On 03/04/11 04:34 AM, Stefano D'Angelo wrote:
2011/4/2 Tim Goetze<[email protected]>:
[Stefano D'Angelo]
2011/3/29 Tim Goetze<[email protected]>:
It is very unfortunate that such a change might break the way your
bridge code works, Stefano, and I would like to apologise in advance.
(If the addition of a 'version' symbol exported by caps.so is any
help, I'll be happy to add that.)
[...]
Regarding the addition of a symbol, introducing something into LADSPA
(because if we agree on something, it's probably going to become a
generic mechanism in the end) is really something I would avoid. It
kind of both defeats the purpose of doing bridging well (i.e., no need
to make changes to existing stuff) and also it would be unfair to
recommend an addition to LADSPA without agreement from the whole
LADSPA community.
Thanks Stefano,
this extra symbol wouldn't be an addition to LADSPA itself. Instead,
it would be one private to caps.so, completely independent of the
plugin standard.
Like so, for example:
void * h = dlopen ("/path/to/caps.so", RTLD_LAZY);
/* assuming h is valid, check for caps */
const int * caps = (const int *) dlsym (h, "__caps_version__");
if (caps)
printf ("found caps version %d.%d.%d", caps[0], caps[1], caps[2]);
Should you consider special-casing for individual plugin libraries a
pragmatic and viable approach, I'd imagine something like this to be
helpful. (Put together, the caps library version and the UniqueID of
a plugin guarantee a stable port signature.)
Ok, it seems like this is the best way to do it after all... in the
hope that this does not become a trend among LADSPA plugin authors.
Best regards,
Stefano
P.S.: using two version numbers instead of three could be of help in my case...
Global identifiers beginning with __ are reserved for the C
implementation...
Might as well just use LADSPA as a prefix instead of CAPS, in case this
needs doing somewhere else... though this whole thing is extremely
awful, and I really hope that is not the case...
Another less awful option would be to somehow add the information to the
library that the port is connectionOptional...
-dr
P.S. Just to verify, the new port index will be a new index greater than
all the old ones, right?
_______________________________________________
Linux-audio-dev mailing list
[email protected]
http://lists.linuxaudio.org/listinfo/linux-audio-dev
