M station -----> Steve Harris - LADSPA plugins June 02

Steve Harris talks about LADSPA plugins

Some time back there was a lot of interest in the Linux audio community for porting Cubase's VST plugin format to Linux. It didn't happen for various reasons but what did happen was that LADSPA was developed by Richard Furse in conjunction with various other people on the Linux Audio Developers mailing list. Steve Harris has been the most prolific LADSPA plugin developer and here we talk to him about LADSPA and about writing plugins. related links: Steve Harris' homepage plugin.org.uk - collection of GPL'd plugins Steve Harris' plugin docs www.ladspa.org ... the API etc Jack LADSPA XMMS support Linux Audio Dev mailing list More LADSPA links at Dave Phillip's page

Mstation: Did any particular event get you started on Linux, or did you just gravitate towards it as a matter of curiosity?

Steve Harris: Well, I was hacking on SunOS and Amiga machines around the time when Linux started to get usable ('94), so moving to Linux was a pragmatic thing for me, the Amiga was dying, and Sparc machines are just too expensive. There are some things I miss about the Amiga, consitant hardware was a nice thing, and the 68000 processors were much easier to understand than x86's are. On the other hand, x86 machines are really cheap for the ammount of processor power you get.

The idea of a bunch of apps being able to talk to each other is attractive at a lot of levels including code reuse. Would you like to tell us in a nutshell what LADSPA is?

[ Nothing to do with apps talking to each other ;) ]

yes, that's a little fanciful - I like the idea though!

Jack (jackit.sourceforge.net) does a good job of connecting apps together. Its the only simple, low-latency approach I've seen for linux. Its also very similar in design to Apple's Core Audio, so porting OSX apps to jack should be fairly easy.
LADSPA is a DSP plugin format. It has a very simple design (in a good way) and is easy to learn. When I started writing LADSPA plugins I'd never written any plugins before, though I had written some (non realtime) audio software.
The learning curve is very shallow, much simpler than VST, for exmaple.
LADSPA i/o is through "ports" which can be either audio data (a buffer of samples) or control data (a single sample). Control data is sent at varying rates by varying the size of the audio buffers. All i/o in LADSPA plugins is 32 bit float.

Is it being quite widely accepted?

Yes, I think the majority of serious Linux audio apps that are still in developement support LADSPA. It appreas to be easy to integrate into apps (hosts) too, though I've never tried myself. Even XMMS supports LADSPA now (http://www.ecs.soton.ac.uk/~njl98r/code/ladspa/).

Are there any problems with it's current state?

No serious ones. The most glaring ommision is the lack of default values for control ports: when a host creates the GUI, it has no idea where to set the value. This is being addressed though, and the next version of the standard should have support for this.
Another realted problem which is partly fixed is the GUI issue. Its impossible for hosts to automatically build good GUIs for some plugins: for example the Hermes filter has 30-odd control ports and there's no clue where to put the controls on the screen. There is a proposed GUI standard (LCP), and I've built a couple of demo GUIs in GTK, but no real hosts support it yet, its a bit of a chicken and egg problem I think.
Lastly there is a problem which seems to effect all plugin systems: there's no way for hosts to sensibly categorise the plugins, you can group them alphabetically, or by unique ID, but niether of those is particularly useful. Say you have four compressors, you would want them to be all together, and near the expanders, gates etc.
I have a potential solution to this problem, but I need to build a protoype before I suggest it, and it is somewhat complex.

Does this impact on the order of processing? Let's say we have a situation where ...

Ah, I didn't explain correctly, I just meant for placement in the GUI, not the actualy processing.

... we want to delay the distortion rather than distort the delay (which should sound different!) - are you able to do that?

Actually delay and distortion are orthogonal, it doesn't matter which way round you place them, unless the delay has feedback and is very short.

yes. I was thinking of seperate boxes which usually aren't.
For someone wanting to get a start at writing plugins, what should they do?

I guess the basics here are knowing the plugin API, knowing some C, and then getting knowledge of algorithms to do the job they want to do.
The plugin API is very simple, in fact I write my plugins in an XML format that removes all of the API setup cruft anyway, it's just a case of filling in the blanks.
I would say the only requirements are a reasonable grasp of C, maths skills and good ears. Some of the implementations have realy nasty maths behind them, but on the other hand some of them are very simple.
The thing I find hard is trying to implement things I don't use in my own music. For example, I use compressors very little, so its very difficult for me to debug compressors, as I don't really know what poeple look for in a good compressor.

That is a pretty hard one because people use them in different ways. Some people with some kinds of music actually want to hear them pumping and others would scream at that! I guess most people just want to dampen the peaks and bring the apparent level up a bit without hearing any artifacts or major changes in balance.

Well testing a transparent compressor is comprarativly easy, it's when it comes to a matter of taste that it becomes hard.
Mathematically definable effects are the easiest, you can just build a test harness around them, tweak the code, and watch the numbers go up and down to your heart's content. If you have a short piece of music that shows up a particular sound quality bug, you can *really* grow to hate the music after an hour or two!
There is a perl script that downcompiles the mixed XML and C into pure C in my source distribution.

Like to take us through a simple example plugin?

Sure, I statred writing a tutorial, but haven't finished it yet, I'l describe one of the examples from there [see below]
There is a perl script that downcompiles the mixed XML and C into pure C in my source distribution.


LADSPA plugin example

<?xml version="1.0"?>
      <!DOCTYPE ladspa SYSTEM "ladspa-swh.dtd">	This defines what XML syntax you're using 
      													for this document.
      <?xml-stylesheet href="ladspa.css" type="text/css"?>	This is a CSS stylesheet for the XML, it allows it 
															to be rendered in a readable form by Mozilla and IE6.
      <ladspa>
        	This defines things that use global to all the plugins in the XML file.
          </callback>
      
          <port label="input" dir="input" type="audio">	This declares and audio input port, called input,
            <name>Input</name>	and it's longname (human readable).
          </port>
      
          <port label="output" dir="output" type="audio">	Guess what this does ;)
            <name>Output</name>
          </port>
      
          <port label="gain" dir="input" type="control">	This declares an input control port, called gain, 
															that has a range of 0 to 10.
            <name>Gain</name>
            <range min="0" max="10"/>
          </port>
        </plugin>
      </ladspa>

That's really quite elegant ... let me see if I've got this right. The perl script would grab line 27 (<port label="gain" etc) and declare 'gain' as a variable in the C code, which will be sitting around waiting for an instruction. Is the gain level input as a command line option or can you change it dynamically? How?

"gain" is both a variable in the C source and also a member of the plugins struct. The host program writes parameter values into the plugins gain variable, to make it available to the plugin.
The ports' values are fixed for the duration of the run() call, but they can change between calls. Sometimes it is neccesary to cache some maths betwwen calls and only recalulate if the ports value has changed.

This leads nicely into the plugin architecture itself. Is LADSPA essentially a list of audio parameters together with permissable value ranges?

Well, its a list of ports, all of which can be either control (single value) or audio (a buffer) and some recommeneded ranges. It's perfectly legal to put arbitrary float values into LADSPA ports, but the output is unlikly to be useful!

Let's take your example from the beginning - you're sitting there thinkin you just have to create an amplifier plugin (!). Where do we go from here?

Well, that's probably too simple an example to be interesting, but I would start by thinking about what kind of ports it needs (in this case, an audio in, an audio out and a gain control port).
Then its just a case of writing the DSP code to stitch it together. ie. out = in * gain ;-)
For a more complex example, once I have the idea or suggestion I would start by researching the effect (google, DSP and acoustics textbooks), try to find some papers on the maths, then start writing toy C programs to see what it sounds like.
Once I have a working software solution I convert it into a LADSPA plugin, then it's usually then down to optimising it and taking shortcuts until it will run in sensible amounts of time. I have a modified version of applyplugin that fixes the 0dB issue and reports how many CPU cycles it takes to process one sample.

Cropping the code must be a time consuming process. Crop, listen, crop, listen - are there any objective tests you can apply first?

For some plugins you can just describe the results mathematically, then you can automate the testing, but mostly I spend a lot of time debugging by ear. Unfortunatly there are often corner cases of particular combinations of port values that I miss, so I need bug reports from people who've noticed sound quality problems.

I hadn't thought about about creating more complex plugins but that would be a real test of programming and research abilities I would think. First you would need to identify the sonic components of whatever you imagine and then sit down and code it. Having said that I guess a few well known sounds have actually been accidents that people liked and then duplicated. Have you tried to create a plugin that you've imagined from scratch?

Mostly the're inspired by realworld things, or modular synth patches I've built. There isn't really any "from scratch" as nearly all plugins are (conceptualy) built out of filters, delays and all the usual things, its just how they're "wired" together that makes it special.

Maybe we can summarise by saying (for those that know C), "read the API, read up on the effect you're doing, Code!". I think we're done!

Yep, thats pretty much it.

Thanks Steve.

Bookmark:

post to Delicious Digg Reddit Facebook StumbleUpon

Recent on Mstation: music: Vivian Girls, America's Cup, music: Too Young to Fall..., music: Pains of Being Pure At Heart, Berlin Lakes, music: Atarah Valentine, Travel - Copenhagen, House in the Desert

front page / music / software / games / hardware /wetware / guides / books / art / search / travel /rss / podcasts / contact us