Subject: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Mar 13 2000 - 01:21:41 EST
"Quick" reply before i go to bed.
>i certainly defer to the experience of you and others on this list.
>being a newbie to the discussion, i just feel obligated to throw in
>some ideas and stir it up a little bit :) just keep thinking about it
>.... plugin architectures with dynamic loading seemed to be tailored
>for binary distribution of proprietary software. while it's a nice
>model, maybe we've been a little brainwashed by it. perhaps what we
>really want is more like a standardized programming language with
>libraries which lets us exchange source code and compile into
>effecient platform specific representations for execution...
i actually agree with most of what you've said. when i started working
on quasimodo, i sort of hoped that it would be able to be pretty much
what you describe here, with the only real difference being that it
was efficient enough to not need native compilation. i really was
optimistic that i would be able to show everyone that it was the ideal
environment for doing almost all audio work.
however, even if quasimodo could be that (which is far from obvious),
its very clear from the myriad of other projects that nobody is going
to be able to mandate a single language for this stuff. stefan and kai
and richard and tim janik and div and benno and david and everyone
else will have their own pet preferences about exactly what that
language should be and how it should be used, what the basic building
blocks should be, and how you access it.
tying people to a language and a library seems to me to generally to
be an invitation for them to go off and reinvent/reimplement it :)
perry cook's Synthesis Tool Kit (STK) from CCRMA at Stanford is sort
of related to what you're talking about: it consists of a libraries of
C++ code that can be used with C++ to easily build complex synthesis
and processing programs.
but thats not what the plugin API is for. its so that anyone can write
anything they want, and as long as it matches the API, it can be used
by another object/program that hosts the API. it really is time that
we stopped inventing the wheel over and over and over again.
thats why i have been very open about my intention to get quasimodo to
host LADSPA/MuCoS plugins, as well as my recent work to modularize its
language handling (it dynamically loads language parsers now as
well). that way, even though quasimodo may not be everybody's tool of
choice (which is quite understandable) it can use the same useful
plugins that other programs can. Richard can write stuff intending to
use it with MN, but user's of Kai's ecasound and derivatives will be
able to use it too. Likewise, hopefully, aRts users and people playing
with, oh, maybe even XMMS!
the VST world has had this for some time, and it has revolutionized
audio programming under Windows and MacOS. we need the same thing,
even if along the way, we bump into the killer standardized
programming language with good libraries.
that doesn't mean that we should stop once we have VST-like
functionality. i think your ideas about transparency of complex
plugins are great, and if we can get there, we should go there too.
--regards,
--p
This archive was generated by hypermail 2b28 : Mon Mar 13 2000 - 08:58:19 EST