[linux-audio-dev] LADSPA: proposition for polyphonic use of plugins

Alfons Adriaensen fons.adriaensen at alcatel.be
Mon Nov 17 15:26:23 UTC 2003


On Mon, Nov 17, 2003 at 03:01:40PM +0000, Steve Harris wrote:

> > I'd like to propose an extension of the LADSPA specs, or more correctly, a
> > particular interpretation of the current specs, in order to support the use of
> > plugins in a 'polyphonic' context.
 
> FWIW, I dont think this is the correct way to support polyphony in a
> modular system. It works ok for special puprpose soft-synth plugins, but
> LADSPA is missing other things to make that viable.

What exactly do you mean by 'this' in the preceding sentence ?
Anyway the method I outlined works perfectly with the modules I tested.


In an ideal world, I'd prefer another method such as

instantiate (plugin_handle)

where the argument tells the new plugin which group it is in.
But that would not be backwards compatible.


> Other modular systems I've seen have a polyphonic block, eg:
> 
>                          -------------------
> in -> mono processing -> | poly processing | -> mono processing -> out
>                          -------------------
> 
> The poly processing block is repeated once for each voice (with duplicates
> of its inputs, and its outouts mixed), and the mono sections only exist
> once per patch.
> 
> The division between mono and poly sections can either be a magic module,
> or a flagged subpatch. In the simple case (everything is duplicated per
> voice) the poly processing block is the whole patch, but often LFOs and
> things exist globally.
> 
> This works well, and doesnt break the "module" metaphor.


This is exactly what AMS is doing in polyphonic mode. Most internal modules
(PCM out is the obvious exception) are created as many times as there are
voices, but still look like a single module to the user. Plugins can be
created 'monophonic' (e.g. a reverb) or 'polyphonic' (e.g. a VCF). In the
latter case all voices receive the same control parameters from the GUI.
At the border between a mono and a poly module, signals are duplicated or
mixed as you describe. Nothing special has to be done by the user.
Where does this 'break the module metaphor' ?


-- 
FA






More information about the Linux-audio-dev mailing list