RE: [linux-audio-dev] Re: A Plugin API

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: RE: [linux-audio-dev] Re: A Plugin API
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: ma helmi  28 2000 - 19:26:46 EST


I don't see how overloaded opcodes can be handled using the run() function.
How can the opcode tell which case is which? I suppose the API could be
extended but this would increase complexity and personally I'd like to
avoid that where possible. Incidentally, I shoved a comment in to prohibit
a socket being both a control/audio socket when I was prohibiting
input/output combination. I probably should have pointed out the edits
specifically.

I must admit I'd not considered the plugin API for use at module level in
Quasimodo - I'd only been looking at the opcode layer. It would be very
cool to have it working at module level though.

I don't see what else the plugin can do to help out flow control - I'd have
thought that was fundamentally the host's problem. Unless I've forgotten
something (very likely), the current API provides all the basic information
about the plugin that MN needs, but I appreciate that other hosts may be
organising themselves using different approaches.

By the way, I've just realised that the API can be further simplified by
using an array of character arrays rather than the get_port_name()
function.

-- Richard

-----Original Message-----
From: Paul Barton-Davis [SMTP:pbd_AT_Op.Net]
Sent: Monday, February 28, 2000 6:40 PM
To: Richard W.E. Furse
Cc: linux-audio-dev_AT_ginette.musique.umontreal.ca; 'David O'Toole'
Subject: [linux-audio-dev] Re: A Plugin API

>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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST