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
