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

On June 8, 2013 11:59:49 AM you wrote:
> On Thu, 2013-06-06 at 20:58 -0400, Tim E. Real wrote:
> [...]
>
> > 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 :)

I knew that comment might generate a response.

> I really think that, in Jack (and LV2), it should just be mandated that
> these (and all other multi-) events be shipped as one,

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...

> for the same
> reason that running status is forbidden: it's annoying and entirely
> pointless.

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.)

> Optimising for a 7-bit wire should be the driver's problem, if a wire is
> even involved...

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...

>
> Some big fancy programs will have to deal with such things anyway, but
> the reality is that these events just aren't supported by most Jack/LV2
> apps. I think it's a lot more likely they would be with a normalisation
> guarantee.
>
> Some consider this best practice even over the wire (with the additional
> safety measure of nulling controllers at the end, but we could skip
> that): http://www.philrees.co.uk/nrpnq.htm

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.

>
> Cheers,
>
> -dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Jun 9 00:15:01 2013