dssi-vst: a DSSI plugin wrapper for VST plugins

This is a DSSI plugin wrapper for VST effects and instruments with GUI support.

Copyright (c) 2012-2013 Filipe Coelho, [email protected] Copyright (c) 2010-2011 Kristian Amlie, [email protected] Copyright (c) 2004-2010 Chris Cannam, [email protected]

The 0.9 release of dssi-vst added a fix to plugin idle handling thanks to Robert Jonsson and Torben Hohn.

The 0.8 release added 64-bit support in the Makefile and a few other fixes.

The 0.7 release added a LADSPA descriptor as well as DSSI, contained several build fixes, and switched to jack_client_open in vsthost for more predictable client names.

The 0.6 release contained a fix for a crash in the vsthost program. Otherwise it was identical to 0.5.

The 0.5 release was the first to officially support the VeSTige VST-compatibility header from Javier Serrano Polo (see vestige/aeffectx.h). With this header, you no longer need to obtain the official VST SDK in order to build dssi-vst. Many thanks to Javier for publishing this fine piece of work.

** IMPORTANT: The author of dssi-vst has no connection with the ** author of the VeSTige VST-compatibility header, has had no ** involvement in its creation, and has not modified it in any way. ** The VeSTige header is included in this package in the good-faith ** belief that it has been cleanly and legally reverse engineered ** without reference to the official VST SDK and without its ** developer(s) having agreed to the VST SDK license agreement. ** If you have any reason to believe that this is not the case, ** please contact the author of dssi-vst.

Please also read the "Licence" section further down this document.

This release is also compatible with version 2.4r2 of the official VST SDK. It may also compile with version 2.3.

Build etc

To build dssi-vst, you will need:

• The DSSI header.

• Wine 0.9.5 or newer and its development tools -- http://www.winehq.com/

• Steve Harris's liblo "Lite OSC" library -- http://liblo.sf.net/ -- version 0.9 or newer.

• OPTIONALLY the VST SDK headers. The URL for downloading these seems to change every week, but at the time of writing it is:

  http://www.steinberg.de/331+M54a708de802.html

  These are free to download, but you need to agree to Steinberg's licensing terms and you may not redistribute them. Unzip the SDK into the current directory (creating a subdirectory called vstsdk2.4).

  If you wish to use the official VST SDK, please edit the Makefile as directed in its comments.

Once you have all of the above, you should be able to build and install by running "make" then "make install".

To use dssi-vst: make sure DSSI_PATH is set appropriately, set VST_PATH to a colon-separated list of the directories containing VST plugins, and start up your DSSI host.

The plugin soname is dssi-vst.so, and each VST plugin gets a label corresponding to its DLL name. So for example, with jack-dssi-host, you should be able to just run

jack-dssi-host dssi-vst.so:MyVstPlugin.dll

Source files:

• dssi-vst.cpp: DSSI plugin implementation
• dssi-vst_gui.cpp: DSSI plugin GUI process implementation
• dssi-vst-scanner.cpp: Program that determines what VSTs you have and communicates that to the plugin
• dssi-vst-server.cpp: Program that hosts a single VST with a comms link to the plugin
• rdwrops.cpp, paths.cpp: misc functions
• remotepluginclient.cpp/remotepluginserver.cpp: Code to handle process separation for audio plugin (not VST specific), used by DSSI plugin & server
• vsthost.cpp: JACK/aseq host for VSTs using dssi-vst-server, but not using the actual DSSI plugin.

Building on 64-bit systems

You can use dssi-vst to load 32-bit Windows VST plugins in a 64-bit Linux environment. The standard dssi-vst Makefile should work in a properly configured 64-bit system as well as a 32-bit one, but you will need to ensure you have the proper compatibility libraries installed. For example, if using 64-bit Ubuntu or Debian, you should install (in addition to wine-dev) the gcc-multilib and g++-multilib packages.

Bugs and limitations

Does not handle multiple VST plugins in a single DLL.

Does not handle multi-channel support correctly yet. DSSI does not use MIDI channels, so dssi-vst should permit separate instances delivering to separate VST MIDI channels using run_multiple_synths to share the VST plugin.

Does not communicate tempo and beat information to the VST plugin (the VST API has a mechanism for this, but DSSI does not... yet).

Has a tendency to leave FIFOs and shared-memory files lying around in the temporary directory (/tmp or /var/tmp). You may want to go and remove anything starting with "rplugin_" occasionally...

Why not use vstserver or libfst?

dssi-vst doesn't use libfst because libfst is just too serious a thing to start messing about with in a plugin whose host doesn't know about it (because it involves introducing Wine threads into the host).

The main reason dssi-vst doesn't use vstserver is that I wrote most of this code quite a while ago as an exercise, and I've just got used to my own code. Architecturally dssi-vst is like vstserver in that it runs the VST plugin in a separate process and communicates with it via some IPC mechanism (here shared memory and POSIX FIFOs, in vstserver shared memory and Unix domain sockets).

Good points of dssi-vst:

• Bugs in dssi-vst aside, it ought to be impossible for a misbehaving VST plugin to crash its host. It's therefore theoretically possible for dssi-vst to be more stable for audio use than an fst host. (The same is true of vstserver.)

• DSSI provides a closer match to the VST feature set than LADSPA does -- apart from the synth stuff, this plugin handles VST programs as well as parameters -- which makes it more useful than vstserver's existing ladspavst plugin.

• Obviously, dssi-vst allows any DSSI host to become a VST host without having to know anything about VST or to have a code (or licence) dependency on the VST SDK, which is not the case with fst.

Bad points:

• Processes everywhere. Besides your host process, you get a server process to do the actual audio processing, a scanner process to identify the available VST plugins, and a GUI process. All of these except the GUI process (which in fact does nothing except send information around between the other processes) are winelib applications that are run under Wine. dssi-vst is useful for running the odd synth or effect on a fast machine, not for doing all your effects work.

• It's hard to make sure things like the communications FIFOs are tidied up when exiting. Apart from anything else it requires that the host call cleanup() on its plugins when exiting from ctrl-C or whatever. A model with a server shared among many plugins would cope better with this by having the server take ownership of such resources instead of the DSSI plugin.

Licence

dssi-vst is offered under two alternative licensing schemes: the GNU General Public License (GPL), or the GPL with a special exception for the VST SDK headers.

• GPL. If you choose to compile with the VeSTige VST compatibility header, then you may distribute and/or modify dssi-vst under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Note that in order to accept this license, you must not have included any part of the official VST SDK in your dssi-vst build. Provided that this is the case, please ignore the remainder of this Licence section.

• GPL-with-exception. If you compile dssi-vst with the official VST SDK headers, you may distribute the results under the following licence terms:

"You may distribute and/or modify dssi-vst under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation, except that you are hereby permitted to omit the source code to the two VST SDK header files AEffect.h and aeffectx.h (the source code of which would otherwise be required by section 3 of the GPL) when redistributing dssi-vst. The full terms of the GPL continue to apply to all of the remaining source code for dssi-vst.

Chris Cannam, [email protected]"

Note that these two licensing schemes are exclusive. If you accept the GPL-with-exception option, you may not distribute the VeSTige header code with or in dssi-vst. If you accept the GPL option, you may not distribute binaries of dssi-vst built with the official VST SDK. The default for dssi-vst is to build using the VeSTige headers, and therefore the result is covered by the GPL without any additional exception.

Licence for liblo

dssi-vst makes use of the liblo library by Steve Harris, which is provided under the GPL. Steve Harris has provided the following exemption to permit the liblo library to be used with dssi-vst:

"You are hereby permitted to omit the source code to the two VST SDK header files AEffect.h and aeffectx.h (the source code of which would otherwise be required by section 3 of the GPL) when redistributing any version of dssi-vst which uses liblo. This offer does not imply any exemption to the GPL for the liblo code itself or the remainder of dssi-vst, nor to any other derived work that may use liblo.

Steve Harris steve plugin org uk"