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
