Subject: [linux-audio-dev] exploring LADSPA
From: Pete Yadlowsky (pmy_AT_Virginia.EDU)
Date: Wed Aug 13 2003 - 23:28:53 EEST
Hello,
I'm new to this mailing list, though not especially new to computer music. I
was heavily involved in it some years ago, mainly on the NeXT platform, then
fell away. Out of curiousity, I recently decided to look around and see what
was available today for Linux, audio-wise.
One of the items I found was LADSPA. "A standardized interface for audio
plugin units carried in shared libraries," thought I. "Interesting idea." I
took a closer look at LADSPA and, like any happy programmer, decided that
there are some things about it that I'd do differently. So, to flesh out and
test my ideas, and just for fun, I proceeded to build a LADSPA-inspired
plugin system of my own. I'm writing now to present these ideas in the event
that someone may find a few of them useful, and to perhaps contribute to
LADSPA's evolution:
- I've done away with the distinction between control signals and audio
signals. I understand the performance gains to be had by computing one class
of signals less often than another, but I feel this is a hold-over from days
when computers were much slower than they are now. In my ideal system,
signals are signals and any signal should be potentially applicable to any
purpose. I don't want to be bothered with control vs. audio, either
conceptually or in actual code.
- Somewhat related to the item above, a plugin's run() method computes exactly
one sample at each call, not a block of samples. This is again a matter of
conceptual simplification. I don't want the individual plugin to have to know
anything of process iteration; that job is for the containing infrastructure.
Also, some years ago I started working on some computer synthesis software
and found that when units ("plugins") computed samples in blocks (instead of
one at a time), there was a strange behavior when these units were patched
together in looped delay line configurations. As I recall, gaps would appear
in the audio output, and these gaps would grow in length as the loop
proceeded. I don't remember if I ever discovered the exact cause, but I think
it had something to do with the relationship between the length of a block of
samples and the length of the delay line. Maybe I was doing something wrong,
but going to a one-sample-per-run process made the problem go away. I wanted
the flexibility of being able to patch units together in any sort of
topology.
- Every input port is a mixer/modulator. Since the operations of mixing and
modulating (multiplying) signals together are so often needed, I decided to
build them into plugin input ports. A given input port can accept any number
of connections from "feeders" and either mixes or modulates their outputs
transparently, according to the port's configuration. I believe this
simplifies use of the system and eliminates the need for a special
runAdding() plugin method.
There's more, but this is getting rather long. I'll leave it here for now. If
you've gotten this far, thanks for your time.
-- Pete Yadlowsky ITC Unix Systems Support University of Virginia
This archive was generated by hypermail 2b28 : Wed Aug 13 2003 - 23:30:25 EEST