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.comReceived on Thu Dec 21 04:15:07 2006
This archive was generated by hypermail 2.1.8 : Thu Dec 21 2006 - 04:15:07 EET