Daniel James interviews two of the developers working on DSSI, a free software standard for virtual, synthesised instruments

With the recent passing of hardware synthesis pioneer Robert Moog, it's a fitting time to reflect on how electronic and synthetic instruments have changed popular music over the last forty years. The children now watching Doctor Who on DVD may not appreciate the impact that the late Delia Derbyshire's work had a generation ago, when composition meant the painstaking splicing of tape loops - loops that were so long, they had to trail out of the studio door and along the hallway of the BBC's Radiophonic Workshop.

Moog's early modular machines were no more practical, requiring frequent maintenance and retuning - not to mention a major logistical operation each time the heavyweight synthesiser had to be moved.

Now those same youngsters can have full access to virtual synthesised instruments, running entirely in software on a generic PC. The triumph of software over hardware is almost complete, and replica synthesisers now run as an application controlled over USB by replica keyboards, complete with fake-analogue dials and patch cables. Thanks to proprietary applications like Propellerheads' Reason for Windows and Mac OS, control of banks of software synthesisers is almost too easy, resulting in a rash of equally generic music filling the needs of daytime TV shows, music-on-hold suppliers and elevator manufacturers across the world. Arguably, members of the free software audio community have more in common with the likes of Bob Moog, his collaborator Wendy Carlos, and Delia Derbyshire, in that they straddle the realms of developer and experimenter, user and artist.

Just as Steinberg's proprietary VST format for effects plugins has its free software equivalent in LADSPA, the VSTi format for virtual synth instruments now has an alternative in the DSSI standard. Pronounced 'dizzy', DSSI was originally proposed by Jamin author Steve Harris and Rosegarden developer Chris Cannam, the acronym standing for Disposable Soft Synth Interface. The word 'disposable' reflected the fact that other standards were supposed to be under development at the time. DSSI was first mentioned in this series of articles one year ago, as synth instruments written for the standard began to emerge. In the meantime, DSSI gained a stable API and the would-be replacement formats failed to make much of an impact.

I'm so DSSI my head is spinning
Sean Bolton has been one of the most prolific authors of DSSI instruments and other related software, with his work including the WhySynth and Hexter instruments, and Ghostess, which is a DSSI host application. "I've been a musician since I was very small, and have dabbled with writing music software since my Apple ][ days in the 1980s. I worked the last decade as a Unix admin and software developer, and have benefited greatly from open-source software. So, I've had a desire to contribute back to the community. I've long been interested in software synthesis, and in the last few years general-purpose PCs finally have become fast enough to do really interesting real-time synthesis. So when I got burned out in my last development job, I decided to take a little time off and write an open-source synthesiser. Now I've got three synths under my belt, and a flat bank account!"

The DSSI project got started for similar reasons to the LADSPA effort. Steinberg's proprietary standards are available to third-party developers, but under terms which are incompatible with the GNU GPL. In addition, most VSTi synths are written specifically to run on Windows or OS X, and are distributed without source code, making the availability of native Linux binaries very unlikely. Chris Cannam explains: "Not long before Steve and I started thinking about DSSI, there had been some very extensive discussions on the Linux audio developers' mailing list about designing a successor API to LADSPA, filling in all the missing bits. I didn't take part at the time, but I noticed the discussion repeatedly got bogged down in certain details - should you represent note event pitches using discrete MIDI-style values, or in raw hertz, or something else? - that almost everyone felt qualified to have a competing opinion on, until eventually the whole thing seemed to peter out rather than reach a consensus."

"So Steve and I decided the only way something like this was going to happen quickly (as I wanted something I could implement pretty soon in Rosegarden) was to come to a decision on each of the relatively uncontroversial bits, ignore anything too controversial altogether for the first cut, and produce and publish ourselves a spec that was unambiguous, with a reference implementation that actually worked. Then we'd sit back and see what feedback we got, and prepare to change our minds about anything we'd included that anyone convincingly described as unworkable. I didn't set about including anything in Rosegarden until we'd already done all of that, as I didn't want this to end up with a VST-style de-facto standard ripped straight from one particular host sequencer that turned out to be really hard to implement anywhere else. We also thought it was absolutely essential to include some support for plugins with custom user interfaces - something not supported by LADSPA - in a way that avoided settling on any particular user-interface toolkit, given how religious a matter the choice of toolkit (particularly between Qt and GTK) seems to be on Linux."

Bolton's motivation was somewhat similar. "I think we all wanted an instrument plugin API that had a realistic chance to succeed like LADSPA has - one that wouldn't just get bogged down in endless discussions of The Right Way To Do Things. Ironically, at the same time Chris and Steve were developing DSSI, I was looking for a soft-synth API to use with Hexter. The VST licensing issue was a show-stopper for me, and so I haven't delved deeply enough into it to know, for example, if the Motif bindings in the VST SDK are actually functional enough to allow development of a native Linux VSTi. After not finding anything, I developed my own simple plugin API - I never really even looked at Apple's AudioUnits format as a possibility. Then Chris and Steve announced DSSI v0.1. It was much superior to my API, so I junked mine and had preliminary code from Hexter working as a DSSI plugin in a matter of hours."

The host with the most
While DSSI can be used for effects plugins in the manner of LADSPA, its synth instruments also need a host application of some kind, since they do not talk to MIDI or JACK directly. Bolton says that Ghostess, like the reference jack-dssi-host code that it's based on, is about the simplest application possible that can provide all the DSSI host features. "I mostly just play DSSI synths 'live', so all I want is MIDI in, JACK audio in and out, a way to show and hide the plugin's GUIs, and a way to load and save configurations - that's Ghostess in a nutshell. I do wish it could chain plugins, so it would be easier to add effects to the synths' outputs. But for now, there's always Rosegarden, JACK Rack or Ardour for that."

Cannam explains that Rosegarden has a number of instrument plugin slots available as track outputs alongside any MIDI devices. "So you just assign a track to one of those, select a plugin for the slot if it doesn't already have one, and you get sound directly from the events on the track. You can then open another window to control the plugin parameters and start up its own GUI. A track playing to a plugin is like a hybrid between a MIDI track and an audio track; you have note events on it just as you do on a MIDI track, but you can also apply effects plugins to the output and control the output level precisely in the audio mixer, as with audio tracks. Anyone who's used VST instruments in Cubase or the like will find it very familiar, although it's not identical."

DSSI and Open Sound Control
Open Sound Control, or OSC, is a network protocol for audio devices. The use of OSC allows DSSI interfaces to send small amounts of data across the network, setting plugin parameters and reporting state. This means that the DSSI host can be on one machine, while being controlled from a GUI on another desktop or a dedicated hardware controller which might resemble a traditional synth, anywhere on the network. The host is responsible for starting and stopping the GUI, as well as communicating with it.

According to Cannam, the additional flexibility provided by OSC comes at the cost of making plugin GUI development more complex. "We do of course document the requirements thoroughly, recommend a particular OSC library, and provide plenty of example code, but we'd also like to provide some more helpful wrapper code so that people can easily throw together GUIs without having to think about OSC at all. There are a couple of projects underway at the moment that hopefully should simplify this greatly, although none is yet available in a neatly downloadable form."

Further complexity is introduced when compatibility with VSTi instruments is required. However, the combination can be made to work using the dssi-vst plugin, as Cannam explains: "dssi-vst consists of a native Linux DSSI plugin; a mostly-Windows-API application using Wine that hosts the VST plugin and its GUI; a communications layer for control and audio between the two of those, so that the DSSI plugin only has to start and stop the Windows application and then send over all the actual processing to it as it arrives; and another native Linux program that pretends to be the DSSI GUI (for the purposes of talking via OSC to the DSSI host) but does no real work itself, instead negotiating secretly with the VST host part to show, hide, and query the VST GUI from the plugin directly."

"The breadth of support for VSTs is not as good as I'd like - that's partly due to the deficiencies of dssi-vst in terms of API support as a pure VST host, something that's hard to do well and even harder when you're also trying to conform to another API that has different expectations for the processing and threading models. The plain fact is that VST support on Linux is never going to be as broad as on Windows, and it would be far preferable to see more native DSSI plugins than to aim to rely increasingly on non-native VSTs."

Bolton thinks the best way for aspiring DSSI developers to get started is to adapt one of the instruments already available. "I'd suggest they find an existing plugin that's close to their development preferences - C or C++, GTK+ or Qt - and just start tinkering with the synthesis code. It gets addictive!"

Daniel James

DSSI project page http://dssi.sourceforge.net
Sean Bolton's software http://home.jps.net/~musound/
Rosegarden www.rosegardenmusic.com