Content-Type: text/plain; charset="UTF-8"
On Tue, 2012-08-21 at 23:02 +0000, Fons Adriaensen wrote:
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.
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
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
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
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
Out here in reality where real problems need real solutions, I have two
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.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----