[LAD] LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM)

David Robillard d at drobilla.net
Mon Sep 26 13:27:07 UTC 2011

On 26/09/11 06:22 AM, Stefano D'Angelo wrote:
> 2011/9/26 David Robillard<d at drobilla.net>:
>> Here is a quick extension for "CV Ports", i.e. audio ports with control
>> semantics:
>> http://lv2plug.in/ns/ext/cv-port/
> Argh.... sorry for not having followed the discussion when it took
> place, but I have to say I really dislike this extension.

Meh, no big deal, it's just a draft. Those big red letters aren't for 
nothing. :)

> The problem is that it can easily go against the "graceful degrading
> configuration" concept of LV2. E.g., suppose writing a varispeed
> plugin that takes the amount of delay as a control input - you will
> end up writing two versions, one using CV ports and another using
> normal control ports, if you want to support both kinds of hosts.

or just don't, and expect hosts to implement this trivial extension.  
Backwards compatibility would be nice though...

> IMO it could be better done like this: cv:CVPort to be a subclass of
> lv2:ControlPort and a feature URI to be defined.

I suppose this could work, since theoretically the port is still 
connected to a buffer with a single float as lv2:ControlPort dictates.  
Subclass is academic since most hosts don't care anyway, the port would 
have to literally have both types listed.  The only way for this to be 
feasible is if the host supports said feature, it guarantees that such 
ports will ALWAYS be connected to a full audio-rate buffer (otherwise 
you need some mechanism to say which it's connected to and things get 
too complex). This is slightly more complex, but not too bad, and only 
complex for hosts that support CV... good idea.

It's debatable whether or not this violates the spec:

"Hosts that do not support a specific port class MUST NOT instantiate 
the plugin, unless that port has the connectionOptional property set"

This is ambiguous. We might want to reword that slightly in the next 
revision to explicitly state that hosts can instantiate if they 
understand *some subset* of the port types that describes a port type 
they support, i.e. unknown additional types can be ignored. This implies 
new port types can't modify the definition of others, which is good and 
should be explicit anyway.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20110926/e713a499/attachment.html>

More information about the Linux-audio-dev mailing list