20 Dec
2006
20 Dec
'06
10:13 p.m.
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.
the "standard" specifies that LADSPA_PATH be used if set. thus, distros
that package LADSPA should set LADPSA_PATH in /etc/profile and its
various equivalents. i am still dismayed that distros (and even Intel)
could not agree on a common standard for the path to "the directory
where system-level 64 bit libraries are installed").
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.
that's hard. but then again .... seems like its the job of a package
manager to identify the correct build to install on processor foo,
right?
--p