Many current and classic boards provide ability to edit settings via System Exclusive (SysEx) messages.  SysEx provides more data options than Continuous Controller (Cc) or Registered Parameter (RPN/NRPN) messages.  Instead of two MIDI bytes, the data field can be (somewhat) unlimited, allowing for exchange of patch, performance, or even complete system backup.

MDP2 SysEx message format provides for up to four Data bytes, and an extra “channel” byte, for five selectable bytes in a message.

MIDI is already a somewhat non-standard format, since it uses 7 (vice 8) data bits in a message byte.  MDP2 automatically handles conversion from decimal to hex for typical 1 to 4 byte values.  But many manufacturers use even more complicated formats, such as “four bit” encoding (used a lot by Roland), or even somewhat random encoding.  MDP2 has you covered in these cases with “named ticks” – supporting manufacturers completely arbitrary encoding concepts.  In the Roland four-bit per byte case, we can provide a spreadsheet to do the required numerical conversions to load the named ticks.

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.  But what if it doesn’t automatically send?  MDP2 can generate the required interrogation messages to obtain status to synchronize the layout.

A board can report data with individual SysEx messages for each parameter, or a longer combined message with multiple values combined.  Each is supported by MDP2.

For 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, say you need to request 200 parameters, that is a lot of coding.  No problem – a SysEx scanner (https://mididesigner.com/qa/6964) will let just a few controls (typically one for each data byte length) do all the work for you.  (Example – RD-2000, X(m) and RD-88 layouts.)

For a single combined message, the work of separating the single message into individual control messages is done by StreamByter.  Ugh, but now I need to handcraft 200 lines of StreamByter code.  Nope – again, a spreadsheet can automatically generate the needed SB code.  Each situation is slightly different, but we can provide an example if needed to get you started.

Often a manufacturer uses the same SysEx code for a new board, just with different addresses.  In this case an existing layout can be quickly extended to the new board.  But, now you have to change umpteen controls to the new SysEx address format, even though all the data formats are the same.  Nope – SB code can translate the messages in both directions, allowing the layout to be used unchanged with the new hardware.  (Example – some pages in RD-88 editor)

We do have a few limitations.

• We only process data values up to four bytes, and a fifth “channel” byte.  Again, there are work arounds. One is to have StreamByter compressi data inbound to process, re-expanding outbound.  (Example – eight bytes required to select ZEN-Core waves in X(m) ZEN-Core editor).  Other methods get around the limitation of trying to manipulate a >four byte value range on a single MDP2 control.  Again, using SB, split the inbound data into smaller pieces (say, digits of timecode) for display and control, reassemble on outbound.  Some data may be more amenable to using a section of the data to show/hide controls for the remaining range – an alternate solution to the ZC wave selection problem.
• We have a current bug where a few specific cases of V and L are not recognized (https://mididesigner.com/qa/9013)
• We cannot pull out complete patch names for display, or enter patch names, but this in in our think-about pile.  We have several examples of using individual controls (by letter) as a work-around.
• We do not provide storage for SysEx backup, but MDP2 can be the front end to request patch/performance/board backups to be recorded in a separate SysEx librarian.

MDP2 SysEx controls, supported by named ticks and StreamByter code should be able to handle your most complex board implementations.  If you need help, post a Q&A.