Hi Anthony,
I guess most of us use the sample enumeration c code included with the
LADSPA sources as starting point. This code expects a LADSPA_PATH
variable to be set. As a fallback, I suppose most programmers
added /usr/lib/ladspa:/usr/local/lib/ladspa, but all of them should
support LADSPA_PATH.
On Wed, 2006-12-20 at 15:43 -0800, Anthony Green wrote:
I understand that LADSPA and friends specifically
exclude any
functionality around how to find and load plugins, but it seems that a
lot can be gained by introducing some standards in this area.
As a package of audio apps/plugins for a Linux distro, here are two of
the problems I see:
1. Applications are often hard-coded to look in /usr/lib/ladspa (for
instance), when many systems may require that libraries live somewhere
else (like /usr/lib64/ladspa for x86-64, or /usr/lib32/ladspa for
n32-ABI MIPS Linux). I've had to patch a lot of apps for x86-64 Fedora.
2. We build binaries for the lowest common denominator, so the plugins
you'll find in Fedora, for instance, don't take advantage of SSE
hardware or instruction scheduling for different processors. This can
make a huge difference. What would be nice is if we could distribute an
RPM containing a plurality of plugin builds, and then have the
application load the plugin matching the capabilities the execution
platform.
Has there been any discussion around creating a plugin locator/loader
library? It would be nice if one could be written and then widely
adopted by app writers. (I'm not volunteering!)
AG
--
Leonard Ritter
-- Freelance Art & Logic
--
http://www.leonard-ritter.com