16 Jan
2008
16 Jan
'08
1:53 p.m.
Fons Adriaensen wrote:
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
On Wed, Jan 16, 2008 at 05:02:35PM +0100, Pieter
Palmers wrote:
I withdraw my remark, I'm sorry.
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 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.