RE: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)

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

Subject: RE: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: pe maalis 10 2000 - 21:45:00 EST


Okay, I ought to step up here too - I *also* have implemented a system (MN)
that supports both granularites ;)

The reason you cannot tell the 'granularity' from the API is that LADSPA is
designed to be indifferent (if I understand the term 'granularity'
correctly). If there's a good reason why LADSPA plugins don't work at one
or other of these layers then I've fouled up, so please let me know!

But to be honest, and after those two paragraphs, I don't entirely
understand what makes the two levels concretely different for you. Is it
just whether you expect the user to be more interested in controlling
devices from GUIs or other plugins?

I think the Quasimodo opcode plugin API is good. I think Csound's is good
for its day. It's just that it's fiddly to make them compatible with MN
because they're not light-weight. I'm still hoping to find time to write a
wrapper to let MN load Quasimodo plugins but this will be considerably
harder than supporting LADSPA.

-- Richard

-----Original Message-----
From: monty [SMTP:fowlkes_AT_lenin.dabney.caltech.edu]
Sent: Saturday, March 11, 2000 12:01 AM
To: Paul Barton-Davis
Cc: linux-audio-dev_AT_ginette.musique.umontreal.ca
Subject: [linux-audio-dev] Re: Quasimodo (Was: Re: LADSPA GUI)

> No, actually I am going to tell you that I *have* implemented a system
> that supports both granularities.
>
> Quasimodo (http://quasimodo.org/) supports dynamically loaded things
> called opcodes which are the kind of pure, simplistic plugins that
> people have sometimes referred to here that just implement a DSP
> algorithm and nothing else. They consist of 1-3 functions, typically:
> one used at "instantiation time", one used for control data and one
> for audio data. Many opcodes consist of a single function to handle
> audio or control data. Quasimodo does not come *with* any opcodes - it
> dynamically loads them when it finds references to them in ...
>
> ... dynamically loaded "modules", which are written in some kind of
> script language that organizes a series of opcodes into a program (a
> flowgraph, if you like). Quasimodo compiles the module into "thread
> code" (a linked list of pointers to opcode functions), and then
> installs the module in a higher-level flowgraph that allows
> interconnections between the modules ("patching"). It also reads a XML
> specification of the GUI for the module, builds the relevant interface
> and "screws it into the rack" that Quasimodo presents as its GUI.

i'm certainly impressed with the
quasimodo project. (i've looked
at it briefly before although i've
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. i
would think routing audio signals into
controll ports breaks these layers
with little added utitlity. better
to have a module which uses some
opcodes to generate controll signals
from audio.

my original question still remains..
what granularity are we discussing in
terms of LADSPA? are we interested
in sharing opcodes between hosts or
just modules ? what about the
quasimodo/csound experience do people
find so disasterous as to require a
new API ? even though it isn't sexy,
programming time probably is probably
best spent fixing existing systems
rather than starting over.

charless


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

This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST