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

From: David Robillard <dave@email-addr-hidden>
Date: Wed Aug 12 2009 - 01:12:29 EEST

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Aug 12 04:15:01 2009

This archive was generated by hypermail 2.1.8 : Wed Aug 12 2009 - 04:15:02 EEST