Iteration and order module

gentleclockdivider

Question about the iteration

Let's say we have a iteration module that spits out the stream of nr's ranging from 1-8

I want to use these to (rapidly ) change the appearance of a multidisplay (with 8 elements and thus 8 separate x1-x2,y1,y2 ,rgb values for each element )

For that , the index of the element needs to be selected first , and then the parameters ( the order of the parameters are not important as long as they appear after the index is selected )
So ..(long rant ) my question :

If the stream of nr's from the iteration go out the first outlet of the order , it should happen like this ( disregarding outlet 3 for purposses sake )

outlet 1 : value 1

outlet 2 : value 1

outlet 1 : value 2

outlet 2 value 2

outlet 1: value 3

outlet 2 : value 3

And NOt like this

outlet 1 : value 1,2,3,4,5,6,7,8

outlet 2 : value 1,2,3,4,5,6,7,8

If it would happen like thelast example we can't possible adjust the parameters for each separate element of md .module .
I' m a bit at loss
It's also mighty difficult to debug things like these , the console view in other packages are a godsend

Studiowaves

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.

colB

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.