On Thu, 2012-08-23 at 10:56 +0000, Fons Adriaensen wrote: > On Wed, Aug 22, 2012 at 05:32:26PM -0400, David Robillard wrote: > > > The oscillators actually have three CV frequency ports: frequency, lin. > > FM, exp. FM. Since the FM ports provide the ability to modulate in a > > moogey way, I'm thinking perhaps the ideal solution (outside AMS) is to > > simply make the frequency port Hz and leave the others as-is. The > > others, being FM, are purely relative. > > (upper case names refer to the enums in *.h, CV means audio rate in AMS) > > FREQ (CV, log) : keyboard voltage, so this needs to be log in AMS. > > OCTN, TUNE (control, log) : from GUI. In fact one control separated into > and 'octave' switch and 'tune' slider. They are two ports only because > AMS derives the GUI from the plugin interface. Today I'd separate them > only in the GUI. > > Note that there is no problem at all if the for example the VCO has > middle C as the reference and the keyboard has A440. Just use the > 'TUNE' control to shift everything by 3/4 octave. That's one of > the reasons why it exists.
Well, it's not the end of the world, but it's certainly not very user friendly. In practice, most users are just going to connect one "frequency" port to the other "frequency" port and expect the right thing to happen (and likely not even understand that -0.75 is the magic tuning number to make things in tune). Of course, this could be achieved by just setting the default value of that port, but as this ridiculously long thread illustrates, use of octaves in this way is problematic. In general, the goal is to describe plugins well enough that a host could easily automatically connect them correctly. Ideas of a reference frequency that may vary makes this a much more complex special case, enough so to effectively mean it would never be implemented (which is really just the same user difficulty rearing its head). I am not sure how much you care, but for the record here are some examples that illustrate how meaningful *ports* are used, which is what makes the concept of "absolute octaves" appear: Simple host module-level connection logic is something like: 1) The sink has port with designation 'frequency' port and unit Hz 2) Does the source have a port with designation 'frequency'? 2A) If yes, and the units match, great, connect them directly 2B) If yes but the units don't match, connect them via a converter, if one is available 2C) Otherwise, and we don't have any specific knowledge about what to do with 'frequency', just leave it at its current value Similarly, if a user does a manual port connection and hits case 2B, the host can offer to automatically convert the units appropriately. Properties of the plugin that affect the interpretation of ports are of course possible to work into this, but it complicates things and requires the host to have special domain knowledge for the designation to be able to do things (note in the above the host may not have any idea what 'frequency' even means, but can still do the right thing). This might be necessary if something is to be gained from it, but here that doesn't seem to be the case. This is why I need a port-centric solution and reject anything that requires a 'property of the module' (or even other ports, ideally) being necessary to be able to interpret port values correctly. Which is to say, there *is* a problem with that situation. A usability one, not a "your computer exploded" one, but a problem nonetheless. > > The filters are slightly different: they also have two CV FM ports (lin > > and exp), but the cutoff frequency is a control port (not CV). It might > > be nice to make this CV as well, space be damned. This one port could > > also be Hz, leaving the others alone. > > Sorry but this is wrong. The filters have: > > A_FREQ (CV, log) : keyboard voltage), > C_FREQ (control, log) : GUI slider > A_FMOD (CV, log) : modulation (e.g. envelope), gain set by C_FMODG (slider). > > So the 'cutoff' is avaiable as both CV and control, and they don't > have linear modulation. Sorry, this is a translation error on my part. Ports in LV2 have unique symbol identifiers, and I have changed the labels to match (this was always confusing in other hosts anyway). I was referring to CV one as lin FM (which as you have argued is what it really is). The point being, to make the use in practice of CV to represent absolute(ish) frequency go away, one of the ports has to be made Hz. This would be the CV 'frequency' in the oscillators, and the control 'frequency' in the envelopes (which might also be made CV, since here CV may also have a knob). This makes octaves always used for FM only and all reference frequency issues disappear. Cheers, -dr
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev