Send and Receive
Send and receive allow data and signals to be sent across all patches and subpatches within a rnbo~ object without having to connect directly using patch cords.
Event and signal data within the RNBO patcher can be sent between objects using named objects instead of patch cords. A named send object will pass messages to every receive object (or send~ and receive~ for signals) that shares the same name anywhere within the same patcher and contained subpatches. This is similar to the way these objects work in Max patchers.
Unlike the Max versions however, send and receive are always local to their containing rnbo~ object patcher. Thus, send and receive objects cannot transmit messages across other RNBO patchers.
By default, send(~) and receive(~) works across all patcher levels inside of a RNBO patcher. Subpatchers and abstractions can send data to top-level patchers and top-level patchers can send data to all child patchers.
While send(~) and receive(~) work in polyphonic subpatchers, there are some things to consider.
Each send~ (or send) in a polyphonic subpatcher is sent to all other receive~ (or receive) objects in every voice. This can quickly lead to large values. i.e., a value of 1 coming into a four voice subpatcher with one send~ and receive~ would be 16 (1 across 4 voices, four times; 1+1+1+1*4=16). Keep this in mind when building polyphonic patches.
When using polyphony in RNBO subpatchers that have send~ objects, the receive~ objects in all non-local voices have a delay of exactly one vector.
Setting the subpatcher to
@receivemode compensated will add one vector of delay to receive~ objects within the local voice to align them with other voices. This introduces a small amount of latency, but allows for full synchronization across all voices.
In abstractions and polyphonic subpatchers the special naming convention
local:<name> can be used to create a unique send and receive pair that is restricted to the abstraction instance or polyphonic voice. This is useful when you want to leverage send(~) and receive(~) without crosstalk between voices or patcher instances.
Note that this only works in polyphonic subpatchers and abstractions loaded into patchers with the @file attribute. In normal patchers and subpatchers, these sends and receives behave just like any others.