Subject: [linux-audio-dev] Re: A Plugin API
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ma helmi 28 2000 - 13:40:26 EST
>there who have tinkered with Csound. I'm a bit surprised you dislike the
>multiple-UG-per-plugin model - it was partly designed to allow Quasimodo to
>load overloaded opcodes (e.g. oscillators with a-rate or k-rate freq
>inputs) in a single file - fine by me though, either way.
Well, in my first super-petty message (the one I deleted, I wrote a
big long description of how this would all (not) work for Quasimodo,
then realized that it would. Why ? The "problem" in Quasimodo is not
overloaded opcodes - these can be handled from within the "run" function.
No, the problem is that there are two levels of "plugins":
* opcodes
* modules
right now, Quasimodo loads opcodes dynamically, in a way that could be
reasonably easily mapped into this system (though it would definitely
be some work!)
modules, by contrast, are currently little programs that connect a
series of opcodes, written in some language. the module is compiled
down to a thread code representation (linked lists of pointers to
functions), and then used. the thread code contains pointers to opcode
functions.
now, there is no requirement for modules to be generated this way: as
long as they as implemented as an object that matches the definition
of a Module, they could be completely hard-coded in C++.
so, stepping back from the details, and assuming a "plugin" model for
both things, we end up with two linked lists of LADSPA_Descriptors:
Module List: #1 #2 ..... #N
. .
. .
opcode #1 opcode #1
opcode #2 opcode #2
opcode #3 opcode #3
. .
. .
. .
opcode #n opcode #n
Now, thats not quite correct, since traversal of the lists of opcodes
may be subject to flow control via logical expressions, goto's
etc. But the basic model is just fine. It just requires that a
Module-level plugin know about the API as well, and use it to
load/execute its own list of opcode-level plugins.
One thing that the both levels (the host, for the module plugins; the
module for the opcode plugins) has to keep track of is the effective
interconnection between ports of each of its plugins. This is
necessary in order to flow-sort the plugins into the correct execution
order. This is not hard, but not trivial either. The library that goes
with the API should probably include supporting functions for this
functionality.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST