17 Jan
2008
17 Jan
'08
5 p.m.
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:
Indeed, but if you look at the actual implementation, the only thing
that even knows or cares it's MIDI is the drivers.
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 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-