Hector Martin

And now for the crazy bit. There's a whole sub-protocol for device inquiry, capability info, and property exchange over sysex. You know, metadata. It has JSON. And zlib. And Unicode.

Overall the MIDI 2.0 protocol spec seems to be a not-overly-ambitious extension to MIDI 1.0 fixing most of the stupidity and adding enough extensibility, without just, like, making everything a giant pile of JSON or TLV or something. But the MIDI-CI JSON stuff is...

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.