
Other methods get around the limitation of trying to manipulate a >four byte value range on a single MDP2 control. (Example – eight bytes required to select ZEN-Core waves in X(m) ZEN-Core editor). One is to have StreamByter compressi data inbound to process, re-expanding outbound.
#Midi sysex librarian code
Nope – SB code can translate the messages in both directions, allowing the layout to be used unchanged with the new hardware. But, now you have to change umpteen controls to the new SysEx address format, even though all the data formats are the same. In this case an existing layout can be quickly extended to the new board. Often a manufacturer uses the same SysEx code for a new board, just with different addresses. Each situation is slightly different, but we can provide an example if needed to get you started. Nope – again, a spreadsheet can automatically generate the needed SB code. Ugh, but now I need to handcraft 200 lines of StreamByter code. (Example – RD-2000, X(m) and RD-88 layouts.)įor a single combined message, the work of separating the single message into individual control messages is done by StreamByter. No problem – a SysEx scanner () will let just a few controls (typically one for each data byte length) do all the work for you. But, say you need to request 200 parameters, that is a lot of coding. Each is supported by MDP2.įor individual messages, the board response does not require any translation – with a SysEx address match and MIDI receive enabled, the appropriate control will update.

But what if it doesn’t automatically send? MDP2 can generate the required interrogation messages to obtain status to synchronize the layout.Ī board can report data with individual SysEx messages for each parameter, or a longer combined message with multiple values combined. Many board will have a “transmit edit” setting that will send messages, often SysEx, when edits are done on the board, to keep a MDP2 control layout in sync. In the Roland four-bit per byte case, we can provide a spreadsheet to do the required numerical conversions to load the named ticks. MDP2 has you covered in these cases with “named ticks” – supporting manufacturers completely arbitrary encoding concepts. But many manufacturers use even more complicated formats, such as “four bit” encoding (used a lot by Roland), or even somewhat random encoding. MDP2 automatically handles conversion from decimal to hex for typical 1 to 4 byte values. MIDI is already a somewhat non-standard format, since it uses 7 (vice 8) data bits in a message byte. MDP2 SysEx message format provides for up to four Data bytes, and an extra “channel” byte, for five selectable bytes in a message.

Instead of two MIDI bytes, the data field can be (somewhat) unlimited, allowing for exchange of patch, performance, or even complete system backup. SysEx provides more data options than Continuous Controller (Cc) or Registered Parameter (RPN/NRPN) messages.

Many current and classic boards provide ability to edit settings via System Exclusive (SysEx) messages.
