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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Stefano D'Angelo <zanga.mail@...>
Cc: <linux-audio-dev@...>
Date: Monday, September 26, 2011 - 1:27 pm

This is a multi-part message in MIME format.
--------------010201000001070901070103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 26/09/11 06:22 AM, Stefano D'Angelo wrote:

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

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

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.

-dr

--------------010201000001070901070103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 26/09/11 06:22 AM, Stefano D'Angelo wrote:

2011/9/26 David Robillard <d@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.

<pedantry>
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.
</pedantry>

-dr

--------------010201000001070901070103--

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

Messages in current thread:
[LAD] AMS to Ingen: VC to PCM, Aurélien Leblond, (Sun Sep 25, 8:52 am)
[LAD] AMS to Ingen: VC to PCM, Aurélien Leblond, (Sun Sep 25, 1:28 pm)
Re: [LAD] AMS to Ingen: VC to PCM, David Robillard, (Sun Sep 25, 9:01 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Aurélien Leblond, (Mon Sep 26, 1:37 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Loki Davison, (Mon Sep 26, 2:15 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Thorsten Wilms, (Mon Sep 26, 2:11 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Fons Adriaensen, (Sun Sep 25, 2:39 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Aurélien Leblond, (Sun Sep 25, 3:07 pm)
Re: [LAD] AMS to Ingen: VC to PCM, David Robillard, (Sun Sep 25, 9:09 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Thorsten Wilms, (Sun Sep 25, 3:18 pm)
[LAD] LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM), David Robillard, (Sun Sep 25, 9:50 pm)
Re: [LAD] LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM), Stefano D'Angelo, (Mon Sep 26, 10:22 am)
Re: [LAD] LV2 CV Port extension (WAS: AMS to Ingen: VC to PCM), David Robillard, (Mon Sep 26, 1:27 pm)
Re: [LAD] AMS to Ingen: VC to PCM, David Robillard, (Sun Sep 25, 9:11 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Fons Adriaensen, (Sun Sep 25, 10:02 pm)
Re: [LAD] AMS to Ingen: VC to PCM, David Robillard, (Sun Sep 25, 10:20 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Fons Adriaensen, (Mon Sep 26, 9:08 am)
Re: [LAD] AMS to Ingen: VC to PCM, David Robillard, (Mon Sep 26, 1:13 pm)
Re: [LAD] AMS to Ingen: VC to PCM, Fons Adriaensen, (Sun Sep 25, 10:10 am)
Re: [LAD] AMS to Ingen: VC to PCM, Gabriel Beddingfield, (Sun Sep 25, 1:53 pm)