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

On Tue, 2012-08-21 at 23:02 +0000, Fons Adriaensen wrote:
> On Tue, Aug 21, 2012 at 06:29:22PM -0400, David Robillard wrote:
>
> > What is this signal? It either means some absolute frequency, or it is
> > useless. This is what I mean by: in reality/practice, signals that
> > represent absolute frequencies *do* exist here, whether anyone likes it
> > or not. They must exist, since the ability to make an oscillator play
> > the appropriate frequency is obviously something you must be able to do
> > in order to build a synth.
> >
> > In AMS, this is true.
> > In actual analogue modular synthesizers, this is true.
> > In every modular synthesizer ever, this is true.
> >
> > It has to be true, because otherwise you can't build synths.
>
> It doesn't have to be true... you can always see the
> absolute part as a property of whatever receives the
> signal.

Which is precisely where this metadata will do. Also the thing that
sends it, as it happens.

> Suppose you have a VCO with two 1/octave control ports.
> One is used by a GUI element, say a slider which could
> have a scale in Hz, note names, or octaves. The second
> is the 'voltage' from a keyboard.
>
> The actual frequency of the VCO would be
>
> F = exp2(V1 + V2 + C) (1)
>
> where C is some constant, e.g. log2(440).
>
> Each of these two ports can be used without the other,
> that depends just one what you are doing. In case you
> use only V1, you could say that C is a property of the
> port that delivers V1. Same for V2.

It is a property of both, and both need to agree for it to work.

> But if you use both, which one, keyboard or calibrated
> slider, is the absolute one and which one is the offset ?
> That, I'd say, is just 'in the eyes of the beholder'.
>
> That's why I'd say that both are offsets, and C is a
> property of the VCO.

There is no such thing as "property of the VCO" except parameters (i.e.
control inputs), so this is equivalent to saying there should be two
ports where only one is absolute.

> Ask yourself this: in what way would (1) be different
> if you'd consider either port to be 'absolute' ?
>
> Even if you'd move C 'into a port', the net result
> would still be the same sum, in which all terms have
> equal status.

Except a component of that sum necessarily represents an absolute
frequency. So you moved it to another port. Maybe there's 40 ports in
that sum. It really doesn't matter.

This line of 'reasoning' is simply not useful.

I have already agreed that moving this to a separate port _in Hz_ is a
good idea. However these plugins have no such port (and I do not want
the fork to diverge). This obviously does not remove the presence of
signals that represent absolute frequencies (since nothing ever, ever
will), but it does make an absolute frequency in octaves go away. (If
everything is in octaves, of course, then it does not make the problem
go away)

Of course, would you want to patch two wires every time you want to
connect a frequency? Of course not, nobody does. So, a convention is
needed regardless. Since that is the case, whether a plugin decides to
parameterize it or not is not really important.

Making the tuning a constant as you did above is effectively equivalent
to making the input(s) represent an absolute frequency in octaves, since
otherwise you can't... well, set an absolute frequency, which is the
goal. Which one is "absolute" is indeed in the eye of the beholder if
you're straining to make the problem vanish in a poof of logic, but in
practice you'd tag one as such and the others as relative modulation
ports.

Out here in reality where real problems need real solutions, I have two
options:

1) Fork these plugins and add a tuning frequency port, in Hz, which
makes the current reality of them using absolute octave signals go away.
The avwlv2 project will have to adjust the ported AMS modules likewise.
Though your plugins do not currently do this, you now seem to think this
is the correct solution?

2) Define an absolute unit in octaves with a standard, absolute, center
frequency. This is current reality, except the "define" part, and the
'standard' is a weird frequency.

Not being tunable sucks anyway. I don't know how I somehow ended up
'defending' this stupid unit. All I'm attempting to do is define it: I
neither created it, nor do I like it.

-dr

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