Subject: Re: [ecasound] LADSPA labels naming conflicts / -el option
From: Jan Weil (jawebada_AT_mailbox.zrz.tu-berlin.de)
Date: Mon Jan 12 2004 - 01:47:09 EET
Am Son, den 11.01.2004 schrieb Kai Vehmanen um 23:17:
> On Sun, 11 Jan 2004, Jan Weil wrote:
>
> > there is a problem with ecasound's ladspa support.
>
> ... or possibly not. :)
>
Or possibly still? ;)
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.
On my systems this hides some of my plugins!
> > Ecasound assumes that a plugin's Label is globally unique.
> > This is not true.
>
> Actually Ecasound doesn't, only the '-el' option does. Fortunately there
> is also '-eli:plugin_unique_number,param-1,...,param-n' variant, which can
> be used to uniquely identify plugins. This has been available since
> v1.7.8r12 (Feb/2000).
Parsing map-ladspa-list I cannot tell that there is an amp_mono in
/usr/lib/ladspa/amp.so because it is 'hidden' by a duplicate entry of
amp_mono from /usr/lib/ladspa/cmt.so.
I have been and I am still aware of -eli and I would use it if
map-ladspa-list provided me with the plugin ids but it does not.
As you may remember I'm still working on my frontend (and I am looking
forward to my first public release soon - I currently feel like 85%) and
I depend on map-ladspa-list.
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().
This makes sure that I can access all my plugins through
map-ladspa-list.
Would you apply this three char patch?
Or would you prefer a 'map-ladspa-id-list'?
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.
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.
But currently I cannot even be sure of the chainoperator's type
(internal/preset/ladspa).
While you can control the naming scheme of your internal operators you
cannot be sure if someone writes a sophisticated LADSPA plugin and feels
like calling it "Amplify".
Now imagine, my frontend calls cop-list to find out which operators
there are for the currently selected chain and it is told:
'Amplify,Amplify,Amplify'
How is my frontend supposed to know whether it has to render the control
dialog for your internal amplifier or that for the new ingenious LADSPA
plugin?
(To be honest the cmt set already contains a 'Flanger' by Steve Harris
and your -etl also appears as 'Flanger' in cop-list.)
I think there should be something like
virtual std::string CHAIN_OPERATOR::unique(void)
and this should be part of cop-list/cop-status.
I'm not sure if I made myself clear. :|
Jan
This archive was generated by hypermail 2b28 : Mon Jan 12 2004 - 01:46:20 EET