dssi-vst: a DSSI plugin wrapper for VST plugins
===============================================

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

Source files:

* dssi-vst.cpp: DSSI plugin implementation (works OK mostly)
* dssi-vst_gui.cpp: DSSI plugin GUI process implementation (not done yet)
* dssi-vst-scanner.cpp: Program that determines what VSTs you have (a bit
  like fstconfig in the fst package) and communicates it back to the plugin
* dssi-vst-server.cpp: Program that hosts a single VST with a comms link
  to the plugin (a bit like a less general version of Kjetil's vstserver)
* 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
* vstsyth.cpp: JACK/aseq host for VSTs using dssi-vst-server, but not using
  the actual DSSI plugin.  Mostly for test purposes, this does nothing you
  can't already do better with vstserver or jack_fst.

Copyright (c) 2004 Chris Cannam.  dssi-vst does not use any code from
vstserver or libfst.  It requires recent Wine, liblo, and the VST SDK
headers to build.  Once you have these, edit Makefile.in to specify
the VST SDK location; then you should be able to build and install by
running autoconf ; ./configure ; make ; make install.

To run: make sure DSSI_PATH is set appropriately, set VST_PATH to a
colon-separated list of the directories containing VST plugins, and
load the plugin into 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 dssi_example_host, you should be able to
just run dssi_example_host dssi-vst.so MyVstPlugin.dll.  (dssi-vst
does not handle multiple VST plugins in a single DLL.)


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).

Architecturally dssi-vst is a little bit like vstserver in that it
runs the plugin in a separate process and communicates with it via
some IPC mechanism (here shared memory and POSIX FIFOs, where
vstserver uses shared memory and Unix domain sockets).  The big
difference is that dssi-vst spawns a separate process per plugin
rather than using a single server.  To be honest, the only practical
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.

These are some of the theoretical good points of dssi-vst's
architecture:

* Bugs in dssi-vst aside, it ought to be impossible for a misbehaving
  VST plugin to crash its host, for a misbehaving plugin GUI to
  disrupt either the host or the audio part of the plugin (because
  the GUI and audio parts are in separate processes), or for one
  misbehaving plugin or plugin GUI to disrupt another.  It's therefore
  theoretically possible for dssi-vst to be more stable for audio use
  than either an fst host or vstserver.

* Because there is no real audio work done in the GUI process and
  no requirement for an audio thread, the GUI code is less likely to
  experience problems from thread mismanagement.

* 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
  LADSPA wrapper 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.

* Marginally simpler than vstserver to use, because you don't have to
  start the server yourself.

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
  to run the GUI -- and all of these 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.

* A plugin with a visible GUI actually has to be instantiated twice.
  The GUI instantiation doesn't do the full audio processing work,
  and it isn't created unless you actually want to see the GUI, but
  this is still wasteful of resources.

* Any plugin GUI that uses its own back channel to communicate
  directly with the plugin will fail, because there's no way to
  intercept this information, which is necessary for the DSSI GUI
  separation model.  The most obvious example where this causes
  failures is for synth plugins with miniature keyboards or test
  buttons built into their GUIs: these gizmos cannot work with
  dssi-vst, although that doesn't usually prevent the plugin
  itself from working.  More complex plugins with complex GUIs
  that do patch management in the plugin GUI also suffer, though
  they might be better run as standalone jack_fst or vstserver
  applications plumbed into the JACK graph anyway.

* 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.  This isn't quite handled satisfactorily yet
  either in this code or in the existing hosts.  A vstserver model
  can cope better with this by having the server take ownership
  of such resources instead of the plugin.

* The comms model dssi-vst uses introduces a fixed latency equal to
  the JACK period size, as well as any existing latency in the VST
  plugin.  (The fixed latency is exposed through the _latency output
  control port.  Does anyone know how to find out the latency of a
  VST plugin?)


Licence
-------

Basically GPL, but I guess we need an exception for the VST SDK
headers.  This code uses liblo, which is under the GPL without any
such exception, so I'm evidently going to have to think a bit harder
about this.  *sigh*  For now I advise against distributing it at all...


Chris Cannam
[email protected]