3 ms·
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
by 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 agoI 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.