[LAD] JACK & MIDI

Pieter Palmers pieterp at joow.be
Wed Jan 16 17:53:27 UTC 2008


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, with all
> its limitations, and not some extended format that midi could
> be trivially and losslessly translated to, using e.g. 32-bit
> controller numbers, and floating point note numbers and
> controller values.
> 
> 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.
I withdraw my remark, I'm sorry.

> 
> I only picked up the thread yesterday when considering how to adapt
> Aeolus to midi-over-jack. The audio thread only handles note on/off
> directly, all the rest will have to be diverted to the 'model' thread
> somehow. Not a clean thing.
How would you solve it otherwise? As I see it you have
(a) only the need to capture (certain) realtime midi messages
(b) the need to capture both realtime and non-realtime messages (program 
change ?).

in the (a) case you simply drop every event that's not a note-on/off. No 
need to send things to a low-prio thread

in the (b) case, a separate backend port for non-rt data won't help you 
since ports are assumed to be handled in the process() callback (AFAIK).

> 
>> ... E.g. a master controller keyboard with built-in FireWire transport.
>> Hence your 1.a statement is incorrect (especially the 'never be' part).
> 
> I stand by the 'never' -:) By HW MIDI devices I mean those that
> use the MIDI electrical format rather than just the data encoding.

Well, let's say that jack-midi allows for a more broad interpretation of 
'midi', one that matches the firewire one better.

And even with HW midi devices thing can be sample accurate. The fact 
that the MIDI link is low-bandwidth doesn't rule out that it can have 
strictly controlled timing. If a device has a constant latency between 
the time instant a key is pressed and the first (or last) message byte 
is sent, sample accurate timestamping at the receive side does make 
sense since it preserves the relative timing information between events 
(albeit quantized rather rough). I don't think however that such 
behavior is part of the spec, and hence it's probably a non-argument.

In short, I still contest the 'never' part :P.

Greets,

Pieter



More information about the Linux-audio-dev mailing list