Subject: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: la maalis 11 2000 - 23:19:33 EST
>> 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.
well, i misused the word "declare" here. although in the current
system, the opcode declares itself to be inlined, this is really a
property of the host, not the opcode. What you need is something like
PROPERTY_2_FLOAT_MULT, and if a host that can inline such an opcode
sees this property, it just inlines all uses of it. This is a cleaner,
more "plugin-ish" way to do it. Quasimodo can inline about 40-50
opcodes (all C math operators, with vectors and scalars as either
argument, all conditionals, plus some others).
a host that could do this sort of thing would just load the plugin,
notice the property, then promptly unload it.
note that we are, of course, talking about really "low level" plugins
here - the kind that do multiplication, addition etc. Most "complex"
plugins would do this kind of thing internally in a compiled
language.
>> 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).
OK, so take the construction:
if (variable) {
output = some_opcode (arg1, arg2, arg3);
} else {
output = some_other_opcode (arg3);
}
and explain to me how to represent this in a "flat" format that is not
essentially just assembler, i.e.:
push variable
test
ifzero L1
push arg3
push arg2
push arg1
call some_opcode
jump L2
L1 push arg3
call some_other_opcode
L2
I don't want to have to make anyone write this kind of thing.
>> 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 ?
Well, herein lies the problem that we are really discussing. What
causes a host to load a plugin at all ?
In gtk-quasimodo, a user clicks on a selected module name, and it then
finds the XML file. It uses libxml to split apart the various top
level entities in the file. One of them is the module
implementation. This is parsed by a dynamically loaded language
parser, and the result is an intermediate stage compiler
representation that is ready for Quasimodo's internal compiler and
"run time linker" (the compiler generates something roughly equivalent
to position independent code).
Now, during the parse stage, the "script" parser may find textual
atoms that it determines are also plugins, and will load them. In this
sense, the parser is a kind of host, but a very restricted one. How
so? Because it is going to pay absolutely zero attention to any GUI
that comes with a plugin. It is expecting low level plugins that can
be connected together by the script language, and has no intention of
creating GUI's for them.
By contrast, once the parser has created a plugin for us at the "next
level", it is passed to a host (Quasimodo itself) that is very
interested in its GUI & interconnection properties.
>as i noted before, in a flat model, it
>API really simple. the alternative
>would make the scripting language part
>of the LADSPA api.
I don't think it has to be this way. You can view the process I
described above as all part of the "initialize" routine of a
plugin. Thats certainly how I propose to turn Quasimodules into LADSPA
plugins. The end result is just a pointer to a plugin instance that
can be passed to the "run" method.
All the above stuff would happen when the host loaded the .so file,
and ran the "initialize" routine. For all a host could care, the
plugin may have been written in C++, and dynamically compiled upon
loading. All we need are the elements in the API: what ports does it
use/provide, and function ptrs for the standard plugin methods. The
internals of the plugin are its own business.
Of course, most plugins will be written in C or something like it, and
won't do any of this stuff. But take a look at say, Cycling '74's VST
plugins. They come with their own entire script language and GUI, yet
plug straight into a VST host. Same with DeSPider and ReDSPider for
TDM.
My goal for Quasimodo would be to (1) allow it to accept LADSPA
plugins, (2) make its opcodes LADSPA plugins (3) find a way to let the
modules be LADSPA plugins (*) and (4) allow it to be a LADSPA plugin
itself. This latter step will be rather hard, and may be intimately
related to (3).
--p
(*) one obvious way: a "module compiler" that takes the XML file,
converts it to a C string, puts it at the top of a source file, then
adds a bunch of boilerplate code for the initialize() routine and
other standard API stuff. Then you compile this C source into a .so
file. When a LADSPA host loads the resulting .so file, it calls the
initialize routine, which will (1) dynamically load any other
libraries it needs (2) reads the XML definition stored "within
itself", and (3) proceeds to build ("bootstrap") itself to present
back to the host as a LADSPA_Instance or whatever.
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST