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-
