Subject: Re: [linux-audio-dev] Project: modular synth editor
From: Dave Robillard (drobilla_AT_connect.carleton.ca)
Date: Fri Jan 16 2004 - 21:29:13 EET
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)
This archive was generated by hypermail 2b28 : Fri Jan 16 2004 - 21:30:01 EET