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
