[linux-audio-dev] exploring LADSPA

[Pete Yadlowsky]

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