Content-Type: text/plain; charset="UTF-8"
On Thu, 2012-08-23 at 10:56 +0000, Fons Adriaensen wrote:
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
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.
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-----