Iteration and order module
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
Comments
-
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.
0 -
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.
0 -
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.
0 -
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.
2 -
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.
0 -
What are some common uses for the iterator?
Updating multiple objects in a multidisplay. Each iteration, you update a different object in the display.
0 -
Iterators are also used to address the individual oscillators and filters in the Sine Bank and Modal Bank.
1 -
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
1 -
Kind of interesting, although nothing seems to do anything but it's the first time I've been able to draw with the mouse.
0 -
A very thorough and informative response. I feel compelled to thank you on behalf of Studiowaves. Have a good one :)
0 -
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
0 -
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
0 -
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 generationVisual = harmonic summing visulas (using iteration )
0 -
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 )
0 -
I'm starting to get the idea. It makes a decent display doesn't it. Does the iterator repeat itself when the screen refreshes of something. I can't see it running wild continuously.
0
Categories
- All Categories
- 19 Welcome
- 1.5K Hangout
- 65 NI News
- 816 Tech Talks
- 4.2K Native Access
- 17K Komplete
- 2.1K Komplete General
- 4.4K Komplete Kontrol
- 5.9K Kontakt
- 1.6K Reaktor
- 389 Battery 4
- 866 Guitar Rig & FX
- 439 Massive X & Synths
- 1.3K Other Software & Hardware
- 5.9K Maschine
- 7.5K Traktor
- 7.5K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators