Re: [LAD] [ann] CAPS 0.4.5

2011/4/2 Tim Goetze <tim@email-addr-hidden>:
> [Stefano D'Angelo]
>>2011/3/29 Tim Goetze <tim@email-addr-hidden>:
>>> 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...
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Apr 3 12:15:01 2011