Re: [linux-audio-dev] LADSPA2: logarithmic hint

From: Steve Harris <S.W.Harris@email-addr-hidden>
Date: Fri Apr 28 2006 - 20:59:52 EEST

On Fri, Apr 28, 2006 at 10:01:15AM -0700, Sean Bolton wrote:
> On Apr 28, 2006, at 1:30 AM, Steve Harris wrote:
> >On Thu, Apr 27, 2006 at 08:39:06AM -0700, Sean Bolton wrote:
> >>Okay, Steve, I trust you have something ready to go that you feel will
> >>replace it, but I'm still worried. The discussion you and Paul had on
> >>this list sounded to me like you were both conflating the need for
> >>scaling a linear range (widget or MIDI CC) to an exponential one
> >>(e.g. frequency port), with the need to provide unit labels for port
> >>values (e.g. "dBFS"). The two are independent, and I agree with
> >>Dave that the log scaling hint is essential. It does work when bounds
> >>are sensibly specified (i.e. don't include zero), and needs to be
> >>extended -- not dropped -- to handle the other common cases people
> >>try to (ab)use it for.
> >
> >Sure, the problem is that the log hint doesn't actually do what you
> >want.
> >The only time I use it is for frequency ports. Extending it so that it
> >can
> >cover that case would be really hard, and it only covers the one case,
> >so
> >you may as well just say "this is a frequency".
> >
> <snip>
> >
> >So, what you really need is the information about what the port is
> >actualy
> >representing, that way the hosts can make an intelligent choice about
> >how
> >to map it to a UI feature. eg. a pitch mapping for frequency inputs,
> >and
> >an IEC scale for dBs.
>
> Yikes, now I'm sure this is headed the wrong direction! Say you specify
> that a port is representing frequency -- is it a pitch multiplier,
> where the
> 'knob' should be scaled by pitch (i.e. log(frequency)), or does it
> refer to
> an FFT bin, so that it should be scaled linearly?

Right, so theres a subtle bit of semantics there, which I glossed over.

In the filter case your actually offering an absolute pitch control,
measured in Hz.

In the FFT case, it's frequency measured in Hz.
 
> How about a delay time whose unit is 'seconds'? Log or linear scaling?

Or indeed musical time (bars, beats, semi-quavers or whatever). Seconds is
not often that convienient unless you're working in 60 BPM :) But passing
to the plugin in any other form is antisocial.

I didn't claim that this was easy, just that its possible and can do
something useful, unlike the log hint.

> Or a distortion drive control whose unit is technically 'radians'? How's
> a host supposed to figure out how to scale that? What should it do with
> a 'magnification' port that is unitless?

The "technically radians" thing its a bit of a blind, I have a few like
that, and I just map it to a semantics free %age or similar.
 
> It's not possible for a host to know how to scale a port from just the
> unit
> labeling. Unit labeling and input value scaling are independent, in
> fact
> are completely orthogonal except in certain conventional cases like
> IEC for some (not all!) dB ranges.

Indeed, the dB ranges will need to be distinguished, and in any caase
the host may not want to use IEC scales, if it has a preferred one.

Scaling is only one aspect of the problem of how to correctly provide a
way for the user to set certain values, many types of control port can
have improved UI if the host is motivated enough to provide it.
 
> I'm okay waiting until the base LADSPA2 spec is done to figure this part
> out, to keep the confusion down, so long as we all realize that until we
> do, LADSPA2 hosts will be even more clumsy in this regard than
> LADSPA 1 hosts currently are.

Yes, that is a downside. Pitch (aka frequency) inputs will work slightly
less well than they did in LADSPA1, for a bit.
 
> And Steve -- setting my knit-picking here aside ;-) -- thank you very
> much
> for all your work on this!

No problem, keep up the high quality nit picking :)

- Steve
Received on Sat Apr 29 00:15:08 2006

This archive was generated by hypermail 2.1.8 : Sat Apr 29 2006 - 00:15:08 EEST