In virtual modular, I used messages between the modules that are similar to the ones of midi, to make the translation easier. This leads to confusion and also to longer messages between modules. The modules strictly need only two numbers until the end-output, which indicates the function and the variable of that function (e.g. change scale to 13, or note on 45 ). However, for more fluid use, there will be need for additional data like channel. An example case is harmonizer: there is a need of being able to use the harmonizer for several different instruments, which in case of midi, will translate to different midi channels. In the current multi-channel configuration, this is achieved by using a “transparent” channel. If the signals were strictly limited to two numbers, there would be only one possible channel outcome to a harmonizer. However, the specification for eventMessages include the possibility of using any length of message. In this case, the timbre specification being optional, could be sent after the base number, resulting in a message like: (function, number [, timbre [, velocity]]). The problem that emerges now, is: what if we want to sent a message with velocity, but no specified channel?. The two possible solutions for this problem are to define a numbre that becomes transparent ( 0xff, same as it is with eventMessages ) or to define different headers that will indicate how to interpret the bytes that follow.
example case: interpretation of eventMessages into midi output
|Target midi message||current eventMessage||static roles||header-defined roles|
|(note on|default channel, C3, default velocity)||note on, transparent, 36, transparent||note on, transparent, 36||note on, 36|
|(note on|channel 2, C3, default velocity)||note on with timbre n°, 36, 2||note on, 2, 36, transparent||note on with timbre, 36, 2|
|(note on|channel 2, C3, velocity 75)||note on with timbre and velocity, 36, 2||note on, 2, 36, 75||note on with timbre and velocity, 36, 2, 75|
The advantage of the first approach is that a module doesn’t need to have methods to process the information that is additional to the basic number; it can ignore it and pass it on untouched until it is interpreted by the end node. The disadvantage, however, is the use of lengthier messages. The two disadvantages of the second approach are the need of each component to have specifications on how to pass the additional information, or to have agreed headers for data (otherwise a note on with “velocity” may become a note on with timbre in the next module). Also there will be a need for an extensive specification for all the cases (note on, note on with timbre, note on with timbre and velocity, note on with velocity, etc.). In general it could be said that the first approach of static roles will fit better with the logic of being modular, since each module needs not to be aware of the expected output for the messages, hence the static roles will provide a scheme where all information is passed to the otputs untouched, except for the bytes which the module is intended to change.