>it takes a little less than a millisecond to receive a 3-byte MIDI message. >should we put in some kinda delay (like a sample-and-hold) on that which >prevents updating the net control value until 1 or 2 milliseconds after either >the MSB or LSB is received? or slewing the net control value (slewing smooths >out thin little glitches)? this is the only way to be totally flexible about receiving >Coarse and Fine and (if we assume that MSB an LSB are received at adjacent >times, about 1 ms apart) avoiding the glitch. and the price to pay is a 1 or 2 ms delay in updating.
Yeah I don't see any way around that. Note that your proposed revision also requires a 1-2ms update delay, while it awaits the MSB. Seems like a fundamental limitation of a system that's going to rely on split words. E On Wed, Feb 4, 2015 at 12:35 PM, robert bristow-johnson < r...@audioimagination.com> wrote: > > i'm resending this because of unexpected word wrapping and, as much as i > intended to avoid it, a persistent misspelling. > > so this may have been settled long ago, but i cannot from the standard, > make perfect sense of it. > > so the MIDI 1.0 Spec says: > > _______________________________________________________________________ > > ... > > > STATUS DATA BYTES DESCRIPTION > ... ... ... > > 1011nnnn 0ccccccc Control Change > 0vvvvvvv ccccccc: control # (0-121) (see notes 5-8) > vvvvvvv: control value > > ... > > 5. ccccccc: control number > > ccccccc Description > > 0 Continuous Controller 0 MSB > 1 Continuous Controller 1 MSB (MODULATION BENDER) > 2 Continuous Controller 2 MSB > 3 Continuous Controller 3 MSB > 4-31 Continuous Controllers 4-31 MSB > > 32 Continuous Controller 0 LSB > 33 Continuous Controller 1 LSB (MODULATION BENDER) > 34 Continuous Controller 2 LSB > 35 Continuous Controller 3 LSB > 36-63 Continuous Controllers 4-31 LSB > > ... > > 7. Continuous controllers are divided into Most Significant and Least > Significant Bytes. If only seven bits of resolution are needed for > any particular controllers, only the MSB is sent. It is not > necessary to send the LSB. If more resolution is needed, then both > are sent, first the MSB, then the LSB. If only the LSB has changed > in value, the LSB may be sent without re-sending the MSB. > > ... > _______________________________________________________________________ > > > it seems to me very unfortunate that, if they wanted the flexibility of > optionally using Coarse control only (controls 0-31) *and* optionally Fine > control, that they spec'd in Note 7: "If more resolution is needed, then > both are sent, first the MSB, then the LSB. If only the LSB has changed in > value, the LSB may be sent without re-sending the MSB." > > if they were thinking clearly, they would have spec'd in Note 7: "If more > resolution is needed, then both are sent, first the LSB, then the MSB. If > only the LSB has changed in value, both the LSB must be sent followed by > the MSB." if they had done it this way, then the actual control update, > that actually affects the synth, would happen only after receiving the MSB, > whether the LSB was sent or not. receiving the LSB would affect bits in a > field, but they would be "latched" and have no effect until the MSB is also > updated. > > so, to keep with that spec, to be flexible about receiving either Coarse > and/or Fine adjustments, *and* to avoid jaggies that happen when the actual > control is changed after the MSB is changed, but the LSB has not yet been > received, how do we best do it? > > in the past, i had implemented this by simply masking and updating only > bits 7-13 for an MSB control change, masking and updating only bits 0-6 for > an LSB change and when *either* changed, i have assembled the 14-bit value, > scaled and offset it according to the Min and Max for that particular > control, and output the value. it's flexible enough to satisfy Note 7, but > it has little glitches in the LSB. > > like, let's say it's a slider (like Control #16) or the mod wheel (Control > #1). and let's say that we're going from one 14-bit value, 0x207F > (MSB=0x40, LSB=0x7F), to just a teeny bit higher: 0x2080 (MSB=0x41, > LSB=0x00). if our MIDI receiver is flexible enough to react to only a > change in the MSB, first the net control value will go from 0x207F to > 0x20FF, then to 0x2080. so there will be a glitch nearly as big as one > step of the Coarse control when the change intended was one teeny little > step of Fine. > > how best do we do this to both be compatible with the standard (either MSB > or LSB can be received without the other), to update the value immediately > upon reception of the MIDI message, and to avoid this kind of glitch? > > it takes a little less than a millisecond to receive a 3-byte MIDI > message. should we put in some kinda delay (like a sample-and-hold) on that > which prevents updating the net control value until 1 or 2 milliseconds > after either the MSB or LSB is received? or slewing the net control value > (slewing smooths out thin little glitches)? this is the only way to be > totally flexible about receiving Coarse and Fine and (if we assume that MSB > an LSB are received at adjacent times, about 1 ms apart) avoiding the > glitch. and the price to pay is a 1 or 2 ms delay in updating. > > or, as folks in an unnamed synth company i have worked for did it: ditch > (ignore) the LSB? but 7 bits of resolution ain't always so good. > > so how did you other folks deal with this? > > > oh, another question... for Control #5 "Portamento time", does anyone know > of hand how that time (in seconds or ms) is defined from the 14-bit control > value? > > and, since MIDI 1.0, are there definitions assigned to Controls 3, 9, 14, > and 15? or Controls 20 to 31? does anyone implement them? if i cover all > 16 Channels, i don't wanna carve out space for 16 undefined controls that > are never used, or would it be best to have all 32 continuous controls > implemented? my experience (with a few different manufacturers) was that > control messages for controls not implemented for that box were ignored. > but, if you allow the user to create an internal control for their own use, > shouldn't they be able to assign it any channel and control number they > want? > > -- > > r b-j...@audioimagination.com > > "Imagination is more important than knowledge." > > > > -- > dupswapdrop -- the music-dsp mailing list and website: > subscription info, FAQ, source code archive, list archive, book reviews, > dsp links > http://music.columbia.edu/cmc/music-dsp > http://music.columbia.edu/mailman/listinfo/music-dsp > -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
