> All sorts of talented musicians have done incredible things with MIDI. The resolution of MIDI has been just fine for people with real chops. MIDI 2.0 isn't going to solve the real problem: talent vacuum.
I find it difficult to believe that someone with even a passing knowledge what MIDI does would have this opinion. Most of the variables are only 7 bits of resolution which produces jarring jumps when you try to adjust parameters in real time.
I remember taking a college class 20 years ago where we talked about the deficiencies of MIDI and what MIDI 2.0 should look like. It's been 20 years since that conversation and it's mind boggling to me that MIDI is only getting updated now.
Note that more bits don't eliminate jumps on their own. You need to also send changes at a higher rate to take advantage of those bits, which in turn translates to the need for higher speed encoders, more processing time spent dealing with the data, etc.
A different way to eliminate jumps is simply to low-pass filter the values on the receiver, and read out values from the filter at whatever rate your synthesizer engine can handle. The precision of most controls does not matter that much; you just want to eliminate zipper noise, and this does that.
(Of course there are some controls which need the extra resolution. Filter cutoff comes to mind… even 10 bits I've found limiting. Strangely, even though MIDI 1.1 specifies some 14-bit CCs, filter cutoff is not one of these.)
> Note that more bits don't eliminate jumps on their own. You need to also send changes at a higher rate to take advantage of those bits, which in turn translates to the need for higher speed encoders, more processing time spent dealing with the data, etc.
That presumes a continuous information stream being sampled. But the sample-depth problem affects discrete notes, too—it's pretty easy to notice how coarse-grained the quiet end of variation is on a MIDI keyboard or drum controller's attack pulse.
Yeah, the 7-bit amplitudes really wreck things. I switched from MIDI to OSC basically because of the better resolution, though I eventually gave up due to the lack of support for the protocol.
So I get what you're saying, but this isn't my experience.
There's no room to use small changes in volume for expressiveness at the low end of the volume scale, since attacks/sustains/release shape is more quantized. So if your piece has fff and ppp in it (which is probably a full 40dB range) the ppp part will sound super flat while the fff part might sound great.
Also, MIDI has the nice, round speed of 31,250 bps. Since it uses start and stop bits, that's 3,125 bytes per second. A "note on" message to start playing a note is three bytes long: a 4 bit "this is a note on" field, followed by a 4 bit MIDI channel number, then an 8 bit note number, then an 8 bit velocity ("how hard I hit the key") number. "Note off" messages, sent when you want to stop playing a note, is identical except for the first 4 bit status field. So, if everything's perfect, playing and releasing one single note will take 6 bytes out of the available 3,125 available each second, or 1.92ms. That's why a lot of so-called "black MIDI" songs are probably literally unplayable through an actual hardware MIDI interface.
But forget about playing and releasing notes. Say you're triggering a MIDI drum machine and a synth. Sounds like violins have a slow "attack" - that is, you don't go instantly from "no sound" to "full sound", but ramp up over a short interval. Imagine a violinist that has to start moving their bow, or a trumpeter that has to start blowing. It doesn't matter if you send a synthesizer a set of "note on" messages saying "play a middle C major chord" for violin sounds and they don't all get there simultaneously, because it was going to take them all a little bit to start playing anyway. Drums are a different story. If you expect a kick and hi-hat to play at exactly the same time, you don't have that many milliseconds between their starts before a normal human listener can start to really notice it.
So, the worst case scenario is that you'd have a piece of sequenced music that plays two drums, a piano chord, a bass line, and a violin chord at the same time. This is were sound engineers start getting hyper nitpicky about stringing the equipment together so that:
- The two drums fire off in adjacent time slices so that they sound as simultaneous as possible.
- The piano notes come next, from lowest (because if it's a sampled sound, low notes will be played back more slowly and therefore have a slower attack) to highest.
- The bass sound comes next because those don't usually have a super aggressive attack.
- Violins come last, and it doesn't really matter because they're lazy and they'll take a few hundred milliseconds to really kick in anyway.
The worst case scenario is:
- One drum fires off.
- The rest of the instruments fire off in reverse order of their attacks, like high piano, bass, high violin; medium piano, medium violin; low piano, low violin.
- The other drum fires off.
Because MIDI is so glacially slow compared to every other protocol commonly used, it's going to sound absolutely terrible.
MIDI is amazing in so many way, but it has some very severe technical limitations by modern standards. I can't believe it's taken this long for a replacement to come along.
> playing and releasing one single note will take 6 bytes out of the available 3,125 available each second, or 1.92ms.
Rounding this off to 0.002 s and taking speed of sound to be 340 m/s, we can work out that sound travels 68 cm in that time.
So if you're positioned next to a drum kit such that the snare drum is somehow 70 cm farther from your face, and the drummer hits both at exactly the same time (down to a small fraction of a millisecond), you will hear the snare drum 2 ms later than the high hat.
You're assuming that all of the MIDI events in the entire show are multiplexed onto a single serial data link. That means all the controllers and instruments are daisy-chained, in which case your latencies may be actually worse than you imagine because any piece of gear that has store-and-forward pass through (receives and re-transmits MIDI messages) adds latency.
The obvious way to avoid all that is to have a star topology: have the events flowing over separate cables from the controllers to the the capturing MIDI host, or from the host sequencer out to instruments. Have little or no daisy chaining going on.
Now if you have lots of MIDI streams concentrating in some host and it wants to send all of them to another piece of gear (like a synth, to play them), then maybe yes, the regular MIDI serial link might not be the best. I'm sure we can solve that problem without redesigning MIDI.
> I can't believe it's taken this long for a replacement to come along.
Almost forty years tells you that this is a solution in search of a problem. Industries don't stick with forty-year-old solutions, unless they really are more than good enough.
True, some of it is conservatism coming from the musicians: lots of people have gear from the 1980-s that speaks MIDI, using it on a daily basis.
We used to deal with the serial problem using a hack: bump events back/forward by one or two quantums of time to ensure that they go out over the wire in the order that you want. It's laborious and I am looking forward to the next generation never having to worry about it. (That _will_ be fixed, right?)
If you really had to send the data from multiple sources into a single MIDI destination over a single cable, then if a small global delay were acceptable, a smart scheduling algorithm with a 10-20 millisecond jitter buffer would probably take pretty good care of it so that the upstream data wouldn't have to be tweaked.
(Note that if you stand with your guitar 5 meters from your 4x12 stack, you're hearing a 15 ms delay due to the speed of sound.)
Unfortunately, because of the differences in instrument attack, which a MIDI controller would have almost no knowledge of, I think a random jitter would not fix the issue.
An interrupt controller has no knowledge of device semantics; it can just prioritize them based on a simple priority value. The scheduler could do the same thing. It could even be configuration-free by using some convention, like lower instrument numbers have higher priority.
Also, the physical layer of MIDI could simply be extended into higher baud rates while all else stays the same.
I can't remember the last time I used a serial line to an embedded system in the last 15 years that wasn't pegged to 115 kbps. Bit rate is a relatively trivial parameter in serial communication; it doesn't give rise to a full blown different protocol.
115 kbps is almost four times faster than MIDI's 31250. Plain serial communication can go even faster. The current-loop style signaling in MIDI is robust against noise and good for distance. 400 kbps MIDI seems quite realistic.
This would just be used for multiplexed traffic, like sequencer to synth; no need for it from an individual instrument or controller.
I find it difficult to believe that someone with even a passing knowledge what MIDI does would have this opinion. Most of the variables are only 7 bits of resolution which produces jarring jumps when you try to adjust parameters in real time.
I remember taking a college class 20 years ago where we talked about the deficiencies of MIDI and what MIDI 2.0 should look like. It's been 20 years since that conversation and it's mind boggling to me that MIDI is only getting updated now.