[LAD] LADSPA plugins in ardour

David Robillard dave at drobilla.net
Sun Aug 9 23:31:47 UTC 2009


On Sun, 2009-08-09 at 23:10 +0100, james morris wrote:
> On 9/8/2009, "Fons Adriaensen" <fons at kokkinizita.net> 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





More information about the Linux-audio-dev mailing list