26 Apr
2006
26 Apr
'06
4:53 p.m.
On Wed, 2006-04-26 at 19:06 +0100, Steve Harris wrote:
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.
The way your plugins are divvied up is fine, but:
On Wed, Apr 26, 2006 at 11:18:13AM -0400, Dave
Robillard wrote:
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.
On Wed, 2006-04-26 at 10:38 +0100, Steve Harris
wrote:
It shouldn't be neccesary to actually dlload() the .so file, if it is then
theres a mistake somewhere. 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. 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!".
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-