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.
