15 Jan
2004
15 Jan
'04
6:07 a.m.
On Wed, Jan 14, 2004 at 10:16:39PM +0000, Steve Harris wrote:
Indeed. Emumlating analog modular synths has beem a principal aim for Matthias Nagorni,
the original creator of AMS, and this will remain an essential feature in all future
versions. But it's not the only goal, and I see no reasons why AMS should be limited
to what is possible with analog hardware. Anyway, the metadata I plan to use is there
strictly for implementation reasons only, and will functionally invisible to the user.
My conclusion at this point is that ATM the scope of LADSPA is too limited to be able
to say 'Module == LADSPA Plugin', even if we ignore the GUI aspect. This is not
meant as
criticism on LADSPA, it's just a fact, and as the 'S' implies, probably by
design.
--
Fons
We did discuss this briefly, personally I'm
against plugins implementing
polyphony in this way (though I'l admit its more a matter of taste than
anything else), but a good UI standard should probably address controlling
mutiple plugins (its quite common eg. for doubling up mono plugins to
effect stereo streams) and its possible to share data between plugins, and
even across hosts (eg. my bandlimited osc plugins share the table matrix
where possible).
What I proposed is not a way to 'implement' polyphony -- that is done in the
obvious way by the host creating multiple instances. It is a way to enable
plugins that care about this to discover they are used in a polyphonic way.
Coming back to my original example, if you want a plugin to create its own
GUI without any assistance from the host (and that is ATM the only option with
LADSPA) it *has* to know this, unless you want e.g. 16 or 32 identical
windows, one for each voice.
Agreed, but to be acceptable it probably needs to be
transparent to the
plugin if it doesnt want to know - obvious solutions such as setting
buffers to NULL if thier disconnected are a bit awkward to use.
And that's a pity. Since all ports in LADSPA are pointers, even if they
only carry a single value for each call to the process fuction, setting
the pointer to NULL would have been the obvious way to signal an unconnected
port. But it's too late now to do adopt this obvious convention.
Some of the
functionality I want for the new AMS also requires 'metadata' along
with the audio signals, e.g. to indicate which voices in a poly patch are active
or have terminated. In the current AMS for example, there is a 'hidden' data
path
from the envelope generators back to the voice controller, to signal that a
voice has terminated and can be reallocated. This is why you can't have an
envelope generator in a plugin, as this data path is hard-wired into the engine.
This comes back to wether you believe that the plugins should be handling
polyphony or the engine. Again, probably a matter of taste.
FWIW I'l note that hardware modular systems dont have metadata streams :)