[LV2] Configurable channels for LV2 plugins
d at drobilla.net
Sun Mar 24 13:20:13 PDT 2013
On Sun, 2013-03-24 at 19:16 +0000, Harry van Haaren wrote:
> On Sun, Mar 24, 2013 at 6:24 PM, David Robillard <d at drobilla.net>
> Things would work as you described, but
> you'd configure the group(s) individually. I guess the buffer
> could be an array of pointers to buffers?
> Sound pretty logical.
> So we must define a new lv2:port
> which has attributes of the Port group extension
> -pg:inputGroup or pg:outputGroup
> -pg:group subclass (mono stereo, ambisonic etc)
> -pg:mainInput or mainOutput attributes
I haven't thought about this too much in detail, but something like
that. I think it would essentially still be a port in almost every way,
i.e. would still just use lv2:InputPort and lv2:OutputPort, but a new
type where the buffer is an array of pointers to several buffers.
pg:GroupPort or something.
In a hypothetical world starting from scratch we would maybe want to do
something different/better, but I don't see any obvious problems with it
being as much a normal port as possible, and it's much more pragmatic.
One could maybe argue that we need a fully dynamic port system anyway,
though... that would require a bunch of atom stuff. It's not a bad
idea, but I think some work on the host support level (i.e. lilv) is
really needed for such things to be reasonable.
A conservative solution, with backwards compatibility to a mono
AudioPort, might be something like:
<plug> lv2:port [
a lv2:InputPort , lv2:AudioPort , pg:GroupPort ;
pg:supportsConfiguration pg:MonoGroup , pg:StereoGroup ;
lv2:index 0 ;
By setting a pg:configuration property via the options interface, the
host could configure the port at run-time.
Tricky thing is that lv2:AudioPort isn't a pointer to a pointer to a
buffer, it's just a pointer to a buffer. A binary backwards compatible
format would be an array of buffers, but not being able to connect
in-place would be problematic for some hosts. Another backwards
compatible route is to use the morph extension.
The buffer order would be defined as in the port-group documentation,
though we might want to put all that in a static C header so hosts don't
have to query a bunch of stuff.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Devel