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. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
