From the help desk files - a user is attempting to use the MD StreamByter rules as they would be in a stand-alone instance of StreamByter - between a hardware keyboard and an iPad music app.
But - the MD architecture supports StreamByter rules for processing MIDI messages going to or from the control surface in support of MD controls, not, for example, to transpose all notes from the keyboard to the music app.
Sending information THROUGH MD requires creating a pair of controls, one for input, one for output, for each individual message to be passed.
This hack uses SB to create a new, virtual SB path for two or three byte messages, enabling StreamByter processing between two external devices under MD control. We still need a single pair of controls to send a stimulus from input rules to output rules when there is data waiting to send.
The hack support most SB processing on the message stream, with a few limits - any dynamic changes (i.e., controlled by the MD surface) must use SB II rules. You can use SB 1 rules in the input processing, but they cannot be modified by control surface actions.
Logic:
Input rules
- Filter input messages (default is all two or three byte types, can tighten filter - such as only notes on CH 5)
- Perform any static transformation (fixed channel change, fixed transform)
- Shove the messages into the global array (queue)
- Activate the trigger message, waking up output rules
Output rules
- locate next unsent ouput message in the G array
- Perform any dynamic transformation - such as transpose by a variable amount set on control surface
- Send the modified message
- Repeat until queue is empty
The example does a transpose of all notes on channel 4 by the amount set on the control surface.
The hack only works for two and three byte messages. It could be rearchitected to handle some short SysEx messages, but that would be much more complex.
The new virtual route is shown via the orange arrows in the diagram. With the hack, all SB message path possibilities are covered: input, output, feedback, and through.
Note - there is a "through" option for many inputs in the connections page. But this is a straight pipe, and does not enable SB processing on that path.
Additional details in the SB comments.
To use in a production layout, you will need the input and output rules, the two stimulus controls, customize the filtering, static, and dynamic rules as desired, and add any controls and code to store the dynamic control values.
This hack is pretty much limited to a two device architecture.
- In typical use, MD would typically be in a star architecture - i.e, at the center, talking to and listening to all devices.
- But flow processing means it now needs to be between two devices, listening to one device, sending to a second device.
- These two architectures are pretty much exclusive, especially as you go beyond two devices.
- This is why the MIDI Fire app remains a much better solution for the general case - letting you drop a SB module as needed specifically between one particular device output and the desired output, and using MD if needed to control the SB modules.
Images
Virtual path shown in orange
