Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
Dealing with the order/existence of MSB/LSB is per-hardware, I'm afraid. There is only very little that's standard with MIDI, it mostly depends on the manufacturer. NRPNs aren't obscure, they're quite common out there. It's annoying to set up a parser, but once you have one working, you can deal with many devices. Sending them is of course easy. But yeah, 4 messages.. See NRPNs as a 4-message extension to MIDI to deliver a large amount of high-precision CCs. -Message d'origine- From: robert bristow-johnson Sent: Wednesday, February 04, 2015 10:51 PM To: music-dsp@music.columbia.edu Subject: Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine? On 2/4/15 4:21 PM, Didier Dambrin wrote: That's in theory, but in practice, controllers out there send 14bit values in different ways: -LSB before MSB -MSB before LSB -LSB or MSB sometimes missing (sigh..) yes, all of that. that's what the question is about. dealing with all of these possibilities. -NRPNs (much more common, with the same differences as above) well, maybe like the RPNs, they shouldn't do anything until you send 0xB0 0x62 0x7F 0xB0 0x63 0x7F or maybe i'm wrong about that. dunno shit about NRPN. anyway, i look at NRPNs a lot like an obscure SysEx. who knows what it does? about RPNs, the only RPNs i worry about are 0x – Pitch bend range 0x0001 – Fine tuning 0x0002 – Coarse tuning and maybe 0x0005 – Modulation depth range is RPN 0x0005 supposed to affect the range of the Mod Wheel like RPN 0x affects the range of the Pitch Wheel? i know how the latter is defined, but i can't figger out the former. and i still don't know how Portamento Time (MIDI Control #5) is defined w.r.t. an actual unit of time? and do they mean Time Constant (like exp(-t/tau) or maybe 5 times that (which might be settling time)? i suspect the latter. (and portamento can be done in a variety of different ways, doesn't have to be a simple LPF like in the old Moogs.) -pitch bends (common for mixers) pitch bend sends a 14 bit value in a single MIDI message. that's not a problem. In practice, there is thus no established standard, it all comes down to the controller's manual. hence my question. what have people here commonly done in practice (if they're willing to share a secret) to deal with Fine and Coarse? i'm thinking my 1 or 2 ms delay is the only way to be both flexible about the MSB/LSB order (and missing MSB or LSB as per the MIDI standard) *and* avoid the glitch going from 0x207F to 0x2080. is a 1 or 2 ms delay on a MIDI Control update considered really bad? which is worse, a 1 or 2 ms delay or a glitch lasting 1 or 2 ms? -- r b-j r...@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 - Aucun virus trouvé dans ce message. Analyse effectuée par AVG - www.avg.fr Version: 2015.0.5645 / Base de données virale: 4281/9056 - Date: 04/02/2015 -- 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
Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
robert bristow-johnson wrote: ... so this may have been settled long ago, but i cannot from the standard, make perfect sense of it. ... Does it really say modulation bender in the midi-org spec ? Or is the official midi org a thing of the past. It seems to me like it's up to the receiver of the messages to make some sort of communicating systems type of sense of it all. Hard technically thinking, that leads to a lot of protocol and error control that needs to be done, with timers, interpretation of the controller values, possible tempo match implications (does the controller come just before or after the new bar, and what is the function of the controller and what are it's side effects in a mix for instance), so by lack of a definition I suppose it should follow from what it is that you are designing, and what will drive it. Pretty early on in the Midi-hausse I made some new software with elements that didn't exist yet for a couple of synthesizers, but the advantage was the machines I wrote software to drive for were pretty much a given entity, and I had them on my desk, so I could within reason verify if the the software worked good. More recently *I* delved into bit-precise timing issues of MIDI messages, which for for instance monophonic synthesizer modules could lead to a pretty constant-latency, in principle working more accurate than the 1/31250 second. That's stretching the normal intention and nice use of the MIDI standard from the time of the popularity of serial interfaces, but I know for a fact that there are timing and ordering issues in various MIDI implementations you'd need to know about before being sure how to interface with the protocol of all-notes-off, pause, Midi messages with repeat option, and their possible re-orderings. When midi caught on, the were some complicated but musically sensible protocol conventions, that I think up to a point were officially kept by some organization, I forgot it's name. IIRC it required some sort of membership in order to get a certain part of the specification. Of course in this time of many wonderful and honestly not all too properly deep musically useful thinking software maker, it's probably a jungle. Who's the king of the jungle? I don't know, maybe he's been murdered by psycho's in some software horror show, I don't know. So I'm sorry my only help isn't worth much at the moment... T. -- 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
Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
I would like to see a redefinition or extension of the MIDI specification as follows: -- The semantics of the messages are changed as little as possible -- still note on, note off, controller, etc with the same ID numbers. -- No fiddly 7/8 bit numbers to represent delta times, float times from start of performance used instead. -- Indeed, all values are float. -- Indeed, any number of channels, controller numbers, etc. -- Note on messages can optionally have IDs tieing them unambiguously to specific note off messages, for true polyphony. -- The network protocol for the lower half of the driver can be anything and plug into the same upper half of the driver. Thus transport speed can go way up. The virtue of this scheme is that it can extend the functionality of existing software by plugging new drivers into it, where the extended protocol values are cut down to be backward compatible with existing software, while at the same time new functionality is enabled in new drivers for new software, yet programming patterns would be similar. What do you think? Regards, Mike - Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Thu, Feb 5, 2015 at 4:06 PM, robert bristow-johnson r...@audioimagination.com wrote: On 2/5/15 8:37 AM, Theo Verelst wrote: robert bristow-johnson wrote: ... so this may have been settled long ago, but i cannot from the standard, make perfect sense of it. ... Does it really say modulation bender in the midi-org spec ? i dunno where i got that text file, but this guy http://archive.cs.uu.nl/pub/MIDI/DOC/midi-specs got the same. it really does say that in this translation of the spec to someone's .txt file. Or is the official midi org a thing of the past. maybe, i dunno. It seems to me like it's up to the receiver of the messages to make some sort of communicating systems type of sense of it all. Hard technically thinking, that leads to a lot of protocol and error control that needs to be done, with timers, interpretation of the controller values, possible tempo match implications (does the controller come just before or after the new bar, and what is the function of the controller and what are it's side effects in a mix for instance), so by lack of a definition I suppose it should follow from what it is that you are designing, and what will drive it. Pretty early on in the Midi-hausse I made some new software with elements that didn't exist yet for a couple of synthesizers, but the advantage was the machines I wrote software to drive for were pretty much a given entity, and I had them on my desk, so I could within reason verify if the the software worked good. More recently *I* delved into bit-precise timing issues of MIDI messages, which for for instance monophonic synthesizer modules could lead to a pretty constant-latency, in principle working more accurate than the 1/31250 second. MIDI isn't even that. more like a MIDI msg period of (2 or 3) * (8+2) * 1/31250 second. your timing precision is not better than 0.64 ms. if you had 11 simultaneous Note On messages, one note would be happenin' 6 ms later than the first note, no getting around that. That's stretching the normal intention and nice use of the MIDI standard from the time of the popularity of serial interfaces i wasn't trying to stretch or change the standard. i just wanted to know how to avoid the glitch (of 127/16384) you might get if someone's smooth 14-bit precision control is adjusting a parameter (i think the only way to avoid it is with a couple ms delay). perhaps, no one is doing 14-bit control precision. i know one company i worked for did not. someone mentioned using the LSB controls (#32-63) as the MSB for some unrelated controls. sounds a little application specific (or unpredictable) to me. -- r b-j r...@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
Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
Well, from the synth's point of view, it may receive controller messages from multiple controllers, but it seems a safe assumption that any controller will either send only MSBs, or will send LSBs interspersed with the occasional MSB. So how about this? While a synth only receives MSBs for a given controller, it sets the LSB to the same as the MSB; however, as soon as an LSB is received for a synth, it notes that the controller has entered 14-bit mode, and when it receives an MSB, then depending on the previous value of the MSB, it either resets the LSB to 0 (if the MSB has increased) or 0x7F (it it's decreased). That'll solve the specific glitching problem Robert's highlighting. And two MSBs sent in succession should be enough to switch the controller back to 7-bit mode. What new problems will this raise that haven't occurred to me? -- 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
Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
On 06/02/2015, gwenhwyfaer gwenhwyf...@gmail.com wrote: LSB to the same as the MSB; however, as soon as an LSB is received for a synth*, it notes that the controller has entered 14-bit mode, and *for a CONTROLLER. Must learn to proofread better. -- 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
[music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
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: ___ ... STATUSDATA BYTESDESCRIPTION ... ... ... 1011 0ccc Control Change 0vvv ccc: control # (0-121) (see notes 5-8) vvv: control value ... 5. ccc: control number ccc Description 0 Continuous Controller 0 MSB 1 Continuous Controller 1 MSB (MODULATION BENDER) 2 Continuous Controller 2 MSB 3 Continuous Controller 3 MSB 4-31Continuous 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
Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
On 2/4/15 4:50 PM, STEFFAN DIEDRICHSEN wrote: There's an easy trick to overcome this. Put the MSB into the upper and lower 7 bits. ??? If an LSB comes along, put it into the lower bits. This way, you reach with the MSB alone the maximum value of 0x3FFF. If a LSB comes along, it's welcome but its absence won't limit the range. Hope this helps, Steffan, i don't see how it helps. the issue is not problems with range. it's a problem of a glitch when one crosses the MSB boundary and both LSB and MSB are updated. -- r b-j r...@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
Re: [music-dsp] 14-bit MIDI controls, how should we do Coarse and Fine?
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: ___ ... STATUSDATA BYTESDESCRIPTION ... ... ... 1011 0ccc Control Change 0vvv ccc: control # (0-121) (see notes 5-8) vvv: control value ... 5. ccc: control number ccc Description 0 Continuous Controller 0 MSB 1 Continuous Controller 1 MSB (MODULATION BENDER) 2 Continuous Controller 2 MSB 3 Continuous Controller 3 MSB 4-31Continuous 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
