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 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.
... 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.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.