[linux-audio-dev] exploring LADSPA

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