On Wed, Jan 16, 2008 at 01:32:32PM -0500, Paul Davis wrote: > so, fons, you're proposing one or both of: > > 1) that this community somehow magically defines a new standard > for musical information, despite the complete failure of > the entire field of music technology to do this for the > last 30 years. > > 2) that the relatively few pieces of s/w (and in all likelihood, > absolutely no hardware) that actually use this new > standard internally get to save a few cycles at the > expense of the dozens and dozens of existing s/w and h/w > implementations of MIDI itself. > > Neither makes any sense to me.
And neither I propose. Using wider data types internally (we are running on 32 and 64-bit machines today !) is not 'defining a new standard for the entire field of music technology'. Jack *has* actually taken this step for audio data, by representing all samples as floats while the hardware world, including almost all sound cards I know of, is still using 16 and 24 bit integers. It would at least allow software apps to use more fine grained musical parameters. It *could* create a problem when you have to convert back to plain old 8-bit MIDI to be sent to a physical port. But that's the same one we have for audio samples - if you go back from float to 16-bit you can have clipping and you need to dither. Nobody makes any fuss about that. Jack just does it behind the scenes. And no, I'm not concerned about a few more cycles, but it seems others are, if they have round a float note number to an int. Which is completely silly once you consider the number of cycles that will be required to calculate the actual samples for the same note. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev