[LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO)

David Robillard d at drobilla.net
Mon Aug 20 15:24:17 UTC 2012

On Mon, 2012-08-20 at 10:18 +0000, Fons Adriaensen wrote:
> On Mon, Aug 20, 2012 at 12:27:12AM -0400, David Robillard wrote:
> > tl;dr: I think the most reasonable standard for an absolute 1/oct
> > frequency unit is 0.0 = 440Hz
> You're confusing two things: unit and reference point. The second
> you have only on a log scale, for example if you use dB you need
> to define what 0 dB means.

Good point, but a "unit" in general can include a reference point as
part of its definition.  When used relatively, as with dB for e.g. gain,
it's usually obvious what the reference point is.  When used absolutely,
sure, you need a reference point, but multiple reference points is hell.

Augmenting "octaves" is probably a bad idea though, I will probably make
a new unit for "octaves centered around <whatever>".

> The unit here is 'octaves'. The reference point is not a property
> of any port AFAICS. It could be a property of the plugin: the
> frequency it is set to when all control inputs are zero.

That is a sensible way of looking at it, but a plugin /could/ have two
ports in octaves with different reference points.  Probably shouldn't,
and certainly weird, but it makes sense.  You can think about it either
way, but port-centric is much simpler in practice.

Precisely defining port "units"(+reference points) is straightforward,
and fits in with what hosts actually do (check unit, "oh, it's ms and I
have s", do the right thing to get the desired value in the port).
Doing so for the plugin in metadata is a slippery slope to having to
precisely define the entire internal operation of the plugin is so it's
clear what that reference point means.  If we really want to cling to
the idea that this unit is strictly relative, better to use define the
reference point dynamically with a control input (in Hz) as Sean
suggested, though this would add a very tiny amount of overhead and
might cause problems for plugins with precomputed things(?)... It is
also tricky for things working with note numbers since the convertion to
and from note numbers is very simply, but if you involve tuning in Hz,
not so much.

... but anyway, this is all ontology astronautics.  What is needed, in
practice, is a way to have one particular numeric value convey one
particular absolute frequency, as it does with Hz, or with AMS's
convention.  That means a standard reference point, regardless of how or
where it's specified.

I guess, since it's your code... how do you feel about using 440 instead
(at least in LV2 versions), and how difficult would this be to adjust?
It's not immediately obvious to me what magic number twiddling would
have to happen.

I realize in reality I am probably stuck with this (IMO ill-considered)
convention... oh well.  Seemed worth mentioning anyway.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20120820/fb07b72c/attachment.pgp>

More information about the Linux-audio-dev mailing list