[LV2] Configurable channels for LV2 plugins

[David Robillard]

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
>         type
>         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 ;
    # etc...
]

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.

-dr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130324/7d7c0a07/attachment-0002.pgp>