Subject: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)
From: monty (fowlkes_AT_lenin.dabney.caltech.edu)
Date: la maalis 11 2000 - 18:27:45 EST
> Welcome to the world of Csound (and thus Quasimodo). Everything you
> saw in the script for the mixer is implemented via an opcode. Every
> multiply, every assignment, every if, etc.
> Can I say "been there, done that" ? :) There is a really hairy chunk
> of code in the heart of Quasimodo that is a compiler.
ahhh. so why didn't you tell me
that from the beginning :)
seriously, i hope others are
benifitting from this discussion
besides me. if this is just seems
like a "bring charless up to date
with the rest of the world" thread,
let me know.
> I took a few liberties with the everything-is-an-opcode model: in the
> interest of efficiency: an opcode can be declared as "inline", in
> which case we jump into a switch block, and execute the right code
> inline, no function calls. Even so, everything else about the `*' or
> the `if' is handled as if it were an opcode.
so this sort of inlining could take
place in any host under LADSPA as
long as there was a very standardized
library of basic opcode-like plugins
which everyone used.
the only conflict here would be a
desire to support really thin hosts
which perhaps don't have time/space
to inline everything. perhaps an
offline, static "LADSPA plugin
cross-compiler" which could generate
an optimized version of a plugin
composed of plugins for thin hosts
that didn't want to support a
compiler/interpreter themselves.
that way i could patch together
something on my desktop machine,
optimize/inline it, and then
download it into my penguin-powered
nord lead clone.
> no, the script still has to be interpreted even in the scenario you
> are suggesting. a textual list of plugins is not something anything
> can execute - something has to take that list and convert it into some
> kind of representation that can be used by the host. I don't think
> that a textual form that is just a list is very helpful - people
> already complain that Csound is too close to assembler (a very quirky
> assembler too!), and what you're suggesting seems even closer to
> me. Besides, how would you write a conditional as a "flat" structure ?
a conditional as a plugin would take
say two controll signals, compare them
and depending on the output, send some
controll signals to a routing plugin
which would send some audio through one
plugin or another. a conditional just
chooses which branch to evaluate, it's
only a selector switch in a network
(or a crossfader whose control signal
has been passed through a highly non-
linear function).
> Typically the representation you end up with a is linked list of some
> kind; Quasimodo ends up with a linked list of modules which consist of
> linked lists of function pointers.
>
> My plan, when and if we get LADSPA worked out, is to make this
> representation into a linked list of plugins which contain linked
> lists of plugins. Both modules and opcodes will be handled as plugins.
hmm. i'm still unclear about this nesting
of lists. presumably it would allow
arbitrary depth etc. for a host to
execute this effeciently, the LADSPA
spec. has to include a description of
how the plugins are nested. otherwise,
every plugin you distribute includes
a wrapper which iterates over it's own
list of child plugins when this
iteration should really be managed by
the host. every host has to be quasimodo
or every plugin has to have quasimodo
built in ?
as i noted before, in a flat model, it
would be easy to perform cross-plugin
optimizations and also make the plugin
API really simple. the alternative
would make the scripting language part
of the LADSPA api.
if i use quasimodo to "compile" plugins
which are used by others then neither
they nor their optimizer will have access
to the "source" unless they are also using
quasimodo.
charless
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST