We have tried to make the data structures used in the modules (as inputs and outputs) as consistent as possible. Note Data Lists are received by all Players, mono audio signals are the standard inputs and outputs of the modules (except for the mixer and panning modules), and we have tried to keep the range and values for control parameters simple but logical.

Each module can be controlled programmatically by passing messages to the receives implemented throughout the modules. Messages can be passed from any patch, from qlists or externally from NoteAbilityPro. A complete list of messages is included in each module's Info panel.

Extensions (0.95) to support multiple modules:

It is now possible to use multiple copies of the same module within a patch and to have it controlled by separate messages. To do this, add an extra numerical argument in the Argument(s) field of the bpatcher Inspector. For most of the bpatchers this will be the only argument, but for some, such as the samplerBP and megaSamplerBP w hich already have arguments for the soundfile name, buffer name and pitch, it will be the fourth argument. Once the argument has been added and the inspector closed, the argument value will be appended to module name - in the example below, the argument 21 has been added to an instance of the delayBP.

While all inputs and outputs can be connected and used as before, you can now send messages directly to the bpatcher by appending the argument to the end of the regular message. For example rather sending the message [delayVolL 80 3000] (which will control the module without any added argument) use the message [delayVolL21 80 3000]. NB. There is no space between the delayVolL and the 21 - this is now the name of the receive in this copy of the bpatcher.

In order to support multiple modules that use colls with soundfile information, each coll is assigned a unique name when the bPatcher is opened. If you are using a bPatcher with no argument, then the default coll for that bPatcher will be referenced. However, i f you create a bPatcher with an argument, the coll will be empty until you load data from an existing coll or paste data into the edit window.

This extension allows several different copies of the same modules to be controlled programmatically (from messages, qlists, or from NoteAbilityPro) within a single patch. Thanks to Martin Ritter for designing this mechanism.