Description Of Reaktor 4.1.2 Module Output And Input Behaviors

DESCRIPTION OF REAKTOR 4.1.2 MODULE OUTPUT AND INPUT BEHAVIORS
document v0.9
16Aug04
(c) copyright dfa
Status: testing and analysis of outputs and output functionality is complete; testing of all inputs should be done to determine if additional behaviors exist, and to list all triggering or non-triggering inputs (shorter category) in an appendix; could add appendices of all wireless application architecture connections, panel output.



SECTION ONE: TYPES OF CONNECTIONS


Audio and event inputs and outputs can be wire connections or wireless connections.

Wire connections are a dot on a module that a wire can be attached to.

There are two types of wireless connections.

1. Wireless user connections: the "internal connections" and user-established MIDI connections, which can be set up for some modules on the Connections page of the Inspector. See Appendix A for complete list.

2. Wireless application architecture connections: the default MIDI data routing (such as incoming gate data sent to the Gate module), and other communication between the Reaktor application and certain modules (such as processor load values sent to the CPU output of the System Info module, or incoming audio sent to the Audio In module in the Ensemble Structure window).



SECTION TWO: OUTPUTS


A. Types of Output

There are four types of output from Reaktor modules.

1. Audio output: the output is audio values (numbers sent continuously at the audio sample rate.

2. Event output: the output is event values (numbers sent once, or at the event control rate, or at specific rates for some modules).

3. Panel output: the output is visual images to the panel.

4. No output: one module (the Module container) produces no output.

See Appendix B for notes.


B. Audio Output Functionality

All audio outputs are active. They send values continuously at the audio sample rate. If the processor is not creating new values, the last value or zero continues being sent at the audio sample rate.


C. Event Output Functionality

There are five types of event output functionality.

1. Active: these event outputs send values continuously, at various rates. There are subtypes of switched active and triggered active. Example: LFO. See Appendix C for complete list.

2. Triggered by manipulation: these event outputs are triggered by manipulation of a control in the panel or the application menubar, and output one value for each value caused by the manipulation. Example: Knob. See Appendix D for complete list.

3. Triggered by global event reset: these event outputs are triggered by a global event reset, and output one value when a global event reset occurs. Example: Constant. See Appendix E for complete list.

4. Triggered by a triggering wireless input: these outputs are triggered when a value is received by a triggering input which is a wireless connection. The wireless connection can be a user connection, or an application architecture connection. Example: a Knob with an "internal connection" set up, receives a value from another control, which triggers output. Example: the Gate module receives a MIDI value from the application, which triggers output. Example: the Tempo module receives a value when the menubar BPM control is changed, which triggers output.

5. Triggered by a triggering wire input: all other event outputs are triggered when a value is received by a triggering wire input, which may be an event input or an audio input. Example: math modules.


Many outputs are triggered in multiple ways, for example a Knob can be triggered by manipulation, by a global event reset, and by user-established "internal connections".


D. Global Event Reset

When any of these actions are taken, a global event reset occurs:

- ensemble opened
- sample/control rate changed in menubar
- processor button turned on in menubar
- instrument/ensemble panel mute buttons unmuted
- instrument/ensemble panel number of voices changed
- wire connected in the structure

And there is one module that has the effect of wires being connected, and so triggers a global event reset:

- Switch (triggers global event reset both off and on)


Note that when a global event reset occurs, that modules reset by it are triggered one at a time, and in no predictable order. This may result in unexpected behavior, particularly at ensemble start-up.



SECTION THREE: INPUTS


A. Types of Input

There are four types of input to Reaktor modules.

1. Audio input: the input is audio values (numbers sent continuously at the audio sample rate).

2. Event input: the input is event values (numbers sent once, or at the event control rate, or at specific rates for some modules).

3. Panel input: the input is user changes to a panel control or application menubar control.

4. No input: two modules cannot receive any input (Text, Picture).

See Appendix B for notes.


B. Audio and Event Input Functionality

There are two types of input functionality which occur for both audio inputs and event inputs.

1. Triggering: when the input receives a value, it stores the value, triggers the module to do something internally, and triggers the module to send a value from its output(s).

2. Non-triggering: when the input receives a value, it stores the value, and may trigger the module to do something internally -- but it doesn't trigger the module to send a value from its output(s).


And one type of input functionality which occurs for event inputs only.

1. Switching: when the input receives a certain value (or range of values), it stores the value, triggers the module to do something internally, and triggers the output(s) to begin active outputting; when the input receives another certain value (or range of values), it stores the value, triggers the module to do something internally, and triggers the output(s) to stop active outputting.


A wireless input is always triggering. A wire input can be either triggering or non-triggering.

There are only two modules with switching inputs, both with a wire input:

- Resynth: the G input switches on and off the Len, Pos outputs.

- Pitch Former: the G input switches on and off the Len and Pos outputs.


A notable non-triggering input is the Pos input on the Router, M->1 Router, and 1->M Router. With the Router for example, when the Pos input receives a value, it stores the value at the Pos input, and it tells the Router to change its active numbered input to the Pos value. But it does not cause the Router to send the last value that was previously stored at the now-active numbered input. So no output occurs. The numbered inputs on the Router are triggering, however. So if the Pos input makes a numbered input active, and then that active numbered input receives a new value, that new value will trigger the Router to send a value from its output. The only other thing that will trigger a Router to send an output value is a global event reset. (It's debatable whether this design for the routers is a feature or a flaw.)


C. Input storage and Tool Tips

All audio and event module inputs store the last value they received, and that value remains available for the module to use (for example a pitch value).

The last stored value received by any input can be read with the cursor hint popup on the wire going into the input.

(Values can change faster than the hint can show them though, in which case the hint only updates periodically to show one of the values recently received, and is not very useful.)

Note that the cursor hint is not showing a current value coming out of the output that a wire is connected to. Outputs only send a particular value for a split second, and most event outputs only send values occasionally.


[CONTINUED IN NEXT POST]

 

Description of Reaktor 4.1.2 Module Output and Input Behaviors, Continued - p. 2

DESCRIPTION OF REAKTOR 4.1.2 MODULE OUTPUT AND INPUT BEHAVIORS
CONTINUED - p. 2
document v0.9


APPENDIX A: Wireless User Connections

User-Established "Internal Connections" - Receive:

- Fader
- Knob
- Button
- List
- Switch
- XY
- Receive
- (MIDI In) Controller

User-Established "Internal Connections" - Send:

- Fader
- Knob
- Button
- List
- Switch
- XY
- Receive
- Lamp
- Meter
- Multi Picture
- Multi Text
- (MIDI Out) Controller

User-Established MIDI Connections - Receive:

- Fader
- Knob
- Button
- List
- Switch
- XY
- Receive


APPENDIX B: Notes on Connection Types

Note that the wire connections that appear on Module containers and Instrument containers are actually the inputs and outputs of the Terminal modules.

The Instrument container module itself receives input and sends output, via wireless application architecture connections to and from the Note Range, Midi Channel, Snap Value, Spread, and Snapshot modules. It sends values to the Voice Info module. It also receives a mute value from the Instrument panel Mute button.

The Module container itself does not send any values. It receives a mute value from the Instrument panel Mute button.

The Text and Picture modules do not receive any input, they output panel output to the panel based on data entered via the inspector.


APPENDIX C: Active Event Outputs

- LFO (at the event control rate)

- Slow Random (at the event control rate)

- Clock oscillator (at its F input frequency)

- Geiger: Out output (per its P and Rnd inputs)

- Grain Cloud: Len, GTr outputs (with sample loaded, rate is number of grains per ms as set by Dist input)

- Grain Delay: Dly output (polyphonic values at its Gr input rate)

- Cloud Delay: Dly and GTr outputs (polyphonic values at its Dist input rate)

- A to E (at the event control rate)

- A to E Perm (at its F input frequency)

- System Value: CR output (at the event control rate)


Two modules have switched active outputs. They are only active while the module is explicitly switched on:

- Resynth: Len, Pos outputs (at the rate of milliseconds of sample playback per audio sample rate, with sample loaded, while G input above 0)

- Pitch Former: Len, Pos outputs (multiple polyphonic values at the rate of grain playback, with sample loaded, while G input above 0)

(Note that the Len, L16, P16, and Ct16 outputs of the Beat Loop module are neither active nor switched active, because they output individual values directly as a result of the Clk input being triggered by individual values.)


One module has a triggered active output. It is active between being triggered by an input value, and when the module completes processing that value:

- Event Smoother (at the event control rate, triggered by input, for the duration of the smoothing)


APPENDIX D: Event Outputs Triggered by Manipulation

- Fader
- Knob
- Button
- List
- Switch
- XY (all outputs)
- Multi Picture (all outputs)
- Start/Stop (triggered by manipulation of Play/Stop buttons in menubar)
- Tempo (triggered by manipulation of BPM control in menubar)
- Snap Value (changing current snapshot)

(Note that 1/96 Clock, Sync Pulse [a.k.a. Sync Clock], and Song Position are not triggered by the menubar Play/Stop buttons per se. The Play/Stop buttons activate the modules, but then individual timing event values are sent to the modules, and it is these values which trigger output values.)


APPENDIX E: Event Outputs Triggered by a Global Event Reset

- Fader
- Knob
- Button
- List
- Note Pitch
- Pitch Bend
- Gate
- ST Gate
- Sel. Gate
- On Vel
- Off Vel
- (MIDI In) Controller
- Chan AT
- Poly AT
- SelPolyAT
- Start/Stop: G output
- Constant
- Sampler Loop: Len output (with sample loaded)
- Lookup: Len output (with sample loaded)
- Tempo
- Tapedeck 1-Ch and Tapedeck 2-Ch: Len output
- Voice Info (all outputs)
- Tuning (all outputs)
- System Info: SR output
- Note Range (all outputs)
- MIDI Channel ICh and OCh (all outputs)
- Snapshot: Snp, Bnk, Sw, MT outputs
- Snap Value

[END OF DOCUMENT]

 

Re: Description of Reaktor 4.1.2 Module Output and Input Behaviors, Continued - p. 2

and OSC!

ciao herw

PS cool description!

 

GREAT POST!

thanks

 

My gosh, very nice, very complete. The formatting alone must've taken you quite a while!

Nice work, I'll be linking to this thread in the FAQ!

- CList

 

thanks very much for this!
do you know if a snapshot change trigs a global event reset? it sure feels like that.
thanks again.

 

Note the typos -- I say "Module container" when I mean "Macro container".

And yes I'm getting around to some other corrections, etc. on this... someday.