[sdiy] MIDI Note chaining (was MPE)

[rsdio at audiobanshee.com]

On May 6, 2018, at 11:13 AM, Ben Bradley <ben.pi.bradley at gmail.com> wrote:
>> "This is easy. You always “steal” the first note and then only echo
>> the remaining notes. Each subsequent synth does not see the notes
>> stolen earlier, but proceeds to steal the “first” note that it sees,
>> and then passes on the rest. Any synth that’s already playing a note
>> will simply pass on everything until it sees a matching Note Off."
> 
> If this is going through the original MIDI protocol (the 5-pin
> DIN/serial protocol, and I'm not familiar with how well or badly "MIDI
> over USB" is) it's going to be slow - each device has to read two or
> three bytes, determine the note is not for them, then retransmit them,
> doubling the delay time between each note. The ideal (and expensive,
> but if you've already got 16 monosynths, ...) solution is an
> in-between device that does the note assignment and has a separate
> output port and cable to each monosynth.

Yes, the ideal is a global controller that knows everything. A disadvantage is that this global controller needs a setting for the number of voices attached, but that’s either a feature or not depending upon your use case. It’s not necessarily a workable product, though, since as you say it’s more expensive.

However, the chained option is not as slow as you think. If fact, it’s not slow at all.

Once a given mono synth is playing a note, it can literally pass on every message except Note Off without delay. This means each byte of the multi byte messages would be sent as soon as it’s received, without significant delay. There’s no need to collect complete messages before passing on the individual bytes. The only byte that might be delayed is the first byte of a Note Off message, because the synth would need to wait until the note number byte is received to decide whether to pass on the message or not. It should even be possible to pass on all Note Off values without delay, since downstream synths are surely going to ignore a Note Off for which they never received a Note On.

However, when that same mono synth is not playing a note, it still won’t be delaying Note On messages. The first Note On command will not be passed on, but that’s not a delay because it’s going to be stolen anyway. Once that first Note On has been received, the firmware starts operating in the mode I described above where further Note On messages are sent without waiting for the full message.

The MIDI retransmit delay is 0.32 ms, plus any interrupt overhead on the specific processor being used. 0.32 ms is hardly a delay at all. Most synth keyboards are scanned in a matrix of rows and columns of switches, such that more than 0.32 ms separates even the notes of a chord played “at the same time.”

Granted, writing MIDI firmware that properly parses messages and implements minimal retransmit delay, especially for the MIDI System Real Time messages, is not a given. Not every firmware developer has the skills or experience and understanding. Fortunately, the MIDI protocol is designed so that ancient 8-bit 1 MIPS processors can handle it. Todays processors are hundreds to thousands of times faster, and the protocol is still just as streamlined.


USB-MIDI has a minimum delay of 1 ms, perhaps more if you consider all of the operating system and application overhead necessary for chaining. There’s not even a guarantee that the USB driver has to service the USB-MIDI endpoint on every frame, so the delays are impossible to predict. However, if you have USB-MIDI, then you probably have a computer, and if you have a computer then you really should just use a global solution like you describe where all of the mono synths fan out from a central controller.

Brian Willoughby
Sound Consulting