Order module

Hello! I didn't understand what the Order module does... Please can anyone explain to me what it exactly does and what it's used for? Thanks

 

the hints for the order module are kind of cryptic, but really do make sense. basically, you have a event arrive at the input. that event is then held, and sent out of the #1 output. when that event is terminated, the next event value (but not the same event) is sent out the #2 output. and so on with output #3.

so what terminates an event? well, there are a lot of things that can end an events path, the input of a value module, the event inputs on all samplers or delays or event tables and so on. anytime you have an input that wont be sent back out the output (math modules are like this) you terminate that event.

i thought of this for the first time the other day, the order module is like a 3 stage iteration. but instead of the iteration being determined by the input, it's determined by the output. and it's good to keep in mind that with the order module, you will have 3 separate events being sent out, one right after the next.

 

A good use for the order module is when an event may cause
a big CPU hit.

By splitting it among modules further down the chain, the
event CPU usage will be distributed.

 

...um, sort, though I wouldn;t focus on that as being their main function...

Do a search on EventOrder here in the forums.

One key thing it's used for is when a single event will cause a whole bunch of events to be propagated - due to branching event lines. If you only want one event to come out of your structure when one goes in then you use an EventOrder and an EventValue.

Playing with the event watcher macro will help you understand what I'm talking about. There's almost no other way to fully understand it, explanations only go so far.

See the file - try clicking each button...

In the upper case I say: "just do a whole bunch of math stuff", but because I have branched event paths I get multiple events when the final value gets calculated. If this were feeding an audio input, it really wouldn't matter because audio inputs only "see" the final value because they process after all of the event processing is done on each clock tick.

In the lower case I say: "do a bunch of math, and when you're all done, get me just the final result". This might be useful, or important if I were, for example, using the resulting event as a clock for a sequencer, i might not want to send 6 events downstream as they might cause something else to happen 6 times.

Read the "Helpful links for new users" thread for a post of mine linking to a whole bunch of very detailed articles on events and the ideas of "event propagation" and "how events die"

Cheers,
Chris

 

Not TRUE!
Math modules do not terminate an event!

These things terminate events:
- Audio inputs (on ANY module)

- Modules with no event output ports

- A couple of Ports that NI should have marked as audio inputs, but they (mistakenly) display as event inputs: The Pos input on the Router1->M and RouterM->1, and the Ctl input on the Router1,2 modules

- The In, XO, XR, YO, YR inputs on the event table

That's IT (or that's all I can think of right now). Sending an event to any other event port will cause an event to appear at one or more event output(s) of the module.

 

...wait a second, Theo, I think I see what you're saying about the math modules...

You are thinking of events as "immutable" i.e. they have certain value and any time that value changes the event dies and a new one is born.

I think of events as little capsules that hold a value and flow down the pipes of the structure. A module might change the value in the capsule before it sends it on it's way, but there's only one capsule. When that capsule hits an audio input, it "dies", and the the first branch up the "tree" from where it died sends a new event.

An event OUTPUT port that has two wires connected to it will pass along the original, incoming event down one wire, and when that event dies, it will send a new event "capsule" - with the same value as the last event it sent - down the next wire.

...at least that's the way I visualize it, that is. Of course, what really happens is purely dependent on how you chose to define an "event".

Cheers,
Chris

 

yeah,

i worded that wrong. from my understanding of events, the value can change all over the play with math modules, but the event (call it a unit or whatnot) is still the same event.

so in my mind, there are two sides to an event, the event itself and the event value, and the value can change but the event unit stays the same.

 

Sorry, where's the "Helpful links for new users" thread? I can't find it...

 

check the 'sticky' threads in this forum.

 

It's actually called:
"Useful tips for new and intermediate Reaktor Users"

It's a sticky at the the top of the list of threads when you come to the reaktor forum.

 

Hi
I'm upping the thread because, though reading it at full I'm still not into the Event Order thing; I used the posted demo a bit but I was only able to understand that the event called by the left "offset 25" (the one not going into the EO module) outputs 6 events at one time ,while the right "offest 25" outputs one event at each pressing; does it happen because of the Value module detecting the trigger event?
And, also, if the EO states that the event will pass by all the module chain connected to "1" then all the module chain connected to "2" and so on, would then be any latency?
Sorry for being dull but still don't understan d what the goal would be compared to simply connect all the modules inputs to the event source....

PS, same problems with "Key Info" and "Voice Info" modules, btw

 

There is no latency, all the events happen in the same tick of the sample clock. You computer's CPU runs at a much higher rate than the sample rate, so it can compute the actions of many events for each clock tick. The pre-set latency of your audio buffer already takes in to account all of the event processing that might need to occur. If you have a *really* high number of events - like an iterator driving an iterator - then you'll see a little colored bar rise on your reaktor cpu meter - this is the "temporary event cpu usage" and acts as a warning that very high event-based cpu activity is raising the cpu usage. For one event cascading down several branches the effect on cpu is effectively nothing.

Cheers,
CList

 

As for your first question, yes, all of the events that get created from all of the branching event wires (out ports with more than one wire) - they all DIE when they hit the audio input port pon the EventValue module.

After that (after that *sequentially*, but in the same clock tick - i.e. in the same instant as far as we're concerned), the event from port2 of the order goes into the order module and "grabs" the value from the audio port and spits it out. This is the one event that you see on the output.

Cheers,
CList

 

Thx Clist, i think I'm going to understand this better

 

You may find this helpful. I've been working on a document called "The Essential Guide to Reaktor Events", but I realize that my vision may have been a little too ambitious, and I don't know if I'll ever finish it. That being the case, I might as well start releasing parts of it here, and then see if I can ever get the motivation together to complete it.

Here's a short section about Time in reaktor as it relates to events.

Cheers,
Chris

 

It would be extremely useful and savvy to release it, CList!

M