25 Apr
2006
25 Apr
'06
9:59 a.m.
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.