[linux-audio-dev] LADSPA 2

Dave Robillard drobilla at connect.carleton.ca
Tue Apr 25 22:46:41 UTC 2006


On Wed, 2006-04-26 at 00:33 +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.

++

Definitely shouldn't have to instantiate a plugin to see if you even
want it, especially since (as mentioned) this would make the user
experience awful.

> > 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 ;)

Plugins must be able to refuse hosts and hosts must be able to refuse
plugins.  It's the only way to allow extensions.  I _guarantee_ plugins
will exist that some hosts just don't want (they already do with
LADSPA1), and some plugins will exists that require features hosts are
not required to provide.  This is a Good Thing.

> 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.

While I am with you on the name thing, you don't understand.  LADSPA2
will be completely installable in parallel with LADSPA1.  Obviously it
will not "replace" LADSPA1 on a system and immediately break all the
installed plugins!

> 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?

This, like most everything else, is in the data file.  You really need
to read more than the header before commenting further ;)

-DR-




More information about the Linux-audio-dev mailing list