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

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