On Mon, 2011-09-26 at 09:27 -0400, David Robillard wrote: > On 26/09/11 06:22 AM, Stefano D'Angelo wrote: [...] > > 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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
