[linux-audio-dev] LADSPA 2

[tom christie]

> Sorry, I just dont feel that motivated by this.
No problem :) just wanted to know if anyone else thought it was an
important point.


Two other concerns...


A) There is no built-in way of a host distinguishing between a LADSPA
1.1 and a LADSPA 2.x plugin.  (Unless I'm missing something?)


Would it make sense to change the name of the discovery function?
eg... ladspa2_descriptor() instead of ladspa_descriptor()

That way there's no chance of a 2.0 host thinking it has a 2.0 plugin
when in fact it has a 1.1 plugin.  (Or vice versa with a 1.1 host) 
Either case would cause the host to crash when it calls the
instantiate() function.


B) There is no way of a host distinguishing between a LADSPA 2.x and a
LADSPA 2.y plugin.

Would it make sense for the initial few bytes of the struct to
explicitly declare that this really is a LADSPA struct and give the
major and minor versions for which it was written?  This would allow
the struct to change in the future if neccessary without breaking
things and without needing to change the name of the discovery
function again.

char ladspa_string[7];      // plugin must set this to "LADSPA\0"
unsigned short major_version; // plugin must set this to 2
unsigned short minor_version; // plugin must set this to 0

The host should check for the null terminated "LADSPA" string, and
should ensure that it's version is less than or equal that which the
host supports before attempting to access the plugin.


thoughts?...





On 4/25/06, Steve Harris <S.W.Harris at ecs.soton.ac.uk> wrote:
> 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.
>