A Host For Native Linux VST Plugins ?

Fully functional support for the VST plugin standard is one of the most important remaining problems for the Linux audio world. VST plugins are ubiquitous in the Win/Mac audio worlds, they are employed extensively in professional and desktop music software, and it may be no exaggeration to claim that the VST standard has revolutionized computer-based creation of music and sound. Given its great popularity this writer believes that stable VST support would give Windows users a compelling reason to try Linux as an alternate or replacement platform, especially if they have a sizeable investment of money and experience in their collection of VST plugins.

To a degree, VST support under Linux already exists. The FST and DSSI projects provide utilities to open and run Windows-specific VST plugins. Those projects do work, but they are dependent on WINE. As WINE itself has become a more stable dependency the FST and DSSI bridges have become viable mechanisms for internal VST support in programs such as Ardour and Rosegarden. However, significant problems remain, particularly regarding multiple plugin instances and MIDI control.

Developer Lucio Asnaghi has created his JOST software to provide seamless support for VST plugins under Linux, but his design philosophy differs radically from the FST and DSSI projects in two key aspects. First, JOST has no WINE dependencies. More significantly, instead of acting as a emulation environment for native Windows VST plugins JOST hosts native Linux VST plugins. Yes, I mean VST plugins that can be compiled for running under Linux.

JOST

Figure 1: JOST

JOST (Jack hOST) is a standalone host for VST plugins that have been ported to Linux. The project is quite new, and at this time it's best to consider JOST development to be at the proof-of-concept stage. It works, but setup and usage is a little complicated. Here are the steps necessary to use and test JOST :

Download and (optionally) compile the jost binary.

Download and (optionally) compile some ported VST plugins.

Copy or rename the jost binary to the name of a ported plugin, minus the .so extension.

Start the JACK audio server.

Invoke the newly-named binary, e.g. ./Transverb.

Make audio and MIDI client connections (in QJackCtl or a similar utility).

Rock out (optional).

The plugin and the jost executable must exist in the same directory. Thus, if I have jost and Transverb.so (a reverb effect plugin from DestroyFX) in one directory :

cp jost Transverb

I start JACK, then I can run the plugin as a standalone application :

./Transverb

Figure 1 illustrates the results.

Lucio has collected and compiled various plugins from VST developers mda and DestroyFX for use with JOST. Sources and precompiled binaries are available from the JUCEtice Web site.

Building JOST from source code is not difficult, but it requires the JUCE framework, which is also not difficult to compile and install. Both packages require the premake utility and an up-to-date C/C++ compiler. JOST further requires version 2.3 of the VST SDK. Potential builders should note that JOST is open-source software that is freely available, but it is not licensed under the GPL.

I tested JOST with some ported plugins under Dynebolic 2.3 on an 800 MHz machine. The Transverb plugin worked well, but the current port is incomplete (I missed its randomization function). I also tested the Rumpelrausch ZR3 VSTi plugin, a very good drawbar organ emulator. VSTi plugins are typically instruments that require MIDI input for their operation. JOST supplies the necessary MIDI I/O ports, identified as Juce Midi Input/Output by QJackCtl.

Lest any reader get carried away by enthusiasm, it is highly unlikely that many commercially developed VST plugins will be ported to Linux any time soon. The work done so far has been possible thanks to the original developers consenting to release their source code openly, and it is unwise to expect the same behavior from all developers. However, JOST is proof of the concept that VSTs can be compiled for and run natively under Linux, and perhaps it will be convincing enough to sway a few more developers into an open-source orbit.

As I mentioned, FST and DSSI depend upon WINE to emulate a Windows environment sufficiently believable to a native Windows VST plugin. Alas, WINE may change its codebase and leave those systems stranded, but depending on WINE is the least of the difficulties faced by any prospective system for VST plugin support under Linux. The greater problem is the license for the VST SDK, particularly this section :

"2. The Licensee has no permission to sell, licence, give-away and/or distribute the VST PlugIn Interface technology or parts of it in anyway, on any medium, including the Internet, to any other person, including sub-licensors of the Licensee or companies where the Licensee has any involvement. This includes re-working this specification, or reverse-engineering any products based upon this specification."

That passage expressly forbids the free distribution of the SDK source code, excluding it from agreement with the terms of the GPL, nor can Linux-specific improvements be added to the official codebase. If the SDK sources were truly libre software then the various VST support applications now available for Linux could become standard items in Linux distributions. VST support could become more stable and robust, lending Linux greater attraction to users coming from the Windows audio software world. Libre license-compliant native and/or emulated support seems to have no downside, and it's even possible that more commercial VSTs might be sold.

Back to reality. Michael Bohle's announcement of JOST's initial release caused a lengthy commotion on the Linux audio mail lists, with much commentary upon the licensing and other development issues. Alas, no conclusion was reached regarding how to lobby for a change of license for the VST SDK, but the fact remains that as more Windows users contemplate a change of operating system, the musicians among them will want the option to use VST plugins under Linux. It would be a shame if a mere licensing issue prevents them from enjoying that option.

Outro

I'll return in somewhat less than a fortnight with more news from the world of Linux sound and music software. Until then, keep your heads ringing.

jost is okay, but still quite buggy, not only that the best VST plugins are not native to linux(and may never be)... Now, that being said, if you can get your hands on VST's that are "standalone apps". they can run quite well under linux, and then all you need is any linux app that sequences midi. ie: jost,seq24,muse,rosegarden...also the "multiple instance" problem does not exist with standalone VST's.

you mention in your article that under linux VST's are still a hurdle. this is not a fact. in fact, the technology exists - it just happens to be proprietary - google "Receptor2 + muse research". also, this technology has been around for years!

i personally think native VST's would be great under linux(i own a few), but i think it is equally, if not more important to have the support for Windows VST's under linux as well. it would open up the world for us linux audio people!

I compiled and tried JOST a while ago, It worked OK but is really a pain in the neck to run alongside Ardour and have to patch things in and out through JACK. Also the plug-ins are a half-baked lot of oldie but goodie Windows VST freebies that have been ported to Linux with varying degrees of success. Like LADSPA and LV2 the native Linux VST format suffers from too few developers with too little time and/or interest IMO. Native Linux VST has even less to offer than compiling Ardour with regular VST support. If you are handy enough to compile JOST you might as well compile ArdourVST. Or run VSTHOST alongside Ardour with wineASIO and JACK.

I am running Audacity 1.2.4 on Fedora Core 4 on Athlon64 hardware. I recently downloaded the VST-enabler source code because there is a VST plug-in I would like to use. Following the compilation instructions, I downloaded the VST SDK from Steinberg and edited my Makefile as directed to point to the required header file.

The compilation went without incident. I copied the binary vst-bridge.so to the plug-ins directory under /usr/share/audacity/plug-ins. All sets of instructions on this topic indicated that copying the bridge to the plugins directory would result in the ability to actually load and use VST plugins. So far, I have failed to do that. When I restarted audacity with my vst-bridge binary and the binary for my VST plugin in the .../audacity/plug-ins directory, the plug-in was not available under the Effects->Plugins window as expected.

Has anyone gotten this to work under Linux? If so, what did you have to do to accomplish this task? I would appreciate any help or guidance. Thanks.

I managed to compile Ardour with VST support, and sucessfully loaded plugins such as Sonnox & Voxengo. In operation, VST suppirt was far worse than 'buggy' and all patch data gets rest on restarting a session. In reality, a working professional could not use or rely on this system at all. If linux VST support became seamless, it (ardour + linux) would be a very streamlined and powerful system I would quite hapilly, or even prefer using, especially as alsa supports Lynx cards and other excellent audio interfaces, but until the plugin support gets stable, its unusable for anything serious, you'll just lose money through lost time.

I've found a personally suitable solution for the issue of VST(i)s on Linux. I bought a license for Reaper, which hosts all the VST instruments I've so far tried. Despite being a Win32 program, it seems to run and perform perfectly well under recent version of Wine. It's not open source or free of charge, but it is affordable and it works very well.

The Studio-to-go looks promising, but I am wondering about the quality of the samples. I use Garritan(GPO and Strad), EWQL, Synful for classical sounds and after tweaking them a little in Cubasae I can get very good sounding samples. I don't know if that quality is achievable with Studio, or any other Linux app. As long as this will not be possible, I wont' be able to give up Windows completely.

Well, I think sound quality should be no problem since it depends mainly on the internal rendering of the software (sample rate and resolution) and the used audio-hardware. I see no disadvantages here for Linux.

A more important issue could be the latency and speed for "live"-playing the vst instruments. Latency depends mainly on the audio-hardware and the necessary os-drivers that support the hardware.

I've released a new version of jost (for now binary only, but source will follow soon), and it can load VSTs with GUI ! that's a gr8 news. Even if the support is limited to plugins made with JucePluginFramework (but i'm working to let vstgui/qt/gtk interfaces for plugins), this little thing is progressing ! Try it with eqinox, and is somewhat impressive !!!

Studio-to-go has been for me the best answer to the VST issue with linux based DAWs. It comes as a commercial live-cd with the best of what you can find in the linux world , working out of the box, including VSTs.

STG 2.0 should be released very soon. As a beta tester, I've had the privilege to use it, and it's been taking a giant step, in par with other main linux distribution, as far as ergonomics and ease of use is concerned (jackdmp for multicore machines, qjadeo for video post production, compatible with debian etch, new Rosegarden with audio time stretching, etc).

Some of the STG community have strong hope that a solution could be found to get VSTs working with Ardour2 for STG running on hard-drive. Downloading the needed file from steinberg's website is not a big deal. How to keep the next needed steps (recompilation of ardour) user-friendly, so that a sound engineer, or average DAW user/producer can be tempted by the linux alternative which covers its need, is the question!

We've all been to dependancy hell a few times, while desparately trying to get that latest greatest something...so where is the rocket science in treating those two pesky Steinberg text files as just another in a long line of dependancies, that would be gravely searched for by rpm, apt-get, yum, smart, yast, and any other evil beast that has tried so hard in the past to deny us a successful software installation (due to a missing dependancy)? I mean, how hard could it be to code an Ardour or Rosegarden or LMMS or jost install script that just searched for the two text files in /opt/jost/steinberg or /usr/lib/dssi/steinberg etc, and nuked out if the exact text failed to parse...That takes the headache away from distro maintainers and gpl police, and puts the (tiny) burden on the user of downloading the SDK, and copying the two files somewhere. Theres only a handful of music apps and code could be shared, right? vst support should not have to be a scons compile marathon man-page allnight coffee-gulping triathlon, and I'll pony up a crisp $20 if a bounty is organized...

Lack of Windows VSTI support was the only reason keeping me from leaving Windows and going to Linux. I eventually threw in the towel. Better to abandon my music than to keep on with Windows--as much as it hurts. Thankfully, I've had a measure of success using some Win VSTIs in Wine (after a lot of headaches)...but not enough to inspire me to continue on with my music.

energyXT is a great application on Windows, and i'm happy that the developer wants to support Linux but, the author does not mention it still depends on Wine. I enjoy using the native GUIs of VST instruments and effects and this is a big issue. I don't want some simple wrapper so I don't mind using Wine for this.

VSTi support in Linux is the single most important thing to me right now. In my estimation, everything else is covered - effects with ladspa, multi track recording with Ardour, sequencing with Seq24, Rosegarden, etc. The only thing missing is support for the many, many fine virtual instruments that VST has to offer (I'm thinking of most anything by Native Instruments).

I've often wondered what would happen if someone produced a precompiled VST host for Linux that included the proper VSTSDK header files, and released it anonymously, much the same way that crackers release warez. While I don't advocate breaking the law, I do see a need for "civil disobedience" here, if only just to show Yamaha/Steinberg that releasing the VSTSDK under the GPL would be a Good Thing.

Interested readers should be aware that the JOST project is truly in development. As usual with such new software, YMMV with any given release and you should not expect consistent results at this early stage. Be sure to follow the JUCE Linux forum as well the comments on the JOST site, you'll find code fixes and advice that you'll likely need. Building JOST is not straightforward a la an autotools-based or scons-based build procedure, so be prepared to do a little humping through source code trees to find out what's supposed to be where.