This article describes the Diag module's input and output signals for ring clock, ring transport, global reset, and ring preset signaling.

Ula 1.2 Diag Panel
Ula 1.2 Diag Panel

Panel Display

Ula 1.2 Implements the diag module as a Max bpatcher object, which will look similar to the illustration above in presentation mode. Please see the cycling 74 documentation on bpatchers for their use.

Messages

The following tables show the Diag module's inputs and output messages for clock and reset services. All of these messages pass to all modules on the single-wire ULA serial ring.

Input messages

I/O Message Description
Inputs
D b [-1|0] Controls transmission of the beat from the global transport clock.
D b -1 Disables transmission of beat messages to reduce ring message traffic.
D b 0 Enables transmission of beat messages for module ring use.
D c [list|-2|-1]0|1] Controls the ring transport clock. It is started by default automatically when the diag module receives a [D init] message.
D c -4 Pauses the ring transport clock.
D c -3 Rewinds and restarts the ring transport clock.
D c -2 Stops the ring transport clock, resetting it to 0.
D c -1 Starts the ring transport clock at the current point in time.
D c measure beat tick Sets the current time as specified.
D m [-1|0|list] Controls meter and measure messages from the ring transport clock.
D m -1 Disables transmission of measure messages to reduce ring message traffic.
D m 0 Enables transmission of measure messages for module ring use.
D m top bottom Sets the meter of the ring transport time signature.
D t [-1|0|int] Controls tempo and tick messages from the ring transport clock.
D t -1 Disables transmission of tick messages to reduce ring message traffic.
D t 0 Enables transmission of tick messages for module ring use.
D t tempo Sets the ring transport tempo.
D diag [0|1|2|3] Controls the generation of diag console messages:
D diag 0 No messages are printed.
D diag 1 Only informational messages are printed.
D diag 2 Parsed messages in the message queue are printed with readable descriptions of source and target.
D diag 3 Only error messages are printed, such as uninterpretable source and target formats.
D init Triggers the [R 1] output message. this is because issuing messages to poly instances before they are loaded can cause data loss. Hence, when the slowest object to receive messages has initialized after startup, it can issue this message to the Diag module to indicate the next step in initialization can continue. Often this is accomplished with a Delay object, but this methodology results in faster startup. If no [R 1] message is received after two seconds, information is printed to the console window at level 2.
D preset [s|r]int Signals that the Diag module is to initiate a global preset storage or recall.
D preset s int Stores a preset at the specified slot. Preset 1 is called at system startup in the Ula 1.2 module implementations.
D preset r int Recalls a preset at the specified slot. In the Diag module, meter and tempo parameters are affected, and the clock continues to run if it is on.

Output Messages

I/O Message Description
Outputs

R [-1|0|1|2|3|4]
R p integer
R s integer

 

Global initialization messages. the R x messages are triggered by a loadbang at the primary level, and alsob by the Diag module's reset button.The R p and R s messages are for global preset reclall and storage. These messages allow modules to start up and synchronize gracefully.
 R -1 System reset at power on, intended to fire all triggers normally fired by loadbang inside modules.
R 0 Issued immediately after an {r -1] message, this is to trigger any communications between modules after they have initiaolized themselves.
R 1 Triggered by the receipt of a R init message, intended for preset loading when the system is ready.
R 2 Issued immediately after the [R 1] message, intended to initiate any activity after all modules have loaded their preset settings.
R 3 Issued immediately after a preset, to trigger anything required before a preset loads, for example, to close a gate so the result of loading a preset does not create unwanted messages.
R p integer Intended for global loading of preset specified by non-zero positive integer in all modules for which preset recall is set up globally.
R 4 Issued immediatley after a preset is called for any functions needed when all the preset values have loaded, for example. reopening a gate which was closed by the [R p -1] message.
R s integer Intended for storage of preset integer in all modules for which preset saving is set up globally.
R t tick The current tick of the ring transport clock.
R b beat The current beat of the ring transport clock.
R m measure The current measure of the ring transport clock.

 

Designing Channel Presets

The ULA preset signals are designed to simplify hierarchical preset sets.

first, remember that the Polyvoice module supports multiple channels in one poly~ object, so that any channel can use any number of the available voices. Hence, typically, as in most multichannel synthesizers, each channel has the same panel controls, with different settings applied for each channel Of course there are many ways this could be designed:

  • Each channel could have its own separate presets, with copy and paste of preset settings between channels. A global preset can then recall and store all the different channel settings simultaneously. The advantage is that changes to presets for one channel only affect that channel. The disadvantage is that a desired sound is often on the wrong channel, resulting in many copy and paste operations.
  • All the channels could share one preset pool at a higher level, recalling and storing presets from it and to it. A multichannel set then combines shared presets in different ways. The advantage is that all presets are immediately available on all channels, and that this is the typical GMIDI-style implementation. The disadvantage is that edits to one channel can affect other multichannel sets, and that this is harder to build.

In both cases, the preset recall can generate undesired propagation of preset values to other modules on the ring. In many cases, if the values are the same as before, this is not important, except that it increases CPU load. In some specific cases, resending preset values to an audio module can cause undesirable effects, depending on the design. For example, resending SYNC signal control values can cause sound glitches, as the resent values cause the sync input to reset to a different value. Because one may wish to recall a preset for one voice but not affect other voices playing the same channel, the ULA system provides a signal before and after preset recall, so that the undesired value changes do not propagate immediately. With ULA's systematic loading of channel values just before a voice starts playing a sound for that channel, the preset values can be loaded& just before the audio output from the synth module is silent. (Note: this assumes the voice has already stopped playing the sound for the previous note, which can be enforced by additional control logic in the poly~ module too, as mentioned in the Max documentation).

The following diagram illustrates how the channel sound parameters are gated by ULA reset at power on. The subpatch snoops the R signal values, not removing them from the ring. When the system starts, the [R 0] signal turns off the gate for the channel's sound output. The channel module's preset 1 is then loaded by the [R 1] signal. Then the [R 2]turns the gate back on, so voices can pull sound parameters in from the channel module when they are assigned to that channel. this is the first step to enabling sound storage across channels.

ULA Control Gates for Channel Presets
ULA Control Gates for Channel Presets

The ULA ring reset messages [R 3] and [R 4] likewise provide gate signals before and after loading of top-level ULA presets, and are combined in above.

Note this system also removes the need for 'bondo' or other such message synchronization to stop panel controls sending the same values repeatedly when new values from a preset load are packed together. Here's the rationale. If there's a controller change message from, say, a manually changed panel, then the change is on one control and desired immediately, so the messages don't need to be synchronized with bondo or other such methods to stop duplicate messages. For preset changes of the entire channel program, the data is requested as needed for new voices assigned to the channel, and not sent to the poly~ immediately anyway. So, this gating system also stops message cascades as each panel value is updated by a new preset.