[LAD] JACK & MIDI

Dave Robillard dave at drobilla.net
Thu Jan 17 21:00:01 UTC 2008


On Wed, 2008-01-16 at 17:41 +0100, Fons Adriaensen wrote:
> On Wed, Jan 16, 2008 at 05:02:35PM +0100, Pieter Palmers wrote:
> 
> > I guess you will agree if I state that it would have been better if you 
> > performed this though experiment while the API was still in a volatile 
> > stage. But that observation doesn't help us, so let's not go down that 
> > path. (FWIW I didn't think about the jack-midi API either back then...)
> 
> Well, IIRC, I did raise my voice then, saying it was a pity
> that it was actually MIDI that was being implemented

Indeed, but if you look at the actual implementation, the only thing
that even knows or cares it's MIDI is the drivers.

> But, as I was sad to note then, some people are horrified by the
> idea of having to round a float to an int *** for each and every
> note *** if their app only supports semitones... It's 'too complex
> for beginners' and also 'inefficient'. The fact that the int will
> later be converted to thousands of FP values anyway is conveniently
> forgotten. I don't remember if this turned up in the jack-midi
> discussion or in the one about LV2, but that sort of arguments
> have been used, and repeated, and that makes me bail out at some
> point.

For the record, LV2 events are going with a fixed frames/subframes
timestamp, for several reasons.  Namely it's both easier and more
accurate, works for tempo based or frame based or time based time, and
is binary compatible with every timestamp spec anyone cares about.

If anyone is seriously considering throwing Jack MIDI API out the
window, look at the LV2 event header here (just LV2_Event, ignoring the
type number mapping to URI bit):

http://svn.drobilla.net/lad/lv2/extensions/events/lv2_events.h

- Sub-sample accurate
  - Which you can blissfully ignore and just use frames if you like
  - And happens to be incredibly convenient inside apps (I know)

- Event type agnostic

An API nearly identical to the Jack MIDI one could transport something
like that around, and __any__ kind of event (including MIDI, or whatever
else people come up with) can be easily transported around, without
changing the API for new events at all (other than picking a number for,
say, OSC).

Of course, it doesn't, and probably won't, because this discussion is
happening now instead of months or years ago when it should have.

No modifications to the Jack MIDI API are going to happen in anything
that isn't called "Jack 2.0".  We just _finally_ got the damn API out
there, and there is NO way in hell it's going to break again.

That said, the events should clearly be generic, unless someone can come
up with a good idea otherwise.

-DR-





More information about the Linux-audio-dev mailing list