Content-Type: text/plain; charset="UTF-8"
On Sat, 2013-06-08 at 18:08 -0400, Tim E. Real 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.
> Still, I would hope maybe it would be fairly straight forward to let Jack=
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.=20
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 -=20
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
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 stan=
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.
=46rom an app POV, if I get *one* event with a high-res control value in
it, everything's easy.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----