I implemented cv:CVPort[1] for these plugins (a CVPort is just an AudioPort that works as a control). I've only done some very quick preliminary testing.
However, I don't think this is the best way of doing CV for most plugins, mainly because it is not backwards compatible with ControlPort. For plugins only usable in a modular and/or plugins where there's no computational benefit, it doesn't matter, but for some it certainly does. I was thinking we should solve this generically, since there's similar situations (backwards compatible stereo ports, perhaps?). The hypothetical "poly-port" (polymorphic port) extension would add a function which lets the host say a port is connected to a buffer for a particular port type. The optional port types would be listed by a different property, so unless this function is called, they would appear as normal ControlPorts to an oblivious host. Something like: # Plugin data _:someport a lv2:ControlPort ; pp:supportedType cv:CVPort . # Plugin code void set_port_type(LV2_Handle instance, uint32_t port_index, uint32_t port_type_urid) { ... } Thoughts on this welcome, I plan to use it for my blop port. Variants suck! Anyway, sorry this took so long, I've been spending so much time on LV2 infrastructure stuff there's not much left to work on my own programs :/ -dr [1] http://lv2plug.in/ns/ext/cv-port#CVPort _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev