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 ;) > > > - 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. alternatively the host could be required to chdir to the bundle folder before the plugin is being instantiated? > 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
