14 Jan
2004
14 Jan
'04
7:24 p.m.
On Wed, 2004-01-14 at 17:16, Steve Harris wrote:
I agree. The S in ladspa is the most important letter in there :).
But, how about we just pretend you didn't even mention the word "UI".
That's what killed the last LADSPA polyphony/misc improvements
discussion.
Anyway, the UIs can't control multiple instances if the simple audio
stuff underneath (ie current LADSPA plugins) can't handle it. _That's_
what we need to look into IMO.
Agreed 100%. Unfortunately, like you said, LADSPA changes. If plugins
are to get more versatile and have more and more control/audio ports,
some mechanism to ignore ports is definately needed.
If I'm just using an oscillator to get a sine wav, it's pretty wasteful
for the plugin to be calculating exponential _and_ liner FM, PWM (pulse
width), and bob knows what else.
I agree, metadata streams = bad bad idea. Unless it can be shown to be
absolutely necessary (which for the record I really doubt). Maybe the
current AMS architechture requires this the way it's written, but I
think it's /possibly/ to write a modular synth that doesn't have it, and
just uses good old LADSPA plugins (ie what I described in my initial
post).
I shouldn't even say "modular synth", because such a program would
definately be an awesome effects rack. Having a jack rack except being
able to string things together however you want is something I think
everyone can appreciate.
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.
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). 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