Re: [linux-audio-dev] LADSPA 2

On Wed, 2006-04-26 at 19:06 +0100, Steve Harris wrote:
> On Wed, Apr 26, 2006 at 11:18:13AM -0400, Dave Robillard wrote:
> > On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote:
> > > This is why the "plugin" is really a directory, all the stuff in there is
> > > neccesary.
> >
> > On the plugin bundle thing, I've got working C code that takes a path to
> > the directory, parses manifest.ttl, gleams the available plugin DLLs and
> > data files from that, and enumerates all the plugins in the DLL.
>
> It shouldn't be neccesary to actually dlload() the .so file, if it is then
> theres a mistake somewhere.

Sorry, to be clearer loading the DLL was my goal (not the means towards
enumerating the available plugins). Enumerating what indexes
ladspa_descriptor returns is just what I happened to write to be sure I
really did load the DLL successfully.

> > We need to clarify some things about bundles themselves:
> >
> > - What is the significance of the bundle name itself? (We need to avoid
> > clashes somehow)
>
> Yes, its a bit awkward. It would be nice to be able to use URIs, but thats
> not going to wash.
>
> I was planning something like
> [abbreviated plugin name]-[collection name].whatever/
> eg. Amp-swh.ladspa2
> Assuming the number of collections doesnt grow to much, the current thing
> of people using thier initials or similar should work fine. The maintainer
> of each colleaction is responsible for making sure noone else uses the
> same collection name, and that none of thier abbreviated names collide.
>
> If we wanted to go overboard we could do something like
> [abbreviated plugin name]-[64bit hash of URI of one plugin].whatever/
> eg. amp-5491370f050fa849.ladspa2/
> which guarantees uniqueness, but its a bit of a pain, and the plugin bundle
> names will be a bit ugly.

That is overboard, but I guess there's no real good solution to this
that doesn't involve having a URI of some variety as the name, which is
far too ugly.

We do need to prevent people from doing stupid things like calling the
directory "amp" though, so at least a recommendation in the spec is in
order.
 
> > - Do they contain one plugin variant, or any number?
>
> Probably leave it as a matter of taste. Though discouraging the cmt thing
> is a good idea IMHO.
>
> > - One DLL or many?
>
> As many as you want / need.
>
> > I'm not sure about number-of-plugins-per-bundle (though putting all of,
> > say, swh-plugins in one bundle seems counter to the intent to me?) but I
> > will suggest we reccommend that one DLL contains only variants of one
> > plugin (or a group of very similar plugins). Reasoning is to avoid
> > things like cmt.so which has a huge number of completely unrelated
> > plugins in one lib, meaning a host has to link in all that crap just to
> > use a simple amplifier plugin, which is no good.
>
> My intention was to have a pretty much 1:1 correspondance between .so's I
> have now and bundles in the future. ie. most plugins are on thier own, but
> logically grouped ones are in one .so. eg. a buch ov very similar
> oscialltors, filters etc.

The way your plugins are divvied up is fine, but:

> I dont think its neccesary to specify this though, the best natural level
> usually settles out. ie. people see cmt.so, and go "arrrghhh!".

They go arrrrggghhh, but cmt.so remains with no settling in sight :)

I guess in the interests of defining as little as neccessary, it should
go unspecified (though as above a recommendation would be good). Large
bundles are okay because they ease the burden on the user, but I don't
see any benefit of a huge chunk of completely unrelated plugins being in
one .so

As long as we have this nice bundle format, I suppose both a LADSPA repo
site and a 'master package' of all LADSPA plugins can exist (both things
that are requested pretty often), though they would only be able to
usefully distribute binary builds, not source. :/

This is why I'm tempted to suggest that a bundle only contains related
plugins, so a user could easily just install the SWH amp (say on a
resource limited system). There's a lot of plugins out there that are
totally useless for some people, it would be nice if /users/ could
decide what plugins they want installed. But then of course the
directory name problem becomes a bigger one that'd need to be solved
properly..

-DR-
Received on Thu Apr 27 00:15:34 2006