4 ms·

> - 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 M

> - 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.

vortico 7y ago
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.
- boomlinde 7y ago
  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.

vortico 7y ago

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.

boomlinde 7y ago
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.