MIDI Designer and StreamByter

MIDI Designer Pro 2 provides a flexible, customizable MIDI control surface.

StreamByter, by Audeonic, provides processing of a MIDI data stream.

Working together, they provide a complete MIDI processing and control solution.

Example use combinations
– SB decodes a SysEx status dump from target hardware into individual MIDI commands for display in MDP2
– SB remaps MDP2 controls to different target addresses (e.g., one set of controls for part and master effects)
– MDP2 provides control of SB channel cloning / remapping
– SB provides advanced relationships for MDP2 controls

StreamByter is built in to MDP2 as an in app purchase for input and output processing.

For more advanced processing, add the stand alone version of StreamByter, for looping output back to input.

MIDI Fire adds other tools, such as flexible MIDI routing, with multiple StreamByter modules.

See more about StreamByter.

See MDP2 layouts using StreamByter.

If you need help, post your question on our Q&A forum

MIDI Designer Pro 2 for the Transitioning Lemur User

Liine have announced the end of support for the Lemur MIDI / OSC controller application – see liine.net 

MIDI Designer Pro 2 offers the Lemur user an alternate application that supports many of the use cases of Lemur.

Lemur MIDI Designer Pro 2
Control surfaces for MIDI devices – Buttons, knobs, sliders, lists, VU meters, dynamic labels, XY controls, accelerometer
– Eight banks with up to six pages each
– Abstract visual style controls 🟡 – MDP2 focuses more on hardware realistic interfaces, some abstraction possible
Advanced relationships between control settings – programming required – Super / sub control relationships and named ticks provide no-programming implementations for preponderance of controls
– StreamByter for advanced control relationships 
Open Sound Control – MIDI only
Sequencer, Multi-Ball Controls 🟡 – MDP2 does provide control loopers, but no direct sequencing
iOS Supported, M1 Mac Provisional – M1 is provisional, functional, with in-work interface improvements
End of Support – MDP2 continues active development and support, most recent update in July 2022
?  Active application help and user groups – MDP2 has active users, FB group, shared layouts, and developer provided support
? – Library of user shared layouts

There is no conversion capability to convert a Lemur application into a MDP2 layout.  But with MDP2 you can build a layout without any programming – place controls, adjust settings, connect, and take control of your devices.

When advanced control relationships are required:

  • Super / sub control relationships provide basic control interconnection
  • Named ticks provide scaling, arbitrary relationships, control down-sampling, and more, without writing any code
  • StreamByter provides advanced control relationships with straight-forward lexicon

MDP2 is not a one-for-one replacement for Lemur, but can cover many use cases.

Our user group and support team are standing by to help you transition.  

Check out our Q&A site for help and user layouts – midiDr.com/qa/

Join our FaceBook group – https://www.facebook.com/groups/mididesigner

StreamByter is a audeonic.com product, included in MDP2, available stand-alone and in MIDI Fire

MDP2 – a capable SysEx solution for device control

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.

MIDI Patcher for OSX?

Need a MIDI Patchbay (Router) for macOS (OS X)?

Options Include: