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.
