[LAD] [ann] CAPS 0.4.5

[Stefano D'Angelo]

2011/4/5 David Robillard <d at drobilla.net>:
> On 03/04/11 04:34 AM, Stefano D'Angelo wrote:
>>
>> 2011/4/2 Tim Goetze<tim at quitte.de>:
>>
>>>
>>> [Stefano D'Angelo]
>>>
>>>>
>>>> 2011/3/29 Tim Goetze<tim at quitte.de>:
>>>>
>>>>>
>>>>> 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...

Tim, you see? David already suggests to use the LADSPA prefix. :-)

However, I think you could happily avoid doing anything special, I can
check if the plugin in question (identified by UniqueID) has more
ports than the current version (this has to be hardcoded into the
bridge), thus making all ports with index >= the old PortCount
connectionOptional in LV2 (that means the bridge makes fake
connections unless the LV2 host does really connect them)... however,
this is possible if you append the new port(s) to the current ones as
Dave suggests, otherwise this just can't be handled even in LADSPA
hosts properly, I suspect.

Stefano