25 Apr
2006
25 Apr
'06
8:02 p.m.
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