The SynthEdit SDK is now in its 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 extensively cleaned up over previous versions, it uses strict, standards conformant coding standards, is designed with cross-platform support in mind.

SEM Supported Features

• Cross-platform. Written in standard C++. Also useable from C.
• An 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 is processed in blocks of sample frames.
• Implement a time-stamped, sample-accurate event system. Events are how real-time signals, including MIDI and 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 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.
• A parameter may be 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 the host. No plugin code is 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. The decoupled design supports UI over a 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 that 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.
• Instruments 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 UTF, could be made platform-specific.
• The API is versioned via GUIDs.
• 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.
• Sample plugins available.
• TODO: Sample host code available.
• The SDK is released under a BSD license and is 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.
• Plugins can report their latency when queried by the host.
• Plugins can change their latency. (requires interruption to audio stream).
• Plugins can expose inter-parameter linkages.
• Cross-platform library: The GmpiDrawing library supports cross-platform graphics on Windows and Mac.
• Plugins are able to perform seemingly spontaneous parameter changes (using IMpController interface).

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 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) that 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.
• GMPI must support dynamic parameter sets. Proved problematic. Changing the parameter set trashes pre-recorded host automation data. Possible future extension.
• GMPI must define a simple file format for storing plugin state independently of any host or project. Partially supported via preset XML format.
• 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 that support non-privileged users. Generally true, except MS Windows 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.