OCTAL and LADSPA

[David O'Toole]

> > plans to implement MIDI i/o or a LADSPA plugin interface?  I might be
> > able to help with those things, or whatever else needs work.
>
> Sorry for the scarce knowledge I am
> showing, but what are LADSPA plugins?

They're plugins that do audio like Octal plugins, but using a different
API. I think there will eventually be a wrapper to use LADSPA effects in
Octal.

LADSPA is an effort put together by the LAD list (linux audio developer.)
The other letters stand for Simple Plugin Architecture. It was started
around the same time Octal was, in late 1999. I've been in touch off and
on with the main people involved since then. The LAD list folks have done
a good job promoting LADSPA and at the moment a lot of audio projects have
implemented wrappers.

One recurring issue that I sometimes get asked about is why I've developed
Octal's plugin API even though LADSPA exists.  I've not discussed it much
on octal-dev, so I thought I would post some of my thoughts on it for
those interested. (Nobody asked :-) but it will help point out contrasts
between the API's.)

What follows is paraphrased from an email I sent to Jorn
Nettingsmeier a while back. Keep in mind my intent is *not* merely to
criticize Ladspa, because it is a good project. My intent is to give
reasons for why it does not currently fit the needs of the Octal project.

---

Things I like about LADSPA:

-- Simple and general
-- A *great* deal of thought has been put into its treatment of realtime
performance, including hosts that require "hard realtime" performance with
very very tiny latencies (i.e. latencies smaller than the stock linux
kernel will currently get you.) Some of these ideas have inspired bits of
Octal as well, like the memory allocation wrappers.
-- Based on shared objects rather than its own weird IPC framework or
CORBA or something
-- Doesn't try to be its own operating system

Things I don't like about LADSPA:

-- It was designed without a user interface in mind. There is currently no
standard for plugins being able to describe their user interface, either
in terms of textual representation (hex? 2 digits? 4 digits? on/off? note
value?) or what graphical widget will be used to interactively edit it
(slider? spin button? dropdown option box with several text options
instead of numbers? 2-D slider controlling two parameters at once?)

How do you view or edit a list of events for a plugin without standardized
ways to render them as text? Certainly not by just printf()ing all floats
(LADSPA's only data type.)

Octal has both of those things, for tracker editing and GUI control boxes
(respectively.) This means that I can implement Octal right now
and indeed the relevant code works now. (The parts that are finished that
is.)

LADSPA does contain an extension mechanism to attach
"properties" to a plugin's parameters, but it doesn't specify any GUI
properties yet. The group is working on adding this, but it revolves
around creating a general XML DTD for user interfaces and even support
for pixmap-based skins. The skins argument is another email ... suffice
it to say that I think they are usually a waste of time especially if your
toolkit supports consistent themes. To implement them you essentially have
to create a new toolkit.

-- It doesn't seem to have any music-related features at all. In
particular there is no standard note format and no tuning mechanism.
No way of controlling multiple voices in a single machine, with note ons
and note offs on different tracks.

This isn't likely to be a big problem for effects, but it's fatal to
synths. You could specify what integer is middle A, and which frequency
that is, but again, hosts + all plugin writers would have to agree on a
convention for it to work. Octal plugins have a standard note format and
a mechanism whereby the host provides frequencies. Thus allowing
nonstandard tunings (to match a recorded instrument performance, for
example, or to do something completely wacko.)

-- This is actually related to the last one. There's no mechanism for
callbacks or other ways a plugin can get services from the host. (I
suspect this stems from LADSPA's aim of being a common-denominator API...
the less you want to specify about the host, the fewer features you have.

(It is good in that certain kinds of plugins could probably have a wider
audience by using LADSPA, but anything with larger requirements must look
elsewhere.)

The biggest result of this is an issue that came up on the LAD list at one
point. Not only is there no agreement on how to get access to a wavetable,
but there is no standard mechanism for even calling that function. Without
a feature like this, you cannot implement a tracker in LADSPA, or anything
that shares some global musical resource like a wave or instrument or a
track from the hard drive.

-- No plugin-wide initialization phase (ironically, this is very important
for implementing plugin API wrappers)

-- As far as I'm able to tell there's no standard C++ wrapper (although I
bet somebody has put one together.)

-- LADSPA ports have no standard semantics. By this I mean that you just
get a list of them, with names, without the host or UI knowing which lefts
and which rights go together if you have multiple stereo signals, or how
to connect a mono output to a stereo input or vice versa. Thus connecting
things together in a LADSPA host, I suspect, will probably rely on
dragging lines from one little 4-pixel-wide-labeled audio port to another
4-pixel-wide labeled audio port, probably hitting the wrong one in the
process. This results directly from trying to allow GUI control of
lots of arbitrary named ports without the host imposing any meaning on
them. It's a "visual CSound" kind of feel, and all the apps I've seen like
this have real usability problems.

(Side issue: apps that mix control + audio ports tend to have "sequencer"
as one of the unit generators... i.e. you connect each parameter from the
sequencer to the desired plugin. Try doing this when almost all plugin
instances need sequencing, and where some of them have many parameters
(a complex synth.) Instant graph paper. It sucks.)

Octal's approach is a bit more like UNIX pipes. There are standardized
inputs and outputs for particular purposes. Any port can be either mono or
stereo. The standard and Auxiliary inputs are distinct; otherwise, pumping
multiple signals into one input causes them to be automatically mixed,
with amp controls. Output ports may go to more than one place.

(The UNIX analogy can be taken further. Octal is like a shell; plugins are
like the commands. A song is a shell script. Doing things the
LADSPA/CSound way would be analogous to having to specify the file
descriptors for stdin/stdout/stderr in any command line.)

The resulting user interface is highly usable. Shift-drag to connect an
output to an input, alt-drag to connect an output to an AUX input. Buzz
had something similar, and its mixer interface was very powerful and very
usable. The one hack that they needed was an auxiliary input bus (for
vocoding-type stuff) and so Octal will include that as part of the base
system.

This port issue is one of the things I feel strongest about. I think that
Buzz was so successful because it took unit generators and gave them a
sensible interface. Buzz had other problems, and I intend for Octal to
remedy them if possible, but the mixing interface seems to me the
important part.

To me, all these things make LADSPA's future look dim as a general
*music-oriented* plugin interface.

---

Now, this is quite a laundry list :-). Realistically there is no reason to
expect LADSPA to have these features if it is not designed for musical
tasks. Thus this is not a criticism of LADSPA, but a justification for
OX_API.


-- 
@@@ david o'toole
@@@ address@hidden
@@@ www.gnu.org/software/octal