Re: [LAD] 14-bit CC / (N)RPN midi controllers question

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.