Hector Martin

The biggest thing that bugs me is the single attribute (on top of velocity) for NOTE ON. You should be able to fake more expressive controls with preceding per-note controllers but... that was the one place a variable-length TLV might've made sense.

OTOH they have an okay amount of toplevel message expansion space if needed (6/16 top-level message types are defined), so I hope they use it well in the future.

Now the thing is the new UMP packet format does not define any mapping to physical transports, and AFAICT the negotiation is between MIDI1/MIDI2 features, not the underlying transport. So how is UMP defined over e.g. existing USB-MIDI or DIN UART MIDI transports? No idea.

It seems no physical layer mappings are defined in the MIDI 2.0 spec itself, that's for another document to lay out including any negotiation.

According to their website, they're focusing on USB first (I guess the old 31kbit UART transport is deprecated, unsurprisingly), and a new mapping for UMP over USB(-audio?) needs to be written before that works. So no automatic backwards compat with MIDI1 byte streams.

One thing they did do is make the UMP format self-delimiting. The message type alone determines message length, and they arbitrarily pre-assigned some lengths to all the unused message types. So transports should be able to deliver UMP messages with future expansions cleanly.

OTOH it is *not* robust at the 32bit word level, so the underlying transport has to guarantee that. If you drop or corrupt a word expect things to explode.

(MIDI1 was slightly better at this with the start/continue markers, but in practice this was useless anyway because as soon as you drop any data you get stuck notes so you're screwed anyway)