[linux-audio-dev] LADSPA 2

[Steve Harris]

On Tue, Apr 25, 2006 at 11:58:23PM +0200, Leonard paniq Ritter wrote:
> Ok, some thoughts about the headerfile:
> 
> - i would find it helpful if the header also contained a definition of
> a valid LADSPA URI, along with some examples.

Yes, we were discussing this on IRC an hour or so ago. Any URI is a valid
LADSPA URI, but there are some helpful recommendations.

NB, the header file is just a hacked about ladspa.h, it's far from
finished.
 
> - passing the HostFeatures in instantiate is a bit too late. i wouldnt
> want to instantiate a plugin first to find out if they match i.e. when i
> enumerate plugins to display them in a menu. furthermore i'm not sure if
> it is an audio plugins duty to check the validity of a host. rather the
> host should analyze a static string pointed member containing required
> host features. this way the host programmer can choose the quickest
> method to do a match check. at least i think so.

I think the easiest thing would be for the plugin to list its required
features in the data file, then the host can weed them out without even
getting that far.

The plugin may just choose to modify its behaviour, not refuse, so the
featuers list still should be passed to instantiate IMHO.
 
> - why does the plugin require its own bundle path for instantiation?
> this can usually be deduced from the dl's own runtime image information,
> no? otherwise, an explanation of this choice in the comment would be
> nice.

Can it? I wasn't aware of that, in that case its redundant.
 
> - comments still contain references to set_run_adding_gain

Cheers, I'l fix that.
 
> - LADSPA is an ugly name ;)

Yep.

> after reading this i do not see why a new ladspa header is required.
> there are barely any changes in 2. i think this is going to become more
> confusing than helpful, especially since it will not be possible to load
> ladspa 1+2 plugins in the same host with ease (yes, people do not like
> to fix orphaned code and recompile binaries, imagine!).

It should be perfectly possible to load both. Personally I prefer to
remove obsolete cruft, but its a matter of taste. I did consder just
ignoring the obsolete fields and resusing label as the uri, but its kinda
ugly.
 
> furthermore, DSSI builds upon ladspa. a ladspa 2 enforces also a DSSI 2.
> again, looking at the slight changes that ladspa underwent, i dont see
> what the big fuzz is about. 

Yes, but that's desirable anyway. With some of the (potential) new
capbilities there are less ugly ways to do some of the things DSSI does,
DSSI 2 should be much less complex that 1.

- Steve