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

[Alfons Adriaensen]

Hello LAD,


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.

The problem to be solved is this:

In a host such as AMS, a plugin can be loaded as part of a polyphonic patch. This
means that there will be as many instances of the plugin as there are voices, but
all of them share the same parameters and user interface. To the user they look as
a single module.

Now a plugin could have resources that can be shared between voices of a polyphonic
instance, but not in general between al instances. For example there could be
precomputed (w.r.t. the sample rate code) tables that depend on a control parameter. 

At the moment there is no mechanism to tell instances of a plugin that they are part
of a such a polyphonic group.


I propose the following solution, which does not require the definition of new
data or functions in the interface. It has been tested with AMS, and works well.
It is also backwards compatible. Plugins or hosts that do not care about polyphony
can just ignore these requirements.


1. Plugins that contain code that is specific for polyphonic use must implement
   all four 'lifecycle' functions, i.e. instantiate(), activate(), deactivate()
   and cleanup(). 

2. If a host wants to create a polyphonic instance, it first calls instantiate()
   for all voices, then activate() for all voices. To remove a polyphonic instance
   it first calls deactivate() for all voices, and then cleanup() for all voices.
   To create or remove multiple instances that do not form a polyphonic group, a
   host always calls both instantiate() and activate() c.q. deactivate() and
   cleanup(), for each instance before dealing with the next.

3. If a plugin detects that its instantiate() function has been called N > 1 times
   before the first call to activate(), it knows that some of the recources created
   by the first activate() can be shared with the other voices. The symmetrical
   treatment of deactivate() and cleanup() helps to keep the 'destructor' code
   simple.


Comments invited !

-- 
FA