16 Jan
2008
16 Jan
'08
2:33 p.m.
On Wed, 2008-01-16 at 17:41 +0100, Fons Adriaensen wrote:
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.
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.
When a wide enough community embraces a new serial data protocol for
music data, it will be implemented in JACK very quickly. Until that new
protocol emerges, we are not going to waste cycles converting from float
to int in the vast majority of apps just so that a handful of apps can
save the convertion.
As far as greater-than-sample-accurate timing - yes, I understand it has
its uses, but there is no concept of fractional sample time in JACK at
present, and introducing it just to allow something that again forces
the vast majority of apps to do *more* work (the dreaded float->int
conversion) in order to facilitate some interesting corner cases to work
more efficiently ... well, I just don't see the justification.
I stand by the 'never' -:) By HW MIDI devices
I mean those that
use the MIDI electrical format rather than just the data encoding.
these are becoming less and less significant every day. MIDI over USB,
MIDI over ethernet, MIDI over firewire etc etc.