[LAD] Lv2 port replication [was Re: the role of lv2 extensions]

[David Robillard]

On Tue, 2009-08-11 at 19:01 +0100, Steve Harris wrote:
> On 11 Aug 2009, at 18:41, David Robillard wrote:
> >
> >> i keep thinking about arrays. passing an array of outputs to  
> >> connect to
> >> the plugin's inputs. null terminated array ( but this would require a
> >> new connect() method in the lv2core, which probably is a bad  
> >> solution ).
> >
> > The connect method takes a void* pointer, so this is fine.  You can
> > stick whatever kind of data you want in ports without needing a new
> > connect method.
> >
> > The question here is probably: array of pointers to buffers, or one  
> > big
> > multi-buffer?  The former is probably more flexible.
> 
> It's more intune with typical DSP code too.

Sold.

> I don't remember offhand whether a float *data[] lets you dereference  
> as data[chan][samp] or not, but that would be nice if it's possible.

Probably not (it would actually be void* anyway), but the header can
provide a nice inline function for this.

> You might actually want a struct of { int channels; float *data[]; }  
> though to keep all the pertinent stuff together.

Good point... this also sets things up to be compatible with
plugin-allocated dynamic output buffers in the future without needing
any hokey mechanism just to say how many are there, which can't hurt.
Maybe we should go a teeny bit further and make the struct extensible,
putting the data pointer first.

Slight overhead in that the number of channels may be shared between
many ports, though.

> Is it possible to specify that a port is both a normal LADSPA Audio  
> port, and a magic multichannel port? If not the back compat thing is a  
> deadend anyway.

I think the port would probably have to be of the MultiPort type, then
either 1) also of another data type, or 2) have a :contentType predicate
to point to that other type.  We certainly don't want a combinatorial
explosion of multi-types.  Probably 2) is needed for backwards
compatibility, but I forget the details of the spec here...

> >> example: a DC offset removal plugin for a stereo stream
> >>
> >> instead of specifying 'in_left' and 'in_right', we just have 'in'.
> >> the 'in' port is specified with portReplicable (or some such). as the
> >> plugin is operating on a stereo stream, two ports are created 'in0'
> >> and 'in1' (or in1 and in2), then these ports are connected as usual.
> >>
> >> the plugin needs to discover if the host supports portReplicable???  
> >> if
> >> the host does not support it, it will do things the old fashioned  
> >> way -
> >> and there'd be two plugins for left + right - so the plugin will know
> >> because the host will give it the number of channels to process.
> >
> > Backwards compatibility is one reason a big multi-buffer (the first  
> > part
> > of which is a single normal buffer) might be good.  Though there can
> > just be a rule something like "if the host doesn't support
> > multi-buffers, the plugin must expect a single buffer", which seems
> > fine.
> 
> Yeah, a little painful to handle, but a utility function can sort it  
> all out.

Well, you'd end up checking the number of channels stored in the
plugin's data anyway, having a case where it's just a plain old buffer
doesn't seem to be that much of an additional nuisance (and the win is
massive).

-dr

P.S. extension and LV2 in general discussions are much more active here
than lv2-dev.  I wonder about the benefit of it existing at all...