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 (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 :
Figure 1 illustrates the results.
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.
The VST Problem
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.
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.
Similis sum folio de quo ludunt venti.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide