On Sat, 2013-06-08 at 18:08 -0400, Tim E. Real wrote:
> 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.
Jack is already required to remove things like real-time events in the
middle of others anyway. I think it more like Jack - one thing -
*removing* the burden from apps - many other things.
> 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.
There is some burden for Jack on this one, since you need to keep
controller state around to do it, but this is the same burden every
single app would have to bear if it wasn't.
> Hm, I do see a contrast.
> As in, why not also give us running status then. Is that what you mean?
Making apps have to deal with running status is basically opposite to
what I think should be done here. Any MIDI wire gunk that doesn't make
sense in the context of Jack just shouldn't be in Jack MIDI buffers in
the first place.
> 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?
Not really. Running status is simple and quite well-defined. Not
handling it at the driver level is just a pain for everyone with no win.
> 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.
The message format shown there includes both, always. That's the point.
> 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.
I agree pervasive support for high-res controllers would be very nice.
That's why I think Jack should do it. It sounds like you are
over-thinking things though. Correct support for NRPN and such is some
work, but it's clearly doable. Best "we" just have to do it once.
From an app POV, if I get *one* event with a high-res control value in
it, everything's easy.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
This archive was generated by hypermail 2.1.8 : Sun Jun 09 2013 - 08:15:02 EEST