Re: [LAD] [ann] CAPS 0.4.5

On 03/04/11 04:34 AM, Stefano D'Angelo wrote:
> 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...
>

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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Apr 5 04:15:02 2011