25 Apr
2006
25 Apr
'06
8:25 p.m.
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote:
i assume the lib file resides in the bundle path or the bundle path has
been compiled into the lib. on win32, GetModulePath can be used to get
the path to the current module, i do not know the posix equivalent to do
that.
alternatively the host could be required to chdir to the bundle folder
before the plugin is being instantiated?
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.
yup.
The plugin may just choose to modify its behaviour,
not refuse, so the
featuers list still should be passed to instantiate IMHO.
if it never refuses then its ok with me ;)
- 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. 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.
i just had a discussion with dave robillard on irc regarding this topic.
my original (silly) wish of just changing the name has now a pragmatical
basis. from my point of view, ladspa 2 is something different than
ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated
plugin on the system. counting the mass of different plugins already
available, it might take up to a year until distros catch up. you could
avoid these migration issues if ladspa 2 had an entirely different name.
none of the previous binaries have to be rebuilt, and can happily bitrot
until no distro is supporting them anymore.
it is maybe neccessary to support future api changes from the start, to
allow soft migrations?
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.
how are parameter boundaries determined now? are all parameters clamped
to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the
comments?
--
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org