Iteration and order module

Can you latch each iteration value in between clocks? Doesn't the iterator send out a stream of values that aren't clocked at the sample rate. It might be possible to use a comparator followed by a latch that only latches when the number is equal to the ones coming out of the iterator. If this = that then router will switch following the comparator will switch on a trigger the latch as it passes the number to be latched.

https://community.native-instruments.com/discussion/comment/208497#Comment_208497

Can you latch each iteration value in between clocks?

You need to be more specific. What do you mean by 'latch'? (you seem to be in Primary mode, but latches only exist in core)

what do you mean by 'clocks'?

Doesn't the iterator send out a stream of values that aren't clocked at the sample rate

Yes, assuming 'limited speed' is unchecked in the properties. The iterator pumps out events as fast as it can. It is limited by the fact that each one must be processed to completion to the end of processing chain, and any 'children' of that chain… i.e. if/when order modules or similar are introduced. Only when all that is completed can the next iteration be generated.

Iterator is an event process, so separate form the Primary audio engine.

It might be possible to use a comparator followed by a latch that only latches when the number is equal to the ones coming out of the iterator. If this = that then router will switch following the comparator will switch on a trigger the latch as it passes the number to be latched.

I can't follow your explanation here. Maybe explain what you are trying to achieve.

Also try to build your own little sketches to prove to yourself whether your ideas work or not. It's really not so difficult. Using numeric displays, lamps, and ACEW when things get complicated. You can create experimental examples to test your theories.

https://community.native-instruments.com/discussion/comment/208586#Comment_208586

Yeah that's a head full there. I was thinking of using a comparator to trigger a latch. The latch should then hold the current value coming out of the iterator. It seems possible if the output of the iterator values are also events. I guess the sample rate isn't important because the iterator acts independently. The comparator is only needed to direct an expected iteration value to the holding cell or latch, whichever you want to call it. I guess if you want to latch all of the iteration values within a time frame you'd have to have a stepper to step thru the latches, one latch captures and holds the first iteration then the second latch would hold the second iteration and so on.

https://community.native-instruments.com/discussion/41294/iteration-and-order-module

It happens like you are hoping…

In Primary each event is processed to its ultimate conclusion before the next is generated, or processed.

So if you have an iterator generating events i1, i2 and i3, and those are sent into an order module with 3 outputs, you get this order

the first event i1 from the iterator is generated and goes into the order module

the order spits out three events in order: i1o1, i1o2 & i1o3 (each of these must wait until the previous one has been completely processed, including all forks caused by more downstream order modules and similar)

then once those are all done, the iterator generates i2 and sends that to the order module

the order spits out three events in order: i2o1, i2o2 & i2o3…

And so on.

Seems like this is explained better in the old R5 manual than in the R6 manual

For what it's worth, I gave up trying to drive multi-displays this way many years ago, all the order modules you end up needing, just obfuscate the code and make it a nightmare to debug. I always use a core cell instead.

For example, here is a simple lamp:

inside the core cell looks like this:

multiple outputs from a core cell that all originate from the same input event are processed in order from top to bottom, so this just works, and always works. It make simple stuff like this really simple, and also enables some really complex processing, sending iterators into the corecell for fancy ******.

Here's the driving code for the visualization graphics in my 'Noise Bleed' Block

It's complex in core, but would be a total nightmare in Primary with all those order/value/merge module combos that would be required. And I can't imagine trying to debug and maintain that kind of Primary code. This core version went through multiple changes and updates pretty much trouble free.

https://community.native-instruments.com/discussion/comment/209389#Comment_209389

What are some common uses for the iterator? In this case I think he wants to customize the appearance of a display. Kind of a feed forward idea, yet iteration typically means to redo something, possibly for better resolution of a math answer.

https://community.native-instruments.com/discussion/comment/209561#Comment_209561

What are some common uses for the iterator?

Updating multiple objects in a multidisplay. Each iteration, you update a different object in the display.

Chet Singer

Iterators are also used to address the individual oscillators and filters in the Sine Bank and Modal Bank.

https://community.native-instruments.com/discussion/comment/209561#Comment_209561

Can be used for anything really , from controlling gui objects to writing waveform data in a table or even visualize stuff
Here I 've used an iterator to diplay the sum of harmonics in an event table , buttery smoooth graphics
The iterator starts counting ( verry rapidly ) from 0 to 1024 (length of table )
Each iteration is going through a sine function and then added /scaled
In N.I. Razor all the filters and osc settings are basically tailor made structered/ordered partials of the sinebank done by iteration , really next level stuff .
Erik Wiegand is true reaktor wizard

In max-msp /pure data is called Uzi

Harmonic table 2.ens

https://community.native-instruments.com/discussion/comment/212600#Comment_212600

Kind of interesting, although nothing seems to do anything but it's the first time I've been able to draw with the mouse.

https://community.native-instruments.com/discussion/comment/212600#Comment_212600

A very thorough and informative response. I feel compelled to thank you on behalf of Studiowaves. Have a good one :)

https://community.native-instruments.com/discussion/comment/212714#Comment_212714

Ooops my bad , when loading in the standalone version , the iterator is disabled because it was connected to audio output 3 ( which is disbaled )
Fixed !
Event table is now connected to non audio output

Harmonic table 2.ens

https://community.native-instruments.com/discussion/comment/212879#Comment_212879

Nice, thought something was odd. It plays now too. I'll check it out and see if it makes sense. I've never actually used any of the tables. Just the read only module. I assume the tables hold samples or something. My guess the tables are indexed or something but at least this will help me learn. Thanks

https://community.native-instruments.com/discussion/comment/212891#Comment_212891

No , the event table does not hold samples .
The event table displays the effect of multiple harmonics by using the iteraton + sine functions for every harmonic , and yes that is written into it but it does not produce sound
The sound generation is a different process but using the exact same method ( sine functions for every harmonic )
The iterator simply adds the value of 1 to the previous value and does this 1024 times ( verry fast ) , each value represents an index for the event table ( which is 1024 indexes long )
The output of the iterator (remember this output is a stream of nr's ranging from0-1024 ) is also scaled (divided by 1024 ): 1/1024 , then 2/1024 ,3/1024 ….1024/1024 ..end result is ramp wave range: 0-1 , this then goes into sine funcions for the harmonics .
Same thing for the audio process , but there I don't need the iterator , I just use a ramp wave reading since functions .
Just have a look at the macro's called "add engine" and "visual" , they are identical .
Add engine = responsible for sound generation

Visual = harmonic summing visulas (using iteration )

Pure data example of iteration

And lastly , the powerfull expression object calculating the first 4 harmonics , whcih can even work on audio signals ( not showcased )