26 Apr
2006
26 Apr
'06
3:48 a.m.
On Wed, Apr 26, 2006 at 12:33:50 +0200, Leonard paniq Ritter 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.
thats platform specific though, seems like the plugins shouldn't be full
of #ifdef WIN32 ... code.
There is no LADSPA "system", its just a specification, so theres nothing
to be replaced. All LADSPA 1.x software will be unaffected.
Thier specified by range hints, allowing natural values, and the plugins
are required to accept any value, though not neccesarily do anything
sensibe with it.
We Like It That Way.
- Steve
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris
wrote:
It's certainly allowed to refuse, it would just be bad manners, unless the
host has ignored the required features list.
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. alternatively the host could be required to chdir to
the bundle folder
before the plugin is being instantiated?
Thats likely to cause all manner of excitement.
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?
Perhaps, I think that can be done in the data though.
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?