[linux-audio-dev] Project: modular synth editor

[Dave Robillard]

On Wed, 2004-01-14 at 17:16, Steve Harris wrote:
> > 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).

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.

> > 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.

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.

> > 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 :)

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.

> - Steve