Iteration and order module

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.

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.

What are some common uses for the iterator?

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

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

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