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

On June 6, 2013 05:36:50 PM you wrote:

> On Thu, Jun 6, 2013 at 5:31 PM, Tim E. Real <termtech@email-addr-hidden> wrote:
>
> Lacking access to the full midi specs document, I don't know
> if this question is addressed. I've looked at manuals for products
> which support them and searched the web but I don't see a clear
> answer to my question:
>
> Is it safe to assume that a product or app which allows
> binding a *single* HW or GUI control to either 14-bit CC
> or 14-bit (N)RPN, would *always* send the value LSB, even if
> the LSB did not change but the MSB did, when the control moves?
>
> Do the midi specs address this?
>
>
>
> > The specs do not address this. It is an error in the MIDI spec in my
> > opinion, and I discussed it with someone from the MMA several years ago
> > and
> > they agreed with me. The spec should have ordered things differently OR
> > required that LSB and MSB are always sent. They did not. The existing spec
> > design is easy to implement in dedicated hardware but notably harder in
> > software run on a general purpose machine because you need to pick some
> > arbitrary timeout.
> >
> >
> > Every possible ordering/delivery sequence can be found in one or more
> > devices.
> >
>

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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Jun 7 04:15:02 2013