[linux-audio-dev] LADSPA 2

Leonard "paniq" Ritter paniq at paniq.org
Tue Apr 25 21:58:23 UTC 2006


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.

- 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.

- 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.

- comments still contain references to set_run_adding_gain

- LADSPA is an ugly name ;)

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!).

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. 

grumpily yours,

-- 
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org





More information about the Linux-audio-dev mailing list