[linux-audio-dev] LADSPA 2

[Steve Harris]

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

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

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

- Steve