Subject: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)
From: monty (fowlkes_AT_lenin.dabney.caltech.edu)
Date: la maalis 11 2000 - 16:12:51 EST
> So, it feels to me as if this kind of organization: a definition of
> the implementation of the higher-level plugin as a program involving
> lower level plugins, combined with a specification for a GUI that
> references parameters within the program, does in fact provide all
> the things that you mention. Note that I am not advocating any
> particular scripting language or any particular XML DTD for this, just
> the way that they are used in the module definition show above.
> step 2 *has* to be scripting language. It needs to contain conditional
> control flow statements, parameters etc. Or am I missing something
> here ?
so i think this gets close. what
happens if i want an 8 channel
mixer ? it looks like you
probably go in and duplicate
the code for each channel fader
as many times as needed. but,
you've got to invent a bunch of
new variable names etc. what
you really want is a nice clean
way to nest modules without
duplicating code.
how effecient can the scripting
be ? it's probably powerfull
enough to implement something like
a convolution but would it ever
be fast enough ? how do you decide
what should be an opcode and what
should be done with the script ?
maybe scripting is the right way
to go but entertain an alternative
just for fun...
imagine making the conditionals,
multiplies, etc. that are inside
the script explicit opcodes. a
mixer channel is just the
multiplication of some controll
signals with an audio signal.
the variables become implicit
(captured by the interconnections).
this makes things like unpackaging /
repackaging very easy. you can
package up a fader for a single
channel then let someone else
repackage them into an 8 channel
mixer without ever having to look
at code.
it strikes me as advantageous to
give the backend a nice flatened
representation to work with rather
than nested modules mixed in with
a bunch of script to interpret.
the obvious thing to worry about
here would be that the host is
spending all it's instruction
cycles jumping in and out of
one line plugins. my thought is
that a reasonably intelligent
host can optimize this away.
imagine the network of plugins
as equivalent to the intermediate
representation in some modern,
multi-target compiler. there
are a million temporary variables
floating around, everything looks
very inefficient etc. however,
because the IR code is the lowest
common denominator, the code
generation phase can easily tile
over sets of operations with
effecient, platform specific
implementations yielding pretty
optimal solutions. if code is
trapped inside modules then you
may never realize you're
performing duplicate computations
which could be coalesced.
charless.
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST