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

[David Robillard]

On Tue, 2012-08-21 at 21:54 +0000, Fons Adriaensen wrote:
> On Tue, Aug 21, 2012 at 10:14:28PM +0200, Nick Copeland wrote:
> 
> > a. 1/Oct is not a reference value, it is a definition for the effects
> > of amodifier signal. The value of 0.0 should definitely not refer to
> > A440.When a mod signal is applied to an osc then it modifies the setting
> > of the osc. You set the osc to A440 and apply 0v then it has no affect.
> 
> I agree. The only way I could maybe understand Dave's view
> is as follows:
> 
> You write 'if you set and oscillator to A440'. Now *how* is 
> that done ? It could be some control that is 'internal' to
> the oscillator, and then all other 'voltages' are relative.
> Now if that 'internal' control is actually using a port,
> one *could* say that such a port has an 'absolute' meaning
> for zero.

In this model, modules have only inputs and outputs, so yes, this is it
exactly.

> The weak part in that argumentation is that such a port
> is not different from any other one that modifies the
> same frequency. In the end the sum of all values is what
> matters. Since adding two 'absolute' values makes no sense,
> there are two ways to look at such a sum:
> 
> * One term is absolute, the other (N-1) must be relative, or
> * All N are relative, being added to something absolute which
>   is internal.
> 
> Since are ports are in fact equal (even if some may have 
> variable gain and some not), I tend to prefer the second
> way of viewing things.
> 
> Dave, this is also visible in the code: the only 'absolute'
> value in the argument of exp2ap() is that constant term,
> and it doesn't belong to any of the ports whose values are
> being summed.

This issue is less vague and hand-wavey when we instead consider the
output that generates this value.  Usually, the frequency output of the
'note' module which reads MIDI or whatever and emits frequency, gate,
and so on.

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.

This perspective about all signals being relative requires making the
frequency a property of the receiver instead.  This seems to make sense,
except since parameters are parameters, this simply means you have moved
the problem to another port.  Then, *that* port represents an absolute
frequency.

That is: some port will always represent an absolute frequency.  No
matter what.

Having to patch two wires instead of one every time would just be a
nuisance with no benefit.

What this implies is that in a purely volt/oct world, there will
inevitably be a signal somewhere that is in volts/oct that represents an
absolute frequency.  Here we can avoid that by indeed having that 'unit'
always be relative and adding a second port in Hz that defines where
zero is.  Then the absolute frequency port is in Hz.  This is a good
idea because it would make patching tunability simple.  However, nothing
from AMS does this, so a convention is needed anyway.  Hypothetical
plugins with this port would set the default value to the conventional
base frequency, and these plugins will just have it hard-coded.

-dr

-------------- 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/20120821/d0aad37c/attachment.pgp>