On Tue, Nov 24, 2009 at 11:04 AM, Paul Davis <p...@linuxaudiosystems.com> wrote: > On Tue, Nov 24, 2009 at 10:53 AM, Adrian Knoth > <a...@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. _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev