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

On Thu, 2012-08-23 at 10:56 +0000, Fons Adriaensen wrote:
> On Wed, Aug 22, 2012 at 05:32:26PM -0400, David Robillard wrote:
>
> > The oscillators actually have three CV frequency ports: frequency, lin.
> > FM, exp. FM. Since the FM ports provide the ability to modulate in a
> > moogey way, I'm thinking perhaps the ideal solution (outside AMS) is to
> > simply make the frequency port Hz and leave the others as-is. The
> > others, being FM, are purely relative.
>
> (upper case names refer to the enums in *.h, CV means audio rate in AMS)
>
> FREQ (CV, log) : keyboard voltage, so this needs to be log in AMS.
>
> OCTN, TUNE (control, log) : from GUI. In fact one control separated into
> and 'octave' switch and 'tune' slider. They are two ports only because
> AMS derives the GUI from the plugin interface. Today I'd separate them
> only in the GUI.
>
> Note that there is no problem at all if the for example the VCO has
> middle C as the reference and the keyboard has A440. Just use the
> 'TUNE' control to shift everything by 3/4 octave. That's one of
> the reasons why it exists.

Well, it's not the end of the world, but it's certainly not very user
friendly. In practice, most users are just going to connect one
"frequency" port to the other "frequency" port and expect the right
thing to happen (and likely not even understand that -0.75 is the magic
tuning number to make things in tune).

Of course, this could be achieved by just setting the default value of
that port, but as this ridiculously long thread illustrates, use of
octaves in this way is problematic.

In general, the goal is to describe plugins well enough that a host
could easily automatically connect them correctly. Ideas of a reference
frequency that may vary makes this a much more complex special case,
enough so to effectively mean it would never be implemented (which is
really just the same user difficulty rearing its head).

I am not sure how much you care, but for the record here are some
examples that illustrate how meaningful *ports* are used, which is what
makes the concept of "absolute octaves" appear:

Simple host module-level connection logic is something like:

1) The sink has port with designation 'frequency' port and unit Hz
2) Does the source have a port with designation 'frequency'?
2A) If yes, and the units match, great, connect them directly
2B) If yes but the units don't match, connect them via a converter, if
one is available
2C) Otherwise, and we don't have any specific knowledge about what to do
with 'frequency', just leave it at its current value

Similarly, if a user does a manual port connection and hits case 2B, the
host can offer to automatically convert the units appropriately.

Properties of the plugin that affect the interpretation of ports are of
course possible to work into this, but it complicates things and
requires the host to have special domain knowledge for the designation
to be able to do things (note in the above the host may not have any
idea what 'frequency' even means, but can still do the right thing).
This might be necessary if something is to be gained from it, but here
that doesn't seem to be the case.

This is why I need a port-centric solution and reject anything that
requires a 'property of the module' (or even other ports, ideally) being
necessary to be able to interpret port values correctly.

Which is to say, there *is* a problem with that situation. A usability
one, not a "your computer exploded" one, but a problem nonetheless.

> > The filters are slightly different: they also have two CV FM ports (lin
> > and exp), but the cutoff frequency is a control port (not CV). It might
> > be nice to make this CV as well, space be damned. This one port could
> > also be Hz, leaving the others alone.
>
> Sorry but this is wrong. The filters have:
>
> A_FREQ (CV, log) : keyboard voltage),
> C_FREQ (control, log) : GUI slider
> A_FMOD (CV, log) : modulation (e.g. envelope), gain set by C_FMODG (slider).
>
> So the 'cutoff' is avaiable as both CV and control, and they don't
> have linear modulation.

Sorry, this is a translation error on my part. Ports in LV2 have unique
symbol identifiers, and I have changed the labels to match (this was
always confusing in other hosts anyway). I was referring to CV one as
lin FM (which as you have argued is what it really is).

The point being, to make the use in practice of CV to represent
absolute(ish) frequency go away, one of the ports has to be made Hz.
This would be the CV 'frequency' in the oscillators, and the control
'frequency' in the envelopes (which might also be made CV, since here CV
may also have a knob). This makes octaves always used for FM only and
all reference frequency issues disappear.

Cheers,

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev