linuxaudio.org

On Tue, Nov 24, 2009 at 11:04 AM, Paul Davis  wrote:

quoted text
> On Tue, Nov 24, 2009 at 10:53 AM, Adrian Knoth

>  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.

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev