You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
- Fundamental data unit is now a 32-bit word (fields are packed in though). No longer eating a bit for start/continue marker. - Sysex can now do 8-bit bytes - Optional timestamping, so as to not rely on the transport layer for time resolution
- 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.
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)
Oh yeah, another fix: 7-bit sysex messages are still atomic (except for realtime messages) to preserve MIDI 1.0 compat, but the new 8-bit sysex messages *are* interleavable with other messages and even up to 256 sysex messages may be interleaved together in streams.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
