linuxaudio.org

On Mon, 2011-09-26 at 09:27 -0400, David Robillard wrote:

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

[...]

quoted text
> > IMO it could be better done like this: cv:CVPort to be a subclass of

> > lv2:ControlPort and a feature URI to be defined.

> [...]

> 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).

Actually, on second thought, while I dislike making anything at all

complex for this ostensibly simple functionality, I think if a feature

is going to be involved anyway it might be best to allow the host to

explicitly specify which type each port is connected to.  Since this is

intended for modular hosts, the host would typically inform the plugin

which based on what the port is connected to.
The feature would basically allow the plugin to expose an additional

function which the host could call to inform the plugin if the CV port

is connected to control or audio data.
The cost is complexity in the plugin, namely a CV supporting plugin

would have to keep a type flag around for all CV ports to know which it

is connected to (a simple macro or inline function can make the actual

reading simple).  This incurs a minor branch cost (one per CV port per

cycle).
Thoughts?
-dr
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev