Hector Martin

- Velocity is now 16 bits - You also get one arbitrary key/value attribute (8-bit key, 16-bit value) next to note on/noteoff, in addition to velocity. E.g. pitch (but just one). - CCs have 32bit data - RPN/NRPN CC changes are now one atomic message, no banking.

- Relative CC changes (inc/dec by an offset, good for stateless buttons?) - Similarly program change now embeds bank msb/lsb/program into one message. - Aftertouch is 32 bits - Per-note pitch bend (32bit resolution) - Per-note controllers

- To support multiple notes on the same pitch or full microtonal stuff, noteon can now *separately* carry pitch info, turning the "note number" into a voice index. You just round robin note numbers and pitch is separate.

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.