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.