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

[David Robillard]

On Wed, 2012-08-22 at 10:27 +0200, Thorsten Wilms wrote:
> On 08/22/2012 01:50 AM, David Robillard wrote:
> > 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.
> 
> I would prefer 1), because 1/octave might be useful for modulation, but 
> just complicates matters if the task at hand is setting an oscillator to 
> a specific frequency.

1 does seem to be the most sensible, and avoids all these academic
'problems' since you can honestly consider all voltage relative, though
it means adding a port.  Originally I was thinking about a control to
set the base frequency, but it sounds like you are thinking about adding
a Hz frequency CV port.  This is a better idea, since you get both
options, and the debate goes away entirely.  The overhead is about 2
multiplications per sample, so not really an issue.

Assuming all the modules agree on the frequency you can just use the Oct
CV in an 'absolute' way, or you can use only Hz, or use Hz + Oct for
modulation.  That's nice.

One thing I hadn't originally thought of is tunability.  For Hz,
obviously you can just do this in the note modular.  For Oct, maybe
there would be negative consequences of shifting the value so A is
actually, say, 0.01?  Even numbers and twelfths would no longer lie on a
note...

Particularly for those who play along with real instruments, making sure
we have sensible tunability is important.

> One could even argue that oscillators should not have 1/octave ports at 
> all, but that there should be a plugin that takes a 1/octave modulation 
> input, a Hz base input and delivers a resulting Hz output. The DRY 
> principal applied to plugins.

Fons can perhaps explain it in detail, but I believe there are good
reasons why these plugins need to use logarithmic frequency inputs.  The
attempts at faithful implementations of the Moog filters in particular.

It is definitely questionable for oscillators, but once you have that
unit anywhere, you have an argument for wanting it there as well.  I am
not a fan of this problem that AMS has dropped in my lap, but I also
don't want to have a "Hz vs Voct" debate that would never resolve
anyway.  I only aim to make both usable in Ingen or similar programs in
a way that both powerful and not confusing.

> I doubt consistency with the original plugins will matter in practice at 
> all. The added workload for you sucks, of course and only you can weight 
> that aspect of it, David.

You are probably right that strict compatibility is not really going to
be an issue for anybody in practice.  However, I would prefer to not
fork Fons' plugins at all.  I get the impression he is not interested in
maintaining ports (or doesn't have the time), but I would rather retain
the ability to easily merge changes from upstream regardless.

It may be a nice idea to slam these and the AMS module ports together
and make one nice consistent set of modular plugins, but that is a more
ambitious project that I can't take on right now.

As far as my plan goes, between these and the blop ports, there are
enough modules to build a decent synth, so I would like to focus on
ensuring the Ingen file format is hyper-stable and getting an Ingen
release out there.

-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/20120822/46c9647c/attachment.pgp>