MIDI 2.0 Prototyping


Well shucks, I had no idea this was even in the works. Are there more technical details available somewhere? It seems kind of lame the whole spec is being developed in private among these large member companies, but I suppose that’s the only way to push something like this through.

Very curious to see how little or much this deviates from the current spec! (Especially in regards to recent discussion here RE the usefulness of something like OSC for dealing with events as param clusters, streams, or in other non-note-centric ways…)



Oops, there is more detail about the specifics in this post:

Most interesting to me up front is that it’s now bi-directional… o_O

1 Like


It’s in the works since some decades already and there has always been talk about it. Good to see there’s some results finally. Extended resolution and tighter timing is a godsend!

1 Like


This talk clarified a whole lot for me. The basic idea (MIDI-CI) that Mike Kent came up with 2 years ago that makes all the new extensions possible is pretty clever & straightforward – the new bi-directionality in MIDI-CI is like a handshake devices can do to decide if all these new features can be used, otherwise they just fall back to MIDI 1.0…

The dude himself:

JSON over the property exchange API is pretty crazy exciting!

…protocol negotiation sounds like it could support even something crazy like OSC over MIDI…

This is super cool.



Thanks for the video. This could potentially be a new era for electronic music gear. They are talking about 32bit resolution (!!!) and much higher bandwidth and clocking rates too. This means Midi could probably even approach audio rates and the old argument about the resolution of Midi vs. continuous CV voltages would also be obsolete. Also tight sync would never be a problem again.

The downside of course is that the simplicity and elegance of the midi protocol would also be gone. All this talk about protocol negotiation kind of makes my head spin.



I think the protocol negotiation part will be easily encapsulated into a library or other set of functions, and the ability to debug/diagnose the protocol will still be fairly simple. No, we won’t be reading the actual bytes on the wire as easily (but if it stays more-or-less human-readable ASCII in JSON format, that’s a plus), but since they still translate to direct messages it won’t be hard to chart/plot/observe them discretely. It’s certainly a lot better than trying to decode each manufacturer’s custom sysex for a lot of the extended parameters!

I would like them to decide on a physical protocol though - ideally Ethernet or USB - because I see that becoming the next big issue once we need bidirectionality and higher bandwidth.