[LAD] LADI

[Paul Davis]

On Tue, Nov 24, 2009 at 11:04 AM, Paul Davis <paul at linuxaudiosystems.com> wrote:
> On Tue, Nov 24, 2009 at 10:53 AM, Adrian Knoth
> <adi at drcomp.erfurt.thur.de> wrote:
>
>> I wonder why Linux Audio always reinvents the wheel. Just look at the
>> Win32 side: VST-Instruments, then put your favourite EQ on the outputs
>> and your mastering compressor somewhere else. Still modular, but
>> provides total recall.
>
> In this particular case, there are some very simple reasons. In fact,
> I'm not even sure that I would call it "reinventing the wheel" as much
> as "trying a different way of doing things than has been done before".
> It happened this for one primary reason: there was (and to a limited
> still is) no plugin API for linux that provides all that is desired by

and just to go a little deeper ... this in turn is caused in largest
part by the absence of a single "event loop" abstraction/API on "bare"
unix systems. windows and OS X defined this relatively early in their
lifetimes (OS X from before birth, windows many, many versions back).
This means that there just isn't a clear path to adding "plugins" that
have to interact with event processing on a "bare" unix system. its
not that it can't be done, its just messy. what has happened instead
is that we continue to have different classes of applications dealing
with event-driven programming in very different ways:

     * command line apps that don't interact with a mouse+graphical
display at all, just kbd stuff
     * applications that use Xlib or some very old widget library that
is very close to the Xlib API in this regard
     * applications that use Qt's event loop
     * applications that use glib's event loop
     * applications that use Qt using glib's event loop (!)
     * applications using some other GUI toolkit's event loop

By contrast, on OS X, there is one event loop abstraction, and no
matter what program you use, if it uses event-driven programming (as
almost any user-driven app will do), it uses that single abstraction
at some layer. Thus, dynamically loading a "plugin" that has a GUI
that has to be a part of the overall app is easy - its obvious what
the "touching points" between the host and the plugin are.

This just isn't true on "bare" unix systems, where the insistence on
choice and flexibility and "developer driven" approaches to almost
everything have ruled out such a common core.