On Tue, 2006-05-02 at 17:21 +0100, Steve Harris wrote:
On Tue, May 02, 2006 at 12:15:20PM -0400, Paul Davis
wrote:
On Tue, 2006-05-02 at 17:57 +0200, Alfons
Adriaensen wrote:
I can't imagine any sane interface standard
for audio controls without a
way to say that the natural way to represent a port's range is exponential.
saying that the port range is exponential doesn't pin it down very much.
it still requires the host to make decisions about precisely what kind
of exponential curve to use for the range, and it may get it wrong.
The "type" is irrelevant, the problem is that what I generally want to say
is "this goes from 0Hz to fs/2Hz, and I want it to be logarithmic", but
you can't say that literally, so you have to say "this goes from
fs/10000Hz to fs/2Hz", which tends to make the bottom value a bit random.
I don't know what the correct solution is, possibly just providing a rule
for the host to caluculate what it should use instead of log(0) is enough,
but I'm not sure what the rule should be.
The problem here is that most people who want the log hint just want it
as, well.. a logarithmic hint. Not a precise definition of a
mathmatical mapping from parameter value to port value (which would also
be nice, but is a seperate thing really).
As an example, I map MIDI controllers to negative parameter ranges ALL
the time, and using an exponential curve more often than not. Obviously
in a strict mathmatical sense this doesn't work out at all (can't have a
negative log), but it's a useful (necessary for me) feature. (as
mentioned I calculate the curve on [1, n] and shift it down to wherever
I need it).
I would like ladspa:logarithmic to remain as the fuzzy
not-very-well-defined hint that it is right now, because it solves the
UI/MIDI/etc problems. You can't even provide a usable frequency slider
to a user without it! A future extension that precisely defines ranges,
units, scales, etc. wouldn't conflict with this simple hint.
That said, I'm not going to lose any sleep over it not being in there.
The end effect will just be that the extension which fixes it will
become a de facto standard. Battles over what metadata to include in
the spec is best left until after we have the C side of things
absolutely pinned down to everyone's satisfaction, IMO.
-DR-
-DR-