Subject: [linux-audio-dev] Quasimodo (Was: Re: LADSPA GUI)
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: pe maalis 10 2000 - 08:30:15 EST
Interesting comments, ending with:
>my impression is that the large granularity case is a lot more
>interesting. lower level dsp code is better shared as a function
>library than kludged out of plugins. if you want a modular synth or
>a reverberation model, build it and feed it's output into a network
>of other plugins. i would want my audio workstation to emulate an
>entire studio rather than a particular dsp algorithm.
>someone is going to tell me that they want to implement a system
>which supports both granularities. this strikes me as a mistake.
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.
>yes it's probably possible to make a totally generic API which will
>let you interconnect anything and everything just like your old
>modular synth. however, what host is ever going to actually want to
>support a true mixture ?
Quasimodo. Its limitations at a deep level right now are just 2, as
far as I am aware: it is *not* sample accurate (i.e. events such as
incoming MIDI data do not result in changes to the sample stream with
sample accuracy; its not about speed, since in Quasimodo they
typically happen too fast (!), but about accuracy). secondly, you
can't connect a control signal to an audio socket, because control
signals are represented by scalar values and audio sockets by arrays.
> aiming for something totally generic is a
>noble cause but such projects collapse under their own weight or
>never actually get used because they have absurd learning curves etc.
I hope that this is not true of Quasimodo. In that case, what is
holding me back is (1) work on other projects (the RME Hammerfall
driver, ardour, softwerk-on-gtk ...) (2) dilemmas about a better
language to support for the modules than Csound's orchestra language
(3) the need for some better graphics and people to write/improve the
modules that we have now (about 70 in some form or another) (4) the
fact that its a cutting edge system that is hard for other people to
compile who are not weathered programmers and understand how to work
with its myriad of library dependencies.
I would like to think that if a half-dozen people started working on
modules for Quasimodo, and 2 people on some kickass pixmaps, it would
be a compelling studio-ready system in 2-3 months.
>sorry this got so long. i'm new to the list so slap me if i'm out of
>line ..... my interests lie towards a system with a GUI which is
>actually a bunch of hardware knob boxes i can use to control a
>realtime, linux-based sound engine in a live performance situation.
I have very similar interests, but would add to them my current
ongoing work with implementing linux software for use in a commercial
studio as well, where a Mackie D8B is the "hardware box".
--p
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST