On Wed, Apr 26, 2006 at 12:33:50 +0200, Leonard paniq Ritter wrote:
> On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote:
> > 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 ;)
It's certainly allowed to refuse, it would just be bad manners, unless the
host has ignored the required features list.
> > > - 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.
>
> 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.
> 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.
There is no LADSPA "system", its just a specification, so theres nothing
to be replaced. All LADSPA 1.x software will be unaffected.
> 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?
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
Received on Wed Apr 26 12:15:02 2006
This archive was generated by hypermail 2.1.8 : Wed Apr 26 2006 - 12:15:02 EEST