On June 6, 2013 05:36:50 PM you wrote: Amen to that. You can imagine I'm having a heck of a time trying sort it all out. Such a "comedy of errors" here. I didn't know my keyboard could send 7-bit RPNs until now. It sends low then high RPN param number, when everybody says it ought to be high then low. Yet no real harm it's only the param nums. So I think "Yay I've got a true HW source to test with". So I select an RPN parameter - 7-bits on this old KB and many other devices - and then operate the 'data' slider and I'm sitting in MusE going "Why is ALSA seq giving me separate controller events?" Well, seems ALSA has no such 7-bit (N)RPN support, only 14-bit. So I think, "Even if ALSA could take a 7-bit and deliver me a 14-bit with the high value, it ain't working here!". If so, I'm thinking it's because the data slider messages aren't full RPN messages - the data slider simply sends data H. A few ironies: That it seems I must now manually encode these separated 7-bit RPN ALSA seq events into our internal 'compact' RPN controller type. Darn, maybe we ought to just go with ALSA RAW and DIY the whole thing. That regardless, I must make my own full encoding code anyway for our Jack midi driver, because Jack midi delivers separate events. But that's totally understandable :) That I might pass received Jack midi events back through an ALSA encoder and then back to MusE, yet I'd still need my own 7-bit RPN encoder. That apart from dealing with single 14-bit controls, one must also be prepared to support separate coarse and fine user controls. Meaning any order MSB or LSB, any time. For that reason I am totally discounting anything to do with checking any 'time delay', which I have read about. I'll just try to work with values as is. See my 'options' below. That our internal 'compact' event types are ultimately just decoded again before they are sent to any external midi port. But they are useful internally, for example for sending to soft synth control ports. Luckily, we have some options. We have output instruments, and I've just added input instruments. Our instruments support user definition of special 'compact' internal 14-bit CC, and 7/14-bit RPN and NRPN controllers, and full 'Program'. So when our driver receives midi it can now refer to the chosen input instrument with some new options, for what kind of behaviour to expect from controllers, to help determine our internal 'compact' controller type. The reason for the original question is that I was trying to decide between two or three new 14-bit instrument/controller options: 'Verbose': Either MSB or LSB are encoded anytime anywhere, together with their last LSB/MSB counterpart, initial zero. Good for separate coarse and fine controls. The midi ideal. We get two different encoded 14-bit internal events, but hey, it makes sense here. 'Unified': Wait for LSB. Good for a single 14-bit control - *if* it always sends LSB. Possible third option *if* I should never expect an LSB: 'Verbose with LSB fill': Encode LSB anytime together with last MSB, same as 'Verbose'. But encode MSB anytime with a filled LSB (0 or 127 depending on MSB delta). This MSB delta check ensures a smoother transition. Since we'll end up with two different encoded 14-bit events, we might as well make the MSB encoded one have a smart LSB so that the next LSB will make it continue on the same upward or downward *trend* Of course with all of this, I'm betting on MSB always arriving *before* any possible LSB. Which I know is supposed to be the convention, but I hate to think that some reverse it. Oh well, looks like 'Verbose' mode for those guys... But I even read one product only sent LSB for 7-bit. A 'reverse MSB/LSB' option? Hate the thought of having to do that, and some products might even reverse anytime or in mid-stream... I had thought we might 'tell' ALSA seq exactly what to expect from input controllers, but instead it seems to try to guess by itself. Hm, magic? Hey thanks for listening. Advice and comments always appreciated. Tim.

On June 8, 2013 11:59:49 AM you wrote: I knew that comment might generate a response. Do you mean delivered as a single compact event? That would be cool, but puts a burden on Jack to do encoding magic that the driver may have missed, as is my case, so I wouldn't demand it. But if so, I would want all controller types and situations covered for me, no having to do my own silly encoding. Still, I would hope maybe it would be fairly straight forward to let Jack cover this, so that if the driver, lo and behold, did detect these events, Jack could pass them along. Not sure how, being a raw Jack midi buffer, maybe reserve some bits as flags... Jack Universal Midi Encoder/Decoder API anyone? "Smartest of them all"? But I can't stop thinking that all this 'guessing' by drivers (or Jack) just can't work properly without input from the user: Are we expecting separate coarse and fine adjustment input? Or 'unified' single adjustments? If so, is LSB always sent? Always after MSB? In fact, are we expecting 7 or 14 bits on this particular controller? I find I can't get around those questions. Else if assumptions are made a 'unified' control may lead to value jumpiness. And... About the mentioned 'timeout checking' method for automatic detection: I can't help thinking that this would still not be adequate. If an overly-happy user has, and twiddles, both coarse and fine controls at the same time, then we have interspersed MSB and LSB messages. So as above, I think I'd need to ask the user if we're expecting separate controls - that would be my 'Verbose' option I mentioned. That's how JUMED could be a smart codec - accept some parameters? He he... Hm, I do see a contrast. As in, why not also give us running status then. Is that what you mean? I read some old Jack midi dev posts, it was agreed by most that running status would just complicate things. Still I wonder, wanting to know everything about what's coming in - status or no status - could it be a clue as to the nature of the message? But that means only Jack's ALSA RAW driver could give it everything, right? Another irony. What, I want encoding, but without it, I'd like running status? (Psst: Is there a handy raw midi command or viewer that will show everything? I tried cat dev/snd/* but it seems to only show input not output. Thanks.) Without a raw viewer or HW monitor I wonder exactly what is on my lines, and is ALSA optimizing output. (Should, it's in the ALSA code and can be turned off.) Got an o'scope though. That's always fun... Naw Dave, I know you like talking midi :) Good site, I like detail. But I didn't see mention of data MSB/LSB order and if LSB would be sent if its value didn't change. Our app's instruments can be told to automatically send NULLs or not. So anyway, I know all of this 14-bit stuff is shooting for some fairly obscure support that may, or likely may not for many, be useful. I know some debate: Synths and volumes are supposed to interpolate anyway - but some don't. And even if not, the only parameter that would likely ever need 14-bit would be an oscillator frequency, being the most noticeable and irritating at low-res for live performance. Thus Pitch Wheel should be all anyone needs. Still, it'd be nice if we had at least one other high-res control on standby if needed, say a high-Q filter frequency, which being almost an oscillator, might be annoying at low-res in live performance. So it's there, but challenging, but I'd like to support it if I can. Thanks. Tim.

[David Robillard] Some MIDI devices do not employ 14-bit CCs or the NRPN mechanism. Access' Virus for example maps all CCs as single 7-bit values, and a forced 14-bit mode will break communication. Tim

[Paul Davis] Thanks, that is good to know, and *sorry* about the noise!

On Sun, 2013-06-09 at 11:55 +0200, Tim Goetze wrote: Yeah, dumb (i.e. non-standard) use of CC would have to be preserved, especially to/from hardware. Within Jackville, it's easy enough to specify: events must be bundled iff they are actually intended to be a high-res controller. Otherwise they, by definition, are not part of one. Like Tim R. said though, there's probably no magic way to deal with this for driver input, which is unfortunate[1] (For output it's a non-issue since they'd be delivered as discrete events regardless) -dr [1] Oh look, another Jack metadata use case...