Re: [LAD] LADSPA plugins in ardour

From: David Robillard <dave@email-addr-hidden>
Date: Mon Aug 10 2009 - 02:31:47 EEST

On Sun, 2009-08-09 at 23:10 +0100, james morris wrote:
> On 9/8/2009, "Fons Adriaensen" <fons@email-addr-hidden> wrote:
>
> >2. The situation is already different for e.g. a compressor
> >or limiter. In that case you would expect the same gain profile
> >on all channels, probably determined (but not always) by the one
> >with the highest level. In other words the channels *do* interact.
> ...
> >Clearly at least (2) requires the plugin to be aware of the situation,
> >and to be designed to handle it. That in turn is possible only if the
> >plugin interface can represent this case. But also case (1) would
> >benefit from being aware of the multichannel use: in many cases the
> >bulk of the work is not the real signal processing but things like
> >limiting the rate of change of parameters, computing and interpolating
> >internal parameter values etc. and all of that can be shared if the
> >plugin standard is designed for it. It's not possible to 'retrofit'
> >this to existing mono plugins by an extension. And finally, a plugin
> >that would do the right thing in case (2) would fail if used in case
> >(3) - it again needs to be aware of being used in this role.
>
> some probably bad ideas:
>
> rather than trying to get a number of instances of the same plugin
> sharing data, is there any way for having a dynamic number of ports
> created within one plugin depending on the context (noof channels) it is
> placed in?

That is almost certainly the way to go IMO. I see no advantage to
trying to make several separate instances of a single plugin work this
way, and it's quite a bit more complicated, and raises some ugly
realtime issues, and generally breaks the whole LADSPA/LV2 model when
you consider static/shared control ports and such. This way probably
has a ton of optimisation issues as well (bunch of process calls instead
of one, plugin code doesn't have direct access to all inputs/outputs,
etc. It's a mess)

Dynamic number of ports, though, is simpler, more efficient, fits well
with static/shared ports, and useful in cases other than this one (i.e.
we need it anyway). I can't think of any cons.

The way AU handles it is analogous to dynamic numbers of ports as well.

-dr

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

This archive was generated by hypermail 2.1.8 : Mon Aug 10 2009 - 04:15:07 EEST