[sdiy] MIDI Sys Ex packet length

rsdio at audiobanshee.com rsdio at audiobanshee.com
Sun May 24 20:53:08 CEST 2015


On May 24, 2015, at 11:21 AM, "Richie Burnett" <rburnett at richieburnett.co.uk> wrote:
> If doing a flash update of firmware over conventional MIDI via System Exclusive is it wise to break the download into many smaller packets of say 128 or 256 bytes in length?
I believe that the only reason to do this is if your hardware cannot handle buffering more than that. I've studied many SysEx formats over the years, and nobody breaks down the length to account for the host computer or hardware in the middle along the MIDI data path. The assumption is that the only limiting factor is the device that's receiving the SysEx. Many synths have enough memory to store an entire SysEx message, so they don't break them down. Of course, most SysEx formats were designed before USB-MIDI.

> I was planning on using MIDI-Ox for Sys Ex flash updates, but I guess I could also incorporate the Sys Ex packets into a standard MIDI file that could be played back on any capable hardware?
The disadvantage of SysEx in an SMF (Standard MIDI File) is that you cannot have any ACK/NACK or automatic retry. Of the synths out there, some accept SysEx blindly, without any handshaking, and those can be put into an SMF. The other synths that need handshaking are incompatible with that convenience, and require a dedicated piece of software that understands the handshaking protocol. A Standard MIDI File is designed to be played such that the only information needed is a clock to implement the timing of the transmission - no handshaking can be defined in an SMF. The choice is yours: convenience (SMF) versus error detection and correction (ACK/NACK).

Besides SMF compatibility, the lack of handshaking allows generic librarians to access your SysEx. I believe that a lot of synths fall into this category.

My personal recommendation is that you come up with handshaking that meets your needs, then define it carefully so that software developers can implement SysEx librarians for your hardware. The alternative is to display a big red FAIL on your MIDI synth front panel, so that the user knows to send again.

Frankly, MIDI is considered a reliable transport. I've never experienced a MIDI send error (that wasn't due to software bugs on the computer).

> Does anyone know if MIDI-Ox has any provision for resending packets if something like a CRC fails, or would I have to write my own program at the PC/Mac end to check for ack/nack and resend the necessary corrupted packets?
I only know of one generic SysEx protocol that could be handled by software that's not dedicated to a particular synth. That's the SysEx Sample Dump Standard (SDS) format. If you're implementing a MIDI-based sampler, you might be able to take advantage of this, although it's somewhat limited by its generic design. Apart from that, you won't get automated resending because your protocol will be custom. If you're doing a synth and not a sampler, then I don't think there's ever been a generic handshaking method.

> I've already discovered that certain cheap Chinese USB to MIDI interfaces don't correctly handle MIDI messages containing more than 3 bytes!!! So they're a non-starter from the outset.
USB-MIDI is the single worst thing that has happened to MIDI. The MMA had nothing to do with it, and weren't consulted on it. That said, we're basically stuck with USB-MIDI anyway. It has 4 codes (out of 16) dedicated to SysEx, so any interface that doesn't support SysEx is serious broken.

However, I've noticed that this sort of problem is often in the software. For example, CoreMIDI on OSX has two different functions for sending MIDI messages. One is for most messages, but is limited to 3 bytes, so it doesn't support SysEx. The other call is for SysEx (or long groups of other messages), and supports more than 3 bytes. Many beginning programmers never even notice these other OS calls and therefore don't work properly with SysEx.

Is it possible that the problems you're seeing are software-related and not the USB-MIDI hardware?

On the other hand, I assume the problem has been isolated to hardware and not software. I've certainly seen the sad state of open-source USB-MIDI firmware, where serious flaws in the code meant that budget USB-MIDI hardware ventures probably propagated these amateur errors. It's entirely possible that the firmware on these Chinese USB-MIDI interfaces have really broken firmware.

Brian Willoughby
Sound Consulting




More information about the Synth-diy mailing list