[linux-audio-dev] LADSPA 2

[Steve Harris]

Sorry, I just dont feel that motivated by this. We have a bunch of code
and experience around the struct format, and we know were going to need
something equivalent for the forseeable future, so I dont see the point in
changing it over just for the sake of it.

Sure, for some possible future ABI-incomaptible extension we might want to
add functions, but equally we might not.

- Steve

On Tue, Apr 25, 2006 at 11:28:47AM +0100, tom christie wrote:
> Okay, I ought to have qualified my 'will always break...' that's
> clearly not true.
> But there is still real inflexibility in using a struct based API.
> 
> eg. Say a developer comes up with a nice extension (perhaps to allow a
> plugin to deal with multi-channel IO / non-causal audio effects /
> alter the audio frequency / support an 'end of stream' marker / midi /
> GUI / accessing metadata via function calls / or whatever...)
> 
> With the struct based API the only way(*) for that extension to make
> it into LADSPA is for it to be part of the the struct in the next
> version of LADSPA.  We want to keep LADSPA simple, so that's unlikely
> to happen.
> 
> With the library call based API the developer defines and advertises
> the functions that make up the extension, and if it is useful hosts
> will start to implement it.  If it proves it's worth it can be adopted
> as an official LADSPA *extension*, which hosts can choose (or not) to
> implement.
> 
> The core API remains simple and unbloated, but LADSPA can still develop.
> 
> (*) Yes there is trickery that could be played with, eg. using
> multiple discovery functions, but that's just icky.