Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Dave Robillard (drobilla_AT_connect.carleton.ca)
Date: Thu Jan 15 2004 - 01:22:09 EET
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
This archive was generated by hypermail 2b28 : Thu Jan 15 2004 - 01:22:50 EET