Specifications

The SynthEdit SDK is now in it's 3rd version. This version combines the best of the earlier versions with new ideas from the GMPI (Generalized Music Plugin Interface) initiative, which was an open specification combining the best aspects of existing plugin standards.

 The SDK is extensivly cleaned up over previous versions, it uses a strict, standards confomant coding standards, is designed with cross-platform support in mind.

SEM Supported Features

  • Cross platform. Written in standard C++. Also useable from C.
  • Arbitrary number of Audio, MIDI, and Control inputs and outputs.
  • Supports arbitrary sample rates.
  • No plugin functions are re-entrant or asynchronous. Plugins require no locks or thread-aware code. Communication between Audio and Graphics code is arbitrated by the host.
  • Audio data processed in blocks of sample frames.
  • Implement a time-stamped, sample-accurate event system. Events are how real-time signals, including control changes, are represented.
  • Changes to music-time variables, such as tempo and meter , transport state, playback location are delivered as timestamped events.
  • Provides a performance optimization mechanism for handling silent audio streams.
  • Parameters support at the following parameter data types:
  • float
  • integer
  • string
  • filename
  • enumerated list
  • boolean value
  • opaque data. aka BLOBs. 
  • Parameters support both natural value and normalized value.
  • Parameters support metadata (maximum value, minimum value etc.).
  • Parameters can be marked as either hidden or visible. Hidden parameters should not be represented in UIs.
  • Parameter maybe either stateful or non-stateful.
  • All parameters are automatable.
  • It is possible to have many listeners for parameter changes. Managing listeners is the host's responsibility.
  • NEW IN SEM - Polyphonic parameters are supported.
  • Patch-change and Patch load/save provided by host. No plugin code required.
  • Plugins may have zero or more UIs, including GUIs. New in SEM - UI's may control 1 or more plugins.
  • Host supports plugins with no UI.
  • Allows arbitrary toolkits (including platform-specific) UIs via plug-in UI interfaces.
  • Supports out-of-process UIs. Decoupled design supports UI over network.
  • All communication between UI and plugin is via standard control signals.
  • GUIs are able to set parameters, read parameters (value and metadata), be notified when a parameter changes, store and recall programs, tell the host to load and save banks/patches, and tell the host to apply "MIDI learn" to a parameter.
  • Hosts are not required to support any external music control protocol, including MIDI. However MIDI is fully supported including SYSEX.
  • Plugins can act as MIDI receivers, processors, and/or senders. Multiple MIDI in/out supported.
  • Plugins which intend their parameters to be driven by MIDI can expose a mapping of MIDI messages to parameters. New in SEM - including polyphonic MIDI messages to polyphonic parameters.
  • Instrument plugins should be fundamentally no different than effects plugins.
  • Provides a note control mechanism beyond MIDI. This includes the ability to turn specific notes on and off. Note control provides the ability to turn on the same note pitch more than once, and identify exactly which instance of a note an event is intended for.
  • Fractional pitch numbers are supported.
  • Voice management is the domain of the instrument. All that the host sees is a voice ID.
  • Instrument can define an arbitrary set of parameters that applies to each voice.
  • Plugins are dynamically loadable in their host environments.
  • Each plugin (dynamically loadable) file may contain more than one plugin.
  • Installing a plugin is possible by simply unpacking and copying the plugin bundle to a directory. Plugin vendors may require additional steps (such as registration or unlocking) for their own plugins to be functional.
  • Plugins may self-categorize into a set of defined categories via their metadata.
  • Plugins are localizable. TODO The host must expose the current language preferences to plugins.
  • String encoding currently 16 bit wide char, could be made platform specific.
  • The API must be versioned. TODO.
  • Plugins are uniquely identifiable by URI or other string. Does not rely on a central authority for ID assignments.
  • Support wrapper plugins for other plugin APIs. TODO test this.
  • Sample plugins available.
  • TODO Sample host code available .
  • The SDK is released under a BSD license and are freely available in source form to any interested party no licensing fees apply.
  • Provides a way for a plugin to obtain information about the host it runs in. This information must contain at least a unique host identification and a host version number.
  • 64 bit float and integer parameter types.
  • API can supply tempo and song position.

SEM is an implementation of GMPI (Generalized Music Plugin Interface) with a few extensions for SynthEdit. Some less crucial GMPI features are not supported yet.

GMPI requirements not supported

  • No cross platform library. Many man-years already spent creating cross-platform toolkits. Use those. VSTGUI etc.
  • No offline support. Offline plugins require multi-pass processing and random access into the audio and MIDI stream. This is a completely different model than a real-time plugin. Rather than bloat or compromise, SEM keeps it simple.
  • Plugins must be able to indicate non-support of a sample rate. Possible future enhancement.
  • GMPI must support ramped or smoothed events. Ramping or smoothing must be supported on controls with a real number datatype, at minimum. Not implemented, Proved problematic applying arbitrary transformation to ramps, e.g. multiplying two ramps results in a parabola-ramp.
  • GMPI must support grouping events into 'gestures'. Partly supported via parameter 'grab' and 'release', Possible future enhancement.
  • GMPI must provide access to a system-global clock (UST) which is compatible with the OpenML definition of UST. No provided, possibly available direct from OS.
  • GMPI must provide a way for plugins to accurately convert between the various timelines. Possible future enhancement.
  • All connections between plugins must be bundles of channels. Not supported. Possible future enhancement.
  • In-place processing (reusing an input buffer as an output buffer) must be supported by GMPI. Future enhancement.
  • Must be able to provide a parameter-specific method for producing a string representation of a parameter. Possible future enhancement.
  • Must be able to provide a parameter-specific method for incrementing/decrementing a parameter . Possible future enhancement.
  • Plugins must be able to expose inter-parameter linkages. Possible future enhancement (Actor concept).
  • Plugins must be able to perform seemingly spontaneous parameter changes. Possible future enhancement (Actor).
  • GMPI must support dynamic parameter sets. Proved problematic. Changing the parameter set trashes pre-recorded host automation data. Possible future extension.
  • GMPI plugins must report their latency when queried by the host. TODO.
  • Plugins must be able to change their latency. Problematic in real-time. Possible future enhancement.
  • GMPI must define a simple file format for storing plugin state independently of any host or project. Possible future enhancement.
  • Plugin GUIs must be able to expose static and configurable keybindings to the host. Possible future enhancement.
  • It must be possible for non-privileged users to install plugins for their own use on platforms which support non-privileged users. Generally true, except Vista requires administrator rights to install software.
  • The GMPI SDK must provide a tool or suite of tools to perform basic plugin validation. Possible future enhancement.