9 Jun
2013
9 Jun
'13
5:26 a.m.
On Sat, 2013-06-08 at 18:08 -0400, Tim E. Real wrote:
On June 8, 2013 11:59:49 AM you wrote:
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.
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. 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