

Why use DSSI?
=============

DSSI is an API for writing audio plugins with custom user interfaces.
Although designed for synthesis plugins, it can also be used for
effects.  This document suggests a few reasons why you might want to
consider using DSSI when writing synths or other plugins, or to
consider adding DSSI support to a host application.


Synth authors
-------------

If you're thinking of writing a synth, here are some reasons you might
want to make it a DSSI plugin.

 * Flexibility

   DSSI plugins can accept MIDI and audio input, can have any number
   of controls and audio outputs, can support unlimited string-based
   configuration values as well as the numeric control ports, and can
   provide their own user interface using any GUI toolkit.

   Using DSSI does not limit your synth to being used as a plugin in
   sequencers that support DSSI, because the DSSI distribution also
   includes a complete, efficient JACK and ALSA-sequencer based host
   application.  This host will run a particular plugin automatically
   if invoked through a symbolic link -- so you can install your
   plugin in such a way as to be immediately operable as a standalone
   program as well, outwardly indistinguishable from any other
   JACK-based synth.

 * Structure

   DSSI separates the plugin and user interface, using standard Open
   Sound Control (OSC) messages to communicate between them.  This
   ensures that the plugin's controls are consistently externally
   available, provides a guarantee of automatability, and encourages
   clean plugin structure.

   DSSI uses a parsed MIDI event structure to pass MIDI events to the
   plugin.  This removes the responsibility of parsing MIDI in the
   plugin, a common source of problems in VST instruments.

 * Accessibility and control

   A DSSI plugin can have any number of different user interfaces,
   which can be added at any time.  It's also possible to use the same
   user interface code for more than one different plugin.  DSSI user
   interfaces don't have to be graphical -- every DSSI plugin is
   naturally controllable, so can be used directly from external OSC
   control surfaces and other non-graphical interfaces.

   DSSI also gives you a simple framework for basic requirements like
   mapping control ports onto MIDI controllers, so as to support MIDI
   controllers and MIDI automation as well as OSC and plugin port
   controls.

 * Simplicity

   Writing the plugin is easy -- the only hard part is that
   troublesome synthesis...

   Plugins can very easily be written incrementally, creating and
   testing the synthesis engine first before adding any advanced
   features or user interface.  (Indeed there's absolutely no
   requirement to write a user interface at all.)  DSSI is based on
   LADSPA, and the simplest DSSI synth plugins are just like LADSPA
   plugins with a single extra function to accept incoming note
   events.

   Source code to a number of plugins is available to serve as
   examples or bases for new efforts. The DSSI distribution itself
   contains several plugins, including the simplest-possible
   monophonic synth, a straightforward polyphonic synth, and
   monotimbral samplers. Also available are several softsynths
   (Xsynth-DSSI, hexter, Sineshaper, WhySynth), a FluidSynth wrapper
   (FluidSynth-DSSI), a DSSI-to-VST bridge (dssi-vst), an X-Y
   controller GUI (xy-controller-dssi), a libconvolve wrapper
   (dssi_convolve), and an oscilloscope (ll-scope) which
   demonstrates shared memory use between plugin and UI. Most of
   these plugins include GUIs, with Qt and GTK examples available.

 * Clear host-neutral specification

   DSSI has a written specification and an open, complete reference
   host.  It was designed and tested independently of implementation
   in any existing host.

   One of DSSI's designers is an author of a sequencer that is also a
   DSSI host, but none of the other people behind DSSI even use that
   host, and DSSI was largely designed and tested in its own test
   framework before being implemented in it.  We're confident there
   are no hidden dependencies on any particular host.

   The DSSI specifications also aim to reduce the amount of possible
   host dependency by specifying things like multithreading
   requirements, that usually go assumed in other APIs and end up
   causing portability problems.


Effects plugin authors
----------------------

DSSI plugins do not have to be synths.  DSSI is based on LADSPA 1.1,
and is compatible with it.  This makes for some interesting
possibilities.

 * Dual LADSPA and DSSI plugins

   A single loadable object file can provide both LADSPA and DSSI
   plugins through the separate LADSPA and DSSI discovery mechanisms.
   You can exploit this to make the same or related plugin code
   available via both APIs, for example to provide an effects plugin
   that supports true presets when queried via DSSI but uses an
   additional control input to mimic presets if queried via LADSPA
   (which does not support presets explicitly).

 * Custom GUIs for LADSPA plugins

   The DSSI user interface standard consists of a set of guidelines
   for OSC message passing and user interface invocation.  Nothing
   about it is necessarily specific to DSSI plugins, although the
   standard does assume that the plugin has at least the structure of
   a LADSPA plugin.  You can take advantage of this to provide custom
   GUIs for standard LADSPA plugins.  This is actually very easy to
   do, and the resulting GUIs will work already in any host that
   supports both DSSI and LADSPA.


Host authors
------------

Here are some good reasons to consider adding DSSI support to your
sequencer or other plugin host application.

 * Appropriateness for plugin authors

   Any plugin API needs to have more plugins than hosts.  The most
   important criterion for a host author is whether or not the API is
   a good one for writing plugins.  DSSI is, for all the reasons given
   above.

 * Documented API and specification

   DSSI is certainly more complex to implement for hosts than for
   plugins, and it's also more complex than some other synth APIs, but
   it's easier to get it right because almost everything is
   documented.  Contrast this with something like VST: a VST host can
   be a simpler thing than a DSSI host, but writing a VST host
   involves so much guesswork that it's hard to be sure whether any
   given plugin will actually run in it.

 * Standard technology

   DSSI's plugin interface is based on LADSPA and ALSA sequencer
   events, so any host that supports LADSPA, ALSA, and any form of
   synthesis will have most of the basics in place already.  The GUI
   part is more unusual, but all it really consists of is an external
   control interface for plugins using the industry standard OSC --
   which is a pretty good thing to have anyway.

 * Best chance as a workable standard

   The options for plugin synth support in a Free Software MIDI
   application are limited, and DSSI is the only one we know of that
   even has a written specification.  While there aren't very many
   DSSI plugins available at the time of writing -- hardly surprising,
   as it's still a new API -- DSSI is now supported by more hosts
   than any of the alternatives.

 * Free VST support

   The dssi-vst bridge plugin gives any DSSI host free support for
   Windows VST instruments and effects.

 * Free LADSPA GUI support

   Because DSSI is compatible with LADSPA, any DSSI implementation in
   an existing LADSPA host will get free support for custom LADSPA
   GUIs written to the DSSI GUI specification.  (See the "Effects
   plugin authors" section above.)

