Hacker News new | ask | show | jobs
by m-hilgendorf 1699 days ago
MIDI 2.0 is transport agnostic so it doesn't necessarily require USB, however USB is going to be the best solution for connecting many MIDI devices for awhile.

The big underlying change is that MIDI 2 is duplex, which allows for device discovery, property exchange, and profile configuration. What that buys you is an arbitrary protocol for exchanging information about what things are connected to each other on the same network of devices. It should allow for a lot of cool features, like supplanting Mackie Control and Eucon with an open (or at least trivially open) protocol. One thing I think we'll see with these is more support for microtonal or arbitrary pitch systems that MIDI currently can't realize.

Jitter compensation is built into the protocol too so it should resolve some of the timing issues with USB.

Having read through the spec and written the data structures out for it already I'm not sold that it's overly complex. The additional annoyance is that it mandates JSON parsing but that isn't a tall order these days.

2 comments

Mackie Control is open already (even if Mackie didn't really intend that to be the case).

Eucon is a perfect example of how to make a control protocol so powerful that nobody can ever really use it, or at least, not more than 5% of its capabilities.

Mackie and Eucon do not provide music performance data, so they would never be involved in pitch control. MTS can already be used to do microtonal stuff, but very few synthesizers are MTS aware, so the fact that you can do it already with MIDI 1.0 doesn't help a whole lot. Maybe 2.0 will encourage (a few?) more synth makers (soft/hard) to support MTS and/or the new stuff, but maybe it won't.

What would you have recommended instead of JSON?
It's weird to put variable-length text-based serialization formats into something that has to perform in realtime no matter what, on potentially limited hardware.
I think JSON makes a lot of sense. It's just orders of magnitude more complex to parse into useful data structures than MIDI1, or any other part of MIDI2.

Since MIDI is already going the opposite direction of say AES67 and reinventing wheels is ok, a custom binary encoding would have made more sense to me. Something that can be encoded in a C89 struct without a ton of trouble or doesn't need much thought put into an allocator on bare metal devices to get the handshake working.

I believe it's not strictly JSON though, I don't have the docs in front of me but iirc strings have a max length. So that's good.

JSON feels like a terrible choice to me, especially on the latency aspect of things.
msgpack comes to mind...