Re: [linux-audio-dev] LADSPA 2

From: Leonard \ <paniq@email-addr-hidden>
Date: Wed Apr 26 2006 - 01:33:50 EEST

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
Received on Wed Apr 26 08:15:08 2006

This archive was generated by hypermail 2.1.8 : Wed Apr 26 2006 - 08:15:08 EEST