1. First steps in Reaktor Core - Native Instruments

3.4. Processing order
As you have seen from the previous examples, when a module sends an event,
the downstream modules respond to that event. From that, one might conclude
that, despite producing logically simultaneous events, the modules are
definitely not processed simultaneously. One might further conclude that, for
a given connection, it would be reasonable to process the upstream module
of the connection before the downstream module of the connection. All those
conclusions are, in fact, correct.
The general rule of processing order of the modules is:
If two connected modules are processing logically simultaneous events,
then the upstream module will be processed first. If the events are not
simultaneous, then of course, the order of processing for the modules
is the order of the processed events.
From the above rule it follows that as long as there is a one-direction connection
path (always upstream or always downstream) between two modules,
then there is a defined processing order for these two modules: the upstream
module is processed first.
If there is no one-direction connection path between two modules, their
processing order relative to each other is undefined for logically simultaneous
events. That means that the order is arbitrary and can change
as a result of various actions. The structure designer must take care
that such situations occur only for modules whose relative processing
order is unimportant. That is normally automatically the case as long
as no OBC connections (see below) are involved.
Here is an example, the digits showing the order of module processing:
�
��
��
��
For the above structure, there is an alternative valid processing order:
��
��
REAKTOR CORE – 61