Subject: RE: [linux-audio-dev] LADSPA Specs ?
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Tue May 14 2002 - 00:22:13 EEST
> -----Original Message-----
> From: linux-audio-dev-admin_AT_music.columbia.edu
> [mailto:linux-audio-dev-admin_AT_music.columbia.edu]On Behalf Of Kai
> Vehmanen
> Sent: 12 May 2002 16:21
> To: linux-audio-dev_AT_music.columbia.edu
> Subject: Re: [linux-audio-dev] LADSPA Specs ?
>
>
> On Sat, 11 May 2002, Likai Liu wrote:
>
> > Please consider my proposal for array extension of the LADSPA:
>
> As the one who encouraged to "show the code", I feel obliged to give at
> least some feedback, but I'm afraid it's not very positive this time. The
> proposal itself looks fine, but I'm not sure how much interest this gets
> from developers of current LADSPA hosts.
>
> For instance ecasound's own plugin system (on top of which LADSPA plugins
> are mapped) doesn't support arrays, so it would be a major change to add
> support for this feature. On the other hand ecasound already has a
> mechanisms in place for representing envelopes (sequences of control data
> changes) and large parameter sets (ecasound plugins can change their
> parameter interface dynamically during runtime).
>
> So this is my view on the issue. Let's see what other people think...
I agree - rather than put the envelope in the plugin, I'd prefer the
envelope to be in a separate plugin wired up to a port (control or audio).
This is more flexible if someone wants to use a different control shape from
somewhere else.
Array data is a very useful data type - for wavetables, waveshaping, impulse
responses, samples, curves etc. On a par with string and event datatypes - I
use all of these heavily in MN (my particular flavour of host). However,
these are all nontrivial and handled differently by different programs -
introducing each of these types makes it harder for host writers to satisfy
the API and (at the risk of being a complete bore) I'd prefer to keep LADSPA
simple. ;-)
For a general solution, see the first cut of LADMEA
(www.ladspa.org/ladmea/). There are already small problems with it, but it
does provide an API that does pretty-well everything. As a result it's
complicated, over-general and everyone hates it! Maybe I could fix this, but
(1) I'd need to show the code and don't have the time at the moment and (2)
Jack does the simple audio stuff that people really need much more simply
(although I have a feeling there'll be another when the limits of Jack are
struck...).
--Richard
This archive was generated by hypermail 2b28 : Tue May 14 2002 - 00:24:35 EEST