14 Jan
2004
14 Jan
'04
6:20 p.m.
On Wed, Jan 14, 2004 at 09:35:27 +0100, Fons Adriaensen wrote:
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).
Wouldn't
number of voices and finding out if a port is connected be
internal to the app? These things can (actually have to) be stored. As
far as storing, this kind of information would go in the patch file
(.ams), not the plugin. Am I missing something here? Besides, since
you've got LADSPA plugins working... well, it must be possible ;).
You can of coourse use plugings in a polyphonic mode, and AMS even implements
a special protocol that enables LADSPA plugins to discover that they are used in
this way (I have some unpublished plugins that actually use this). But this is
not part of the current LADSPA standard. I proposed it some time ago, but when
I mentioned that one use of this would be to let a poly plugin create only one
GUI for all voices, the thread quickly changed into a discussion on plugins GUIs
and how to make them, and the original proposal was lost in the hassle.
There are other reasons why you may want to know that a number of plugin
instances belong in fact to one polyphonic module. There may be for example
lookup tables or control voltage calculations that can be shared between all
voices. Knowing that ports are unconnected can be important if
this changes the way
the plugin operates, or just to avoid useless calculations on endless arrays
of zeros,
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.
Someting like passing the plugin a valid buffer of zeros, with a known
address (that can be queried and compared by the plugin) would be OK,
but would require API extensions.
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 :)
- Steve