Here's some more:

- no way to play a unison without resorting to multiple channels - communication is one-way, so no standard way to query what CCs the synth actually supports - tuning table support wasn't part of the original spec (MTS exists but most synths don't implement it) - poly aftertouch exists but it's hard to actually use it effectively due to how it's implemented in keyboards and how the protocol is designed - 128 notes per channel isn't enough for some instruments without resorting to MPE - MPE addresses an important use case but breaks some MIDI abstractions (users have to know about "zones" instead of "channels") - it's possible to lose a "note-off" resulting in a stuck note - 31.25 kbps is slow by modern standards (USB is faster, but then you're stuck with short cables and the "what if neither or both devices are a USB host" problem)

On top of that, I think it's a bad sign that midi.org requires you to login to download the MIDI 1.0 spec. What are they trying to accomplish by making it harder than it needs to be to just read a 40-year-old specification?

I think it may be a good time for a new protocol that isn't based on the same fundamental abstractions as MIDI. Device compatibility isn't necessarily even that big a problem as long as cheap conversion devices to translate between protocols exist (though of course MIDI devices would be limited to what it's possible to express in MIDI).

Instead of note on / note off, I'm imagining a bidirectional protocol where the controller explicitly allocates voice circuits, explicitly tunes them to a particular pitch, and then either triggers envelope generators or takes manual control of the envelope.

For a physical layer I think CAN bus could be a pretty good option. It's meant for low-latency real-time tasks, it's supported by a lot of microcontrollers, the standard speed is 1mbps, and cable length can be very long at that speed (40 meters).

> Instead of note on / note off, I'm imagining a bidirectional protocol where the controller explicitly allocates voice circuits, explicitly tunes them to a particular pitch, and then either triggers envelope generators or takes manual control of the envelope.

Sounds way more complicated.

What makes midi great is how simple Note On and Note Off are.

At the end of the day, piano keyboards are just buttons. It’s no different than a qwerty keyboard. Getting the note data should be trivial.

The simplicity of the Note On Note Off api is the only reason midi still exists despite the rest of it.

> Sounds way more complicated.

Well, sort of. Consider though that a polyphonic synthesizer typically has to internally go to the trouble of allocating a free voice circuit, tuning it to some pitch, and triggering the envelope. What I'm suggesting is making that more explicit in the protocol. In some ways it's simpler because it's closer to how the synthesizer actually works.

> What makes midi great is how simple Note On and Note Off are.

It is nice that you can get a working MIDI controller or synth up and running with very little effort, but if a thing is too simple then it misses a bunch of nuance and becomes an impediment to more sophisticated use cases.

> At the end of the day, piano keyboards are just buttons. It’s no different than a qwerty keyboard. Getting the note data should be trivial.

Technically, that's not true. Most MIDI controllers use a double switch mechanism, where the time elapsed between activating the first and second switch tells you have fast the key was pressed. That gets sent as velocity in the NOTE-ON message.

Sending high-resulotion pitch data should be fairly trivial as well, it's just that we don't have a standard widely-supported way to do it. (MPE seems to be the current best option.)