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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Mar 12 00:15:02 2012
This archive was generated by hypermail 2.1.8 : Mon Mar 12 2012 - 00:15:02 EET