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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Fons Adriaensen <fons@...>
Cc: <linux-audio-dev@...>
Date: Thursday, August 23, 2012 - 4:06 pm

--=-V70ViHczAISwIMyUjoeg
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

t
r).

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

--=-V70ViHczAISwIMyUjoeg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAABCAAGBQJQNlTuAAoJEDZyeCqb82jzL7QQAM6J6QqSoadFoXSyGNVtgsJd
6iJQaFYMKruj4wzunWBxGtNMvwQiX8Lif5CaigjdFFe9lZGYy67pl/L383Idw7XC
Bu/ddPnko0vrD0NRqaU072/Z4WKDaJbfaViWLne2C3xmwVfb50mDXgRBjrhu89nx
O+WCA0pWKBQ1S/EQc1j3IHZqM2E9hxQFu8njVi6CcVMHClDy4elybw+gGnkx5N1t
ZNwD75yiUVdrRJOjSuJVy1cHjwUvkn6R0jvCMqEAIvq1HccmJd3w6O9ycSWT2zcJ
RyIFlQdUIcLCN/RLYILoOPz9EElf/3OM9jnrZFvklT78BiJBUib4tidVIM1zlTAb
kK8GWYd7o0pc3t97UFetqx8i2dVD+V7NZECOK4qx7ve9IdKxo4dMDB7ftAH3Y8lJ
UbbCMXxjR+QjyLZpLlOGFeNYM5Iqo3e6KDIpreoUVLmeXKBrNTQ3oC1nS1QWTvuB
9JfgBC8rJk6BYo267j+EjqoUGLRmnrFRA3ja6Q4bUvgNnGhQLpihesXMloLeK2Jb
N8L94JuAgYm/zKSKIQgVz0DSa45WHDoU0VXHGpp60MouS+GA1mA+sNJMXEi+BfLm
56jiac/mFVTFGc3e2Jsa4LtsYKw4eAN2ag1DELfSRftQwcneCcAkaPfxmy+IarbK
4YVS9fvftmuPnQfMbhp9
=lxKj
-----END PGP SIGNATURE-----

--=-V70ViHczAISwIMyUjoeg--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Jeff McClintock, (Mon Aug 20, 11:02 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Tue Aug 21, 12:50 am)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Nick Copeland, (Tue Aug 21, 8:14 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Fons Adriaensen, (Tue Aug 21, 9:54 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Tue Aug 21, 10:29 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Fons Adriaensen, (Tue Aug 21, 11:02 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Tue Aug 21, 11:50 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Thorsten Wilms, (Wed Aug 22, 8:30 am)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Wed Aug 22, 4:43 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Fons Adriaensen, (Wed Aug 22, 9:12 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Wed Aug 22, 9:32 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Fons Adriaensen, (Thu Aug 23, 10:56 am)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Thu Aug 23, 4:06 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Fons Adriaensen, (Thu Aug 23, 4:35 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Thu Aug 23, 5:07 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Wed Aug 22, 5:37 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Nick Copeland, (Wed Aug 22, 1:24 am)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Wed Aug 22, 1:57 am)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Tue Aug 21, 8:59 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Nick Copeland, (Tue Aug 21, 10:11 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), Jens M Andreasen, (Wed Aug 22, 3:50 pm)
Re: [LAD] Plugin 1/oct frequency controls (AMS/MCP/VCO), David Robillard, (Tue Aug 21, 10:52 pm)