Subject: Re: [ecasound] LADSPA labels naming conflicts / -el option
From: Kai Vehmanen (k_AT_eca.cx)
Date: Thu Jan 15 2004 - 05:37:21 EET
On Mon, 12 Jan 2004, Jan Weil wrote:
>>> there is a problem with ecasound's ladspa support.
>> ... or possibly not. :)
> Or possibly still? ;)
Possibly yes. :)
> The problem is not only the -el option but also the map-ladspa-list
> command or more precisely and generally speaking your
> ECA_OBJECT_FACTORY::ladspa_plugin_map(void) uses the
> EFFECT_LADSPA::unique() string as keys which is directly mapped to
> LADSPA Labels without respect to the so file name.
Ugh, do'h, and thought this was an easy case. :) Anyways, you are right of
course. The unique() string is not guaranteed to be really unique among
LADSPA plugins.
> The easiest solution is to simply use
> ECA_OBJECT_FACTORY::ladspa_plugin_id_map() instead of
> ECA_OBJECT_FACTORY::ladspa_plugin_map() in
> ECA_CONTROL::ladspa_descriptions().
[...]
> Would you apply this three char patch?
> Or would you prefer a 'map-ladspa-id-list'?
I'd prefer 'map-ladspa-id-list' as this way we maintain backwards
compability. And available in CVS.
> And while I'm at it there is an IMO even more critical problem at least
> for me and my frontend.
> cop-list and cop-status use ECA_OBJECT::name() to identify the
> chainoperators of a chain.
> This is unique only by coincidence.
Yep, it's not unique. The only unique characteristic is the object's
position in the chain (and of course the chain name and the chainsetup
name).
> To make myself clear: I need a unique mapping to an entry of either
> map-cop-list or map-preset-list or map-ladspa-list.
Hmm, probably the best solution would be to add a new "cop-XXX" command
that would return the type (i.e. cop, preset, ctrl or ladspa).
Another way is to maintain the type info in the client side (assuming
objects are only added through the client).
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Thu Jan 15 2004 - 05:36:55 EET