Subject: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)
From: monty (fowlkes_AT_lenin.dabney.caltech.edu)
Date: Mon Mar 13 2000 - 00:52:08 EST
just to refocus things:
this discussion probably doesn't change
the API spec but might affect how one
would structure gui interfacing. in
particular, how people would package
complex plugins to make them usefull in
all environments.
the question is what "belongs" inside
LADSPA plugins. i'm to the point of
believing we can probably squash large
grain, heavyweight objects as well as
simple, lightweight constructs into
the same API and have them interact
in a civil fashion. however, just
because we can doesn't mean we should.
in particular, i'm a little uncomfortable
breaking the real-world metaphor of a
studio where i would be unlikely to
solder a transistor directly to the
connector on the back of a mixing
console or harddisk recorder. i can do
it but it's just not elegant. instead,
i'd put the transistor on a circuit board
in a box with some plugs on the back
and then interconnect things.
user perspective:
i want to be able to interconnect
nicely packaged boxes other people
make. i also want to buy packages
of components and assemble them
into my own audio boxes. sometimes
i may want to open someone elses box
and make a few changes.
electron/host system perspective:
there is a bunch of conductors,
i don't care which box i'm in,
just flow through all this at
near the speed of light.
i'm just trying to imagine what sort of
architecture would match this analogy.
in particular, the user sees flexible,
nested components whose schematics he
can share with friends while the host
sees an optimized set of operations it
can easily perform. there are clearly
a lot of paralells here with language/
compiler design.
> True. But one alternative is what DeSPider and Cycling '74 does: the
> plugin is the whole script interpreter thing, and it loads its own
> plugins using some API. What we want to avoid is not this nesting, but
> the use of some "internal API". We want everything that loads plugins
> to use the same API, so that we can mix-n-match. So, the
> script-based systems either have to do the host-within-plugin thing described
> above, or their plugins (which are written in a language that makes
> producing .so's tricky) have to be converted into something else.
> Fine, but what happens when you want to use a plugin which is itself
> designed to use plugins arranged in an interesting fashion ?
>
> MAX and the Kyma have an interesting take on this, whereby they
> collapse sections of the netlist down to a "black box". But I am still
> adamantly opposed to forcing people to build everything graphically -
> its slow, tedious and not very powerful. The only alternative I can
> see is some sort of language to build them, and then we're back to
> square one, right ?
while i agree gui's are tedious to
implement and to use. however, i
would certainly have to disagree that
they are somehow inherently less
expressive than a scripting language.
this collapsing into black boxes is
more or less what i've been pushing at.
if i may distill the conflict we're discussing,
we seem to have two options:
1. we use the LADSPA api as it's
developing. we let people write
plugins in anyway they see fit
as long as they wrap nicely within
the LADSPA
2. we use the LADSPA api as it's
developing. we also try to standardize
some of the internals of plugins by
adding additional specification of how
to package up large plugins which are
composed of smaller plugins. i claim
this can be done with little aditional
cost as long as it doesn't invovle
standardizing a scripting language.
(this doesn't preclude scripting to
generate the package, just no script
in the package definition)
the advantages of 2 have to outweight
the hands-off simplicity of 1. i'm not
by any means stuck on 2. in particular
requiring people to implement an interpreter
or an optimizer on the host is probably too
much. which probably means that we
probably go ahead back to one and let
plugin/host implementers do what they
feel is best.
> yeah, i saw David's answer. But this has to be a joke! If some_opcode
> just added some numbers, then maybe this approach is OK. But if
> some_opcode computes a 2048 bin FFT of a signal, and some_other_opcode
> does convolution with an IR, this is way beyond absurd.
obviously there is some workaround involving
controll signals which bypass a plugin.
however, the argument is more about
representation than about implementation.
from my inexperienced perspective it
strikes me that most in signal processing
algorithms conditionals are only ever
used for massaging controll signals or
as non-linear transfer functions.
to get some idea:
cd quasimodo/modules
grep "if (" *.qm
grep " ? " *.qm
the question is just whether scripting
is the appropriate intermediate
representation for shuffling around
opcodes. below you claim it's the only
good solution. i'm not convinced
implementing a good script interpreter
is easier than implementing a good
optimizer.
> i don't understand your point here. if i have a scripting langauge,
> call it XXX, and I write something in XXX that does something useful,
> and I want to use that thing in an audio app, what can I do ? I can
> either make the audio app able to understand the script language, or I
> can convert the script into some other form that the app can handle.
my point was that a hardware synthesizer
into which i've downloaded some plugins may
not be a good environment to be running
interpreters/compilers in.
> i wrote quasimodo mostly as a pulsar/nord lead clone, and i consider
> that to do this job well, there has to be script language for connecting
> the small pieces into useful programs.
> I think its good for us to dream. But I don't know of any host of any
> plugin API that could come close to this. Its an interesting CS
> challenge, but it strikes me as far over the horizon.
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...
charless
This archive was generated by hypermail 2b28 : Mon Mar 13 2000 - 08:23:00 EST