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

David Robillard d at drobilla.net
Tue Aug 21 20:59:03 UTC 2012

On Tue, 2012-08-21 at 22:14 +0200, Nick Copeland wrote:
> On Tue, 2012-08-21 at 11:02 +1200, Jeff McClintock wrote:
> >> > I think the most reasonable standard for an absolute 1/oct
> >> > frequency unit is 0.0 = 440Hz?
> >>
> >> My modular plugins use a reference of 440Hz. Also parameters are ranged
> >> between 0.0 - 10.0 but can exceed that if need be. (in a modular synth,
> >> everything needs to interoperate).
> > 
> > So for frequency 5.0 is 440Hz (Middle-A). i.e. the middle of the range -
> > 5.0, is the standard 'middle' key.
> > While I initially thought negative values was really weird, on second
> > thought having it centred about 0.0 is nicer, especially considering the
> > relative uses
> > Great idea though. Octaves are far more universal than western semitones,
> > yet trivial to convert between.
> Aren't there a couple of misconceptions here or at least some
> potential
> for incompatibility?
> The signal itself is a digital representation of a voltage modifier.
> The
> voltage has no semantic other than its value, it does not represent
> freq
> or gain or cutoff or anything - the semantics of what happens only
> occurs
> at the 'sink/dst' of the signal.

Yes, but as already mentioned, for a modular to be usable a standard is
required.  The analog synths on which this was modeled have such a
standard.  As it turns out, that was based around A as well, just dug up
by Robin Gareus on IRC:


Even volts on A in both schemes.

> Consider the following points:
> a. 1/Oct is not a reference value, it is a definition for the effects
> of a
> modifier 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.
> If you apply 1v it should output A880, that is 1/octave. If you want
> the
> signal to be able to reduce the frequency then you transpose the osc
> down
> by a couple of octaves and then set the base mod signal at 2+ve to get
> back to a natural tuning, you can now reduce the frequence by 1/Octave
> too.
> Now let's have a look at those negative values with another example:
> b. It should not support negative values. Let's forget about the 1/Oct
> for a minute. This defines how a mod signal is applied: if it is
> applied
> to an osc or filter coff it represents 1/Octave. It can also be
> applied to
> an amplifier though. If you accept negative values you will get phase
> inversion and a relative signal gain, that is probably not the
> intention
> of the modifier though: if you do not restrict the signal to +ve
> values
> then the source of the mod signal may need to understand more about
> the semantics of the sink - in the case that you have 0.0 to
> represent 
> A440 then does it also have to represent 0dB (or -96dB) when it
> is applied to an amplifier for example. This is excessive since in an
> arbitrary system where rewiring is possible then sources can be audio
> signals or can be mod signals so now they need to understand where 
> they are patched to be able to deliver a correct reference. That is at
> best difficult and at worst unmanageable.

Erm... only being able to modify frequencies upwards would be useless.

Nobody is suggesting that *all* "voltages" that affect frequency are
absolute.  Clearly modulation inputs would be centred about 0 relative
to... whatever/nothing.  If you do otherwise, then you ruin the ability
to modulate frequency with anything (e.g. audio signals).

Plugging a e.g. keyboard frequency into an amplifier gain directly
(without any conversion) is obviously not going to work no matter how
you do things.  Using audio to modulate frequency, however, is a
fundamental ability.  You don't even need modulation inputs for this to
be useful, you can just plug the absolute frequency and some audio into
the same port (so they will be summed) and get the FM you expect.

Regardless, it has to be centered about something.  If you want to make
it positive only, then it has to be rooted at something.  To me it seems
all this achieves is limiting the frequency range you can express (since
you have to pick a lowest note) and gains nothing.  If you divide 440 by
2 successively until you get close-ish to 0, you get numbers like
0.21484375.  Centering about standard concert tuning frequency seems
quite a bit more sensible to me.

If you could start at 0Hz, that would be nice, but of course 0Hz * 2
is... 0Hz :)

> The above is partially opinion but is based on analogue signal paths
> from the old mono/mega synths. Agreed it might be time to move on but
> either way, a modifier signal of 1/Oct is based on the 1v/Oct and in
> that model the modifier signal has no reference regarding frequency,
> gain or anything else, that reference is a function of what it is
> being
> used to modified.

Fons pointed this out, and while correct in some academic sense, it is
not useful.  Pretending the absolute frequency signal is not in fact
absolute and moving the problem to the receiver doesn't really make the
problem go away, and in practice raises a ton of implementation
difficulties that weren't there before.  Suffice to say it is highly
preferable to have *ports* be meaningful on their own.

In these modular synths, both analog and digital, signals at times *do*
represent absolute frequencies.  This is a fact, this is reality, this
is not debatable.  Yes, you can think of these as all modulation
frequencies and move the problem of a base frequency onto the modular
itself, which is reasonable in an academic sense, but not useful.  It
makes the theoretical problem go away by way of semantic trickery only,
it doesn't make the actual problem go away.  In reality you have some
'note' module which emits CV to describe frequency, which is inherently
absolute since describing a frequency is what it does.  This means
everything needs to agree on what the base frequency is.

A good thing for plugins to do would be to have an input that defines
the center frequency in Hz, though these plugins do not have such inputs
and I'd rather not add ports to them (it is also a teeny bit more math
to do, but probably not a significant overhead)

> Just to be complete, I have no objection to such signals having some
> implied semantics.

Signals inherently have implied semantics at some point if they are ever
actually used to do something.

>  There will be some apps that do not have such
> restrictions and this will result in inconsistencies - this is a good 
> thing though, probably, modifier signals and arbitrary routing was
> always used as a testbed to generate new sounds so bring them on.

No restrictions here.  In most apps like this you are always free to
plug any signal into anything.  The need to define these things is
essentially a documentation issue (for both humans and programs).  It's
all just floats at the end of the day.

Thanks for the input,


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

More information about the Linux-audio-dev mailing list