On Thu, 2004-01-15 at 05:04, Alfons Adriaensen wrote: > On Wed, Jan 14, 2004 at 10:16:39PM +0000, Steve Harris 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). > > What I proposed is not a way to 'implement' polyphony -- that is done in the > obvious way by the host creating multiple instances. It is a way to enable > plugins that care about this to discover they are used in a polyphonic way. > > Coming back to my original example, if you want a plugin to create its own > GUI without any assistance from the host (and that is ATM the only option with > LADSPA) it *has* to know this, unless you want e.g. 16 or 32 identical > windows, one for each voice. >
I agree this would be nice/necessary, for optimization purposes. If you've got 20 oscillators going, there's going to be a whole lot of redundancy going on. LADSPA GUIs are way outside the scope of this discussion though. > > 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. > > And that's a pity. Since all ports in LADSPA are pointers, even if they > only carry a single value for each call to the process fuction, setting > the pointer to NULL would have been the obvious way to signal an unconnected > port. But it's too late now to do adopt this obvious convention. > > > > > 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 :) > > Indeed. Emumlating analog modular synths has beem a principal aim for Matthias > Nagorni, > the original creator of AMS, and this will remain an essential feature in all future > versions. But it's not the only goal, and I see no reasons why AMS should be limited > to what is possible with analog hardware. Anyway, the metadata I plan to use is there > strictly for implementation reasons only, and will functionally invisible to the > user. > > My conclusion at this point is that ATM the scope of LADSPA is too limited to be able > to say 'Module == LADSPA Plugin', even if we ignore the GUI aspect. This is not > meant as > criticism on LADSPA, it's just a fact, and as the 'S' implies, probably by design. I don't mean to be a PITA about it, but... why? I realise you don't think LADSPA is up to the task, but without stating reasons. (My apologies if you did and I missed them)
