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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
