Another iteration issue

gentleclockdivider · July 3

I have an issue here with iteration

The iteration count is selectable between 13-32-64 up to 512 , done with buttons and value modules .

These defines the length of each iteration ( and thus length of envelope )
It's then split by an order module , the first output going into a counter to create succesive iterations by each execution .

Second output of order to get the actual value ( pi/2 radians of a sine , inverted to get a decaying envelope )
All behaving correctly , except .
When I choose the nr of iterations without executing the iter , you ll notice that the counter always advancs one step .(last part of gif )
That's becasue whatever value is stuck at the upper input of the divide module , is divided by the lower input .

I tried putting an order + value module in between and this works but now the iteratin is doubled , instead of 32 I get 64 etc…( second giff )
Here's the ensemble for anyone to have a look , just push the value buttons ( make sure counter is reset to 0 ) and don't press the iteratin to see the issue
Giff 1

Ritmenvelope.ens

https://i.imgur.com/xsB8Ekg.gif

gentleclockdivider · July 3

https://i.imgur.com/5zHCcdP.gif

Here I inserted a value module ,this ussue described above is gone nut now

resulting in twice the the length off original iteration .

gentleclockdivider · July 3

Update triggering the iterator directly when selecting the range , but the counter still adds one
Added modulo after counter

https://i.imgur.com/ldpZiq3.gif

Ritmenvelope.ens

gentleclockdivider · July 3

Ok , so this is driving me nuts and I tried to narrow it down

I've got 3 buttons each assigned a value b1= 8 , b2=16 b3=32 .

Each button should define the nr of iterations , divide the iteration by that nr( to get a linear ramp ) and lastly trigger the iteration .

The most logical thing would be order outlet 1 : define nr of iter.cout

ord.out 2 : send to divide module after iteration

ord out 3 : trigger the iteration
Like this .

I attached two event watchers while triggering the button with value 8

The first debugger iteartor shows 9 iterations in total ( starting from 0 ) , the second debugger ( which is placed after iteration divided by constant 8 ) shows 10 iterations .
And it's actually the third iteration step that has a value of 0.125
remember we're dividing by 8 , so why the third step ?
I loathe primary events so so much ;)
And please N.I . allow for bigger res. picture uploads

https://i.imgur.com/NUK1rVp.gif

colB · July 3

This is exactly why builders often use core where possible, this kind of problem doesn't exist in core.

One thing you could try to start with is driving the counter from the iterator output, instead of from the divide. When the divide is fed from that value module, it ends up with double the number of output events (that's the issue that doesn't happen in core). That will work if the code in the other branch isn't sensitive to the extra events.

Another option would be to stick a step filter after the divide…

There are other possible solutions, but this kind of code in Primary is always horrible. You battle to get it working, then at some point you want/need to make some change, and its groundhog day… roll back the workarounds, make the change, then find a whole load of new workarounds and hacks to fix problems created by the Primary event model.

…as soon as the complexity of what you are trying to build rises above "chain some modules together", Primary sucks!

gentleclockdivider · July 3

Well I was hoping that I could solve the double iteration by using the value

You're right , driving the counter directly from the iteration gives a perfect spacing of the divisions
Why the F..does the divide module messes this up ?

It's not that primary sucks, it's the primary events that sucks .

For certain tasks primary is just fine ,

I am building a modal synth that uses 3 event tables for partials , damping and amp ( y-location interpolation ) and the modalbank , can't really do that in core (modal ban ) , for phase modulation Primary is also verry good .
Core is superior for low level dsp , but I am far from an advanced user to say the least

gentleclockdivider · July 3

Iirc , when an event arrives at it's destination the event dies but the value stays there .
Then when a new even arrives , ths old value is added to the new arrived event .

Not sure it was exactly this , but it seems like it .

colB · July 3

https://community.native-instruments.com/discussion/comment/233079#Comment_233079

It's not that primary sucks, it's the primary events that sucks

In a dataflow language, events are the backbone.

Core and Primary are both dataflow languages. The main difference is the event model. Primary, and the Primary event model are the same thing. The language is the event model.

The Primary event model requires each event to be processed to it's ultimate destination before the next event is handled/processed. When an event is split, either using an order module, or taking multiple wires from a single output, the result is 2 or more unique events, that each have to be processed in turn to their ultimate destination. While the first is being processed, the others must wait.

In the case of your division, the upper value and the lower value (via a value module) are separate unique events that must each be processed to their ultimate destination. So for each event out of the iterator, the division gets fired twice, once for the upper value, and once for the lower value. There is no way to avoid this. You have to understand it, and design your code to avoid it, or use things like step filters to mitigate the problems.

In core, two different event paths that originate from the same source are considered to be simultaneous. That means that when an event is split, then re-joins at the inputs of a division (or whatever else) the division is only processed one time, because of that logical simultaneity. There is no need to process it twice. The core approach only has a couple of gotchas, that are fortunately easy to deal with. One is the idea of merging. If multiple events have the same origin, and you merge them, then only one can 'survive' so the rule is that the one at the lowest input of the merge survives. The other issue is OBC ordering. That's another topic. The point is that these things are well defined, easy to handle, and end up being useful mechanisms rather than problems.

A few years ago, I got sick of explaining this over and over again, and posted a more thorough explanation with an example that highlights the issue. Unfortunately it made no impact :). The folk that get it are already using core as much as possible, the folk that don't get it, just don't get it, so keep using Primary.

I'll see if I can dig out the example

colB · July 3

Here you go. It's a very simple set of examples of how Primary can cause the number of events being processed to explode, while core doesn't. Just using simple math operations. It also shows how to using order and value modules to prevent the issue.

core vs primary with exp event explosion.ens

gentleclockdivider · July 3

I am aware of all off the above and dataflow in general , it's just that I have been out of the reaktor rotation for quite a while ( thanks to max-pure data ) ,and yes the primary event system will always feel counter intuitive .

but thanks anyway

Edit : to get back to the divission issue

The issue is not only that the division happens twice , it's that the event value stays at the input of the last module an is added to the next one .
Just have a look at this one .

Reset the counter and press the button 8 , then reset the counter again so the counter reads 0

Hovering over the output of the division shows value 1 (last value of iterator is 8 divided by 8 ) , clicking on button 8 again fires the iterator and the counter shows 9 .

That's becasue the previous value is added .
That's the issue (amongst others )

Events.ens

Another iteration issue

Comments

Categories