For completeness, there are a few 14-bit MIDI control standards that I'm aware of, and all of them have major disadvantages.
- MPE pitch wheel: You can only have 16 controls with this method. Otherwise, it's an efficient protocol.
- NRPN/RPN: Requires 4 MIDI messages to send a single value in a proper way (control number, MSB, LSB, NULL control number). Technically you can do it in 3, or 2 if the control number doesn't change.
- CC MSB/LSB: Plows over normal CC messages so you need to explicitly set up your controller / synth to agree with each other. As far as I know the order of MSB/LSB is not defined by any standard, and IMO this makes it a broken standard.
- DX7-style SysEx: Honestly this is my favorite, but because system exclusive messages are supposed to be... system exclusive, nothing else uses this standard (except for some DIY projects I've seen).
> - CC MSB/LSB: Plows over normal CC messages so you need to explicitly set up your controller / synth to agree with each other. As far as I know the order of MSB/LSB is not defined by any standard, and IMO this makes it a broken standard.
It's well defined. The MIDI 1.0 spec says that the range of controller numbers 32 through 63 is reserved for optional LSBs for the corresponding controller numbers in the range 0 through 31. See the "MIDI 1.0 Detailed Specification 4.2" pages 11 and 12.
Your quote doesn't specify the order of LSB and MSB messages sent by controllers. Nowhere in the standard does it specify the order.
The issue is this: If MSB arrives first, you'd want to reset the LSB to 0. If LSB arrives, the value will exist with a 0 LSB for some time duration. This creates bad value jitter. A possible solution (on the synth side) is to hold the MSB in temporary memory until LSB arrives. But if the controller sends LSB and then MSB, this won't work. So you have to deal with the value jitter.
This was brought up at the committee 40 years ago and they decided "eh, not worth it, the jitter's fine." But it's not.
I understand the problem you describe, but it has nothing to do with the order of MSB/LSB being undefined.
The spec, again on page 12, says that upon receipt of an MSB message, the internal understanding of LSB should be reset to 0, so you can't set LSB first if your intent is to set both. If you want to set both MSB and LSB of a control, you have to send MSB first. If you are expecting both MSB and LSB, according to the spec, you can expect them in that order.
What actually prevents the value jitter mitigation strategy you describe is that you don't have to send the LSB in the first place. Controllers and synthesizers could here manually agree via configuration that the LSB will always be sent so that your mitigation strategy would work, or there could be a low-pass filter on the effect of the control to minimize the impact of value jitter for consecutive MSB+LSB changes.
> - CC MSB/LSB: Plows over normal CC messages so you need to explicitly set up your controller / synth to agree with each other. As far as I know the order of MSB/LSB is not defined by any standard, and IMO this makes it a broken standard.
This was set up to a degree with General MIDI 2, and I've found a -lot- of synths in the past that follow it - even to the point of implementing LSB on other controllers that are not part of the standard. This is in the murky past, however, maybe 20 years+ ago...
CC MSB/LSB is still my absolute least favorite method because you have to tell customers to manually set up their DAW/synth to handle each command, or to load a preset/config that does this for them. Of course, customers are going to mess this up, so you end up with lots of tech support issues of the form "I moved a knob on my controller, and it's setting both CC 7 Volume and CC 39, which I've already configured to control filter attack."
I'd also like to mention that MIDI 1.0 runs on a 31250 baud/s com link. This requires a balance between precision and throughput.
The bandwidth gets pretty tight with CC messages interleaved with clock and SYSEX (sample dumps, patch/pattern updates), that in a DIY sequencer, we have to do pendulum SYSEX updates to avoid disrupting the timing.
Care to elaborate the DX7 sysex?
Most newer manufacturers have a long ID so the header already goes like F0 00 20 3C 02 00 ...... F7
- MPE pitch wheel: You can only have 16 controls with this method. Otherwise, it's an efficient protocol.
- NRPN/RPN: Requires 4 MIDI messages to send a single value in a proper way (control number, MSB, LSB, NULL control number). Technically you can do it in 3, or 2 if the control number doesn't change.
- CC MSB/LSB: Plows over normal CC messages so you need to explicitly set up your controller / synth to agree with each other. As far as I know the order of MSB/LSB is not defined by any standard, and IMO this makes it a broken standard.
- DX7-style SysEx: Honestly this is my favorite, but because system exclusive messages are supposed to be... system exclusive, nothing else uses this standard (except for some DIY projects I've seen).