25 Apr
2006
25 Apr
'06
7:37 p.m.
On Tue, Apr 25, 2006 at 05:40:59PM +0100, tom christie wrote:
I was imagining they would be in a different path, and as they will be in
.ladspa2 directories, and the .so files are discoverable via the RDF
manifest, theres no real reason why you would find one and not be sure
what version it was, however...
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.
Right, I can't see any reason not to do this.
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
I made a version of the .h that does this (the version thing, not the
header), but I couldn't think if any cases where it was useful - if it
gets as far as the time you fetch the descriptor from the .so before you
find out what the version is thats problaby a mistake. You should be
able to reject descriptors you cant handle before that stage, otherwise it
will annoy users. user: "I want that one", host: "oh, sorry, I dont
understand it"
One of my aims for LADSPA 2 is to remove the need to dlload the plugin
(expensive in CPU+memory, potentially dangerous) until you need to pass
data through it.
- Steve