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

[David Robillard]

On Tue, 2009-08-11 at 20:54 +0100, Steve Harris wrote:
> On 11 Aug 2009, at 20:09, David Robillard wrote:
> >> 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.
> 
> Yes, actually if it has to be the same on all then giving it the  
> oportunity not to be is not ideal, but if it /can/ vary then it's  
> conceptually best to have it close by, IMHO.

Agreed.  It's probably best to allow it to vary.  I suspect that
different groups of ports varying separately will be needed by larger
plugins.  Some have synthesis sections and effects sections, or multiple
'mixer strips' and the like, for example.

> >> 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...
> 
> I'd be tempted not to shoot for back compat here. It's hard to see  
> where there's a clear win over just having two plugins, with  
> a :isMutliChannelVersionOf predicate or similar, so the host can pick  
> the right one intelligently.

Meh, I'm thoroughly sick of multiple versions of the same plugin.
Control vs audio is next against the wall :)

It's probably straightforward to make it so that plugin authors can do
it however they want, anyway.

> >>> 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).
> 
> Is the win massive?

I see a great deal of existing plugins that would make sense to
replicate, so I would say yes.

> > 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...
> 
> Well, stuff that gets discussed there tends to be a bit more indepth.

True.  Just a thought.

-dr