17 Nov
2003
17 Nov
'03
11:58 a.m.
On Mon, Nov 17, 2003 at 03:36:06PM +0000, Steve Harris wrote:
On Mon, Nov 17, 2003 at 04:26:23 +0100, Alfons
Adriaensen wrote:
AMS does not require changes to the plugin code, and does not in any way
depend on the things I proposed. It handles polyphony without any problem
with current plugins that were not specially designed for this mode.
The purpose of my proposition is to enable a plugin writer (if he/she wishes
to do so) to detect when the plugin is used in this way, and maybe optimise
his code. For example, control rate computations (which can be elaborate and
even more complicated than the audio rate code) could be shared by all voices.
I have some plugins that are able to create their own GUI (by using a shared
library that makes them look like a single client to the X-server, and that
also provides a standard set of widgets). Clearly, all instances that belong
to the same module should share the same GUI. The proposed way of using
the standard 'lifecycle' functions enables them to do this correctly.
--
FA
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' ?
Well if it requires changes to the plugin code then it is breaking the
metaphor somewhere - the AMS engine should be able to habdle the
duplication without requireing support from plugins.