Subject: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)
From: monty (fowlkes_AT_lenin.dabney.caltech.edu)
Date: la maalis 11 2000 - 03:19:22 EST
> >never used it). my point was simply that there is a difference
> >between modules (complete black-boxes) and opcodes (dsp library with
> >a standardized interface). without looking at the code, i assume the
> >interface between modules is different than the interface between
> >opcodes.
>
> currently yes, but i see no reason why something like LADSPA could not
> be used for both. it will need some careful thought, because of the
> requirement mentioned in my last message for an intepreter/compiler.
ok. this is starting to clear up a
little bit in my mind (clear up a
bit in my little mind) ... so what we
really want to do is build up "large"
plugins out of "small" plugins.
it seems to make a lot of sense
to provide a standardized way of
packaging low-level building blocks
into modules. i think this packaging
probably needs to be part of the
specification shared by all hosts.
such a package would ideally describe:
1. any low level building blocks
that weren't in the "standard library"
2. the interconnection between
low level building blocks.
3a. a way to coalesce the control
signals into something intuitive
to expose to the user.
3b. zero or more guis to bind to the
coalesced controll signals which
would be usefull for some hosts.
my understanding is that quasimodo does
2,3a, and 3b using interpreted scripting.
how would you improve on this ?
one solution::
combine 2 and 3a rather than hiding
3a inside a gui. this lets us feed
the output of some blocks into the
controll ports of others. it also
provides the user with access to
controll details rather than hardcoding
them in the gui.
encode 2 and 3a in a standardized
XML data structure rather than a
scripting language. we encode two
things, the interconnection of basic
blocks and labels on the controll
signals which need to be routed to
specific chunks of uniquely identified
gui. hosts can map these labels to
appropriate guis if available or just
ignore them.
why would we want to standardize the
packaging in addition to the plugin
API itself ?
1. if we don't standardize the packaging
then people have wrap little networks
of basic plugins with their own code
which performs identical functions to
the host (shuttling data among them)
and then implements the plugin API.
2. if we do the host gets a nice flattened
version of the heirarchy. this allows for
runtime optimizations which coalesce
building blocks which would otherwise
be hidden in seperate monolithic modules.
3. it promotes experimentation with the
internals of more complicated plugins
without touching any C code since you
could easily unpackage a plugin.
4. it makes platform specific optimization
easy. you only have to optimize the
basic building blocks and you get all
the modules for free (this is presumably
true for the quasimodo architecture)
5. well known benifits of code reuse.
build plugins out of plugins.
charless
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST