Playing VST Audio Plugins in Linux
Audio Crossover
Dave Phillips
Playing VST Audio Plugins in LinuxAudio CrossoverDave Phillips |
|
In the world of digital audio software, an add-on component that extends the core program’s capabilities is known as a plugin. A plugin might provide a special effect such as reverb, it might be a MIDI instrument such as a multitimbral General MIDI synthesizer, or it might be an interface to a MIDI sequencer.
A host application and a potential plugin must agree on how, what, and when they will communicate. If program and plugin agree upon a standard application programming interface (API), they happily do their business. An API may be application-specific, such as the plugin APIs for the GIMP and XMMS, or it may be more generally designed for a variety of applications.
Designing an application that accommodates a standardized plugin interface has much appeal to programmers. Applications developers can focus on designing more robust and flexible core frameworks and engines, while plugin developers can focus on the capabilities of their plugins without having to concern themselves with the problems of fitting into a variety of hosts. Of course, users always benefit from this kind of synergy.
In the Windows and Mac music worlds, the Steinberg VST plugin API has become the most widely accepted standard interface. Steinberg’s VST (Virtual Studio Technology) plugin API was first released during the late 1990s; the current VST2 standard arrived in 1999. Its popularity with developers and users can be gauged by a simple Google search for VST plugin. As I wrote this article, the search engine reported “about 187,000” hits. Interestingly, a search on free VST plugin resulted in nearly 95,000 hits.
The Linux world has its own audio plugin APIs. (See the box titled “LADSPA and other Linux Audio APIs.”) However, despite the success of LADSPA and other native Linux alternatives, the sheer volume of audio plugins available through the VST API means that Linux users who are interested in audio sometimes encounter situations when they may really need to run a VST plugin in Linux.
This article shows how to configure your Linux system to support the vast collection of VST audio plugins originally developed for Windows and Macintosh systems.
VST plugins have become expected components in the complete Win/Mac audio studio. Some high-end plugins are now standard pieces of professional audio production, and the availability of excellent free or inexpensive plugins brings high-quality (sometimes even pro-quality) audio processing to the desktop musician and semi-professional studio.
The VSTi plugin API extends the VST plugin definition to allow the plugin to be an instrument (that is, a synthesizer, sampler, or sequencer). As with the VST API, VSTi plugins have become standard components of Win/Mac sound and music software. As shown in Figure 1, a typical VSTi instrument is a software synthesizer, playable via MIDI, with realtime parameter control (manual or MIDI), and possibly multichannel output.
| Regarding Pd |
|
Pd (Pure Data) is Miller Puckette’s excellent graphic patching language designed for creating arbitrarily complex audio synthesis and video processing systems. A/V components are connected via virtual wiring to create a Pd patch, ultimately sending the patch output to your audio and video devices. Linux audio support includes the ALSA and JACK systems, and 3D graphics are supported by the GEM library. |
VST/VSTi support is now common in modern Win/Mac audio software. The number of compliant host applications is simply too large to list here, and a Google search is again recommended. However, one addition to this huge list is of special interest to Linux audio people: VST/VSTi plugins can now be used with Linux sound and music software.
The ability to use VST/VSTi plugins under Linux was first developed by Kjetil Matheussen at NoTAM, a Norwegian acoustics and music research center. Kjetil's initial endeavors led to his vstserver, the basis for a client/server architecture for running VST plugins. The vstserver is based upon capabilities of the WINE library, a part of the ongoing WINE project that aims to create an emulation environment for running Windows applications under Linux. Kjetil also created two clients for use with the vstserver, an “object” for the Pd synthesis/composition environment and a LADSPA plugin that acts as a host for VST plugins. Recently he has added the vsti client to allow the use of VST instruments (VSTi) plugins. Thus, thanks to the vstserver, it is now possible to run many VST effects and instrument plugins under Linux.
Follow these steps to install a vstserver environment on your system :
Each package includes complete details regarding compiling and installing the software. By the way, if you want to use Kjetil’s system, you should download and build his modified WINE sources (available from the vstserver site). The vstserver is critically sensitive about the version of WINE on your system, and other versions may not work with the server at all.
Two minor notes: As indicated in the vstserver documentation, Step 2 requires the Steinberg VST SDK (system development kit). Only two files are needed to build the server, and although the SDK is free, it is not freely distributable and must be downloaded separately. Also, if your VST path is set correctly but vstserver refuses to find your plugins, try linking the server and the vstservant.so object to the same directory pointed to by your VST_PATH setting.
| LADSPA |
|
In the early part of the year 2000, developer Richard W. E. Furse proposed a first design for a simple Linux audio plugin API. His proposal was stimulated and developed by discussions on the Linux Audio Developers mail list, leading to LADSPA, the Linux Audio Developers Simple Plugin API [1]. It is important to stress the term Simple in LADSPA’s name. LADSPA plugins do not strive towards the same degree of complex interaction with their hosts as you’ll find in VST plugins. However, “simple” here does not equate to “feeble,” and there are indeed many excellent and powerful LADSPA plugins. Part of the simplicity of LADSPA is in the way it handles GUI issues: it simply ignores them. The host’s graphics toolkit must provide a suitable basic widget set, but the plugin widget design is left to the GUI programmer. Thus, in contrast to the VST world, a LADSPA plugin is likely to look different when run in different applications, though its use and functions should be the same. By providing no GUI guidelines, the API also makes it possible to use LADSPA plugins without graphics.
Figure 2: LADSPA plugins listed in Hydrogen.Another welcome result of LADSPA’s simplicity has been its ease of integration into new and existing applications. The API was quickly adopted by developers, and over the past four years support for LADSPA has become a matter of course for Linux music and sound tools. The variety of application types that have adopted the API includes hard-disk recording systems, digital audio processors, audio/MIDI sequencers, software synthesizers, soundfile editors, and multimedia players. Realtime response of LADSPA plugins is generally excellent, given the requisite low-latency kernel and ALSA or JACK system. LADSPA developers have accepted its essential simplicity, and the API itself has seen few substantial changes since its 1.0 release. One notable extension is support for the Resource Description Framework (RDF), an excellent mechanism for categorizing a plugin, setting its default values, and providing additional presets. Figure 2 shows RDF at work with the LADSPA plugin list in the Hydrogen rhythm programmer.
Figure 3: The TAP reverb in Audacity.If you’re using an audio-optimized Linux distribution, LADSPA is already installed and configured for your system. Mandrake users can find the LADSPA SDK and plugin collections at Thac’s site (see Resources). But fear not, LADSPA holds true to its simplicity even during installation and configuration. Obtain the source tarball from www.ladspa.org, unpack it in your home directory, and enter your new ladspa_sdk directory. Read the README, follow its instructions, then enter the src directory. Edit the makefile, run make to build the SDK, then become root and run make install. Now you’re ready to install and use some LADSPA plugins. Check out some of the links at http://linux-sound.org/ladspa.html. You’ll want to try Steve Harris’s collection, Tom Szilagyi’s TAP set, Fons Adriaensen’s excellent filters, the collections by Tim Goetze and Mike RawesÖ well, just try all of them. Figure 3 displays the TAP Reverberator opened and applied to a soundfile in the Audacity soundfile editor. Linux also supports some other audio plugin APIs. David Olofson’s Multimedia Applications Integration Architecture (MAIA) was an attempt to address the shortcomings of LADSPA. It was designed as a general multiplatform API, with particular emphasis on UNIX systems. Alas, MAIA’s API did not find a niche with developers, and the project has seen little development since early 2001. The most recent entry in the Linux plugin arena comes from developers Chris Cannam (Rosegarden), Steve Harris (SWH LADSPA plugins), and Sean Bolton. Their Disposable Soft Synth Interface (DSSI) is a “LADSPA for instruments,” as the DSSI Web site states [2]. DSSI is designed to address a variety of shortcomings in existing Linux softsynth support, especially with regard to MIDI control, and the interface also provides a bridge for running VSTi plugins. So far, DSSI has been implemented only in the Rosegarden sequencer, it remains to be seen whether DSSI will find favor with Linux audio software developers. In my opinion it is a very useful API with much promise, and I urge interested developers to read the RFC (request for comments) paper at the DSSI Web site. Figure 4 shows Rosegarden running with an instance of Sean Bolton’s xsynth, a proof-of-concept DSSI synthesizer plugin.
Figure 4: Rosegarden’s DSSI at work. |
vstserver [3]is designed to listen for input from a client application. As I mentioned in the previous section, Kjetil created two clients for use with the vstserver:
I’ll describe these vstserver client options in the following sections.
Start the server by entering vstserver at an xterm prompt. You will see a brief message indicating that the server is ready to receive data from clients. If you have the wonderful Pd [8] installed on your system, you can start it with this command sequence to add the k_vst~ object’s capabilities to the program :
pd -lib k_vst~
This command assumes you’ve opened Pd in your home directory. If you start Pd from a different directory, include the complete path to the object.
Figure 5 shows a VST effects plugin utilized within a simple Pd patch. The patch routes an audio input through the k_vst~ object (i.e., the VST plugin) and out through your soundcard’s audio Out port. You can operate the VST plugin by controlling the effect parameters by moving sliders, turning knobs, and throwing switches, just as you would if you were using the plugin under Windows or the Mac.
Details of the illustrated patch can be found in my tutorial at http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/. Incidentally, I experienced the best audio response by setting Pd’s audio I/O to JACK instead of ALSA. (See the sidebar entitled “Regarding Linux Sound Systems.) If you have trouble with sound breaking up under ALSA while you control your plugins, you should try using JACK.
Using a LADSPA plugin to run a VST plugin may seem weird, but with Kjetil’s ladspavst, we have a plugin acting as a host for other plugins. Ladspavst itself is transparent to the user, but only its functions are important anyway.
Figure 6 shows the NorthPole filter plugin, called from the LADSPA menu in my personally customized Snd soundfile editor. As you can see, each VST plugin is listed as VST plugin [plugin_name.dll] available from vstserver, and I invoke the VST plugin as I would any other LADSPA plugin. As I mentioned, the appearance of the plugin depends on the host’s GUI toolkit. However, the ladspavst plugin provides a switch to use the VST plugin’s own GUI if you prefer.
As I mentioned earlier in this article, the vstserver system also includes a vsti client that lets you use VST instruments (VSTi) plugins. The vsti client works with this simple syntax:
vsti /path/to/plugin_name.dll
Take another look at Figure 1 to see vsti running the Crystal synthesizer. The vstserver is open, and we see the MIDI connections panel provided by Rui Nuno Capela’s qjackctl connecting my MIDI keyboard to Crystal. qjackctl also offers an audio connections panel not seen here that provides a graphic interface for making your audio I/O connections.
| Regarding Linux Sound Systems |
|
The default Linux sound system has recently switched from the OSS/Free (the OSS here means Open Sound System) API to the latest ALSA (Advanced Linux Sound Architecture). ALSA is now the default kernel sound system for the development and stable kernel series from 2.5/2.6 onwards. It may be possible to utilize LADSPA and VST plugins under the older system, but I advise against it, and I strongly urge the use of ALSA as the basis for your audio and MIDI system. ALSA has its own plugin system to extend its capabilities. It’s not a general-application interface, but it serves some very useful purposes. For example, the dmix plugin allows software mixing on systems without hardware support for multiplexing audio sources. Thus, under normal use, my laptop can run only one audio application at a time, but by plugging in the dmix module (in the ~/.asoundrc file; see the ALSA docs for details) I can play multiple audio streams. JACK is an example of truly remarkable Linux audio software development. Originally designed by developer Paul Davis (Ardour, Softwerk), JACK has evolved into the robust low-latency sound server that allows the I/O interconnection of any JACK clients, while also providing a transport control mechanism for synchronous operation of compliant applications. If your audio needs tend towards the professional, you definitely need JACK. artsd and esd are the system sound daemons for KDE and GNOME. They are typically employed for relatively simple purposes, although both have interesting potential for desktop events (the aRts system includes a plugin API). However, they are not designed for a professional audio environment and should be disabled when using KDE or GNOME for such an environment. |
The FST (FreeST) system [4] provides another way to use VST/VSTi plugins under Linux. FST implements a library instead of a server. Developer Paul Davis says that FST is “Öa more appropriate solution for audio applications that might support many VST plugins, where the context switches required in the VSTserver case do not scale well.” The downside, according to Davis, is that “Öa misbehaving plugin will crash the host application.”
Both vstserver and libfst are dependent upon particular versions of WINE. As I mentioned, the vstserver site provides a modified version of WINE. This modified WINE is based on old sources, and if you want a more recent version, you may risk the stability of vstserver. Please see the VST/Linux tutorial at http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/ for the latest reports regarding WINE compatibility.
| INFO |
|
[1] LADSPA: http://www.ladspa.org [2] DSSI: http://dssi.sourceforge.net [3] vstserver: Home http://www.notam02.no/arkiv/src/ [4] FST Home: http://linuxaudiosystems.com/fst/ [5] The VST Linux Compatibility Page: http://www.djcj.org/LAU/ladspavst/ [6] KVR Audio: http://www.kvraudio.com [7] Using VST/VSTi Plugins In Linux: http://www.djcj.org/LAU/quicktoots/toots/vst-plugins/ [8] Pd: http://crca.ucsd.edu/~msp/software.html [9] LAU (Linux Audio Users) Mail List: http://www.linuxdj.com/audio/lad/subscribelau.php3 [10] The Linux Sound & Music Applications Site: http://linux-sound.org |