| # |
Status |
Requirement |
| 1 |
Met |
GMPI must be hardware architecture neutral. |
| 2 |
Met |
GMPI must fully support 32 bit and 64 bit processors. |
| 3 |
Met - Though the LV2 APIs are purely C. |
The GMPI API must be defined in ANSI C, with a clearly specified
application binary interface (ABI) for each supported platform. Actual
calling conventions may vary from platform but must be standardized
within a platform. A GMPI SDK must be provided in C++ and C. |
| 4 |
Met |
The GMPI API must use ANSI C type names (from stdint.h) instead of
platform specific type names (e.g. uint32_t instead of DWORD). |
| 5 |
Disagree - This should be a separate project, and
developers should be free to use whatever portability libraries they
see fit. |
The GMPI design group should research options for a cross-platform
portability library for GMPI plugins. An existing library may be
adopted if a suitable specification for this already exists, or a new
specification may be drafted. This should be a separate specification
from the GMPI API. Plugins that wish to be more portable can use this
API instead of native APIs whenever possible. This API is not the host
services API, which should handle certain host-specific service
tasks. |
| 6 |
Disagree - This "profiles" idea is ill-formed and
unnecessary. In reality, all code (including hosts and plugins) must be
written to be portable to whatever platforms it targets. This can not
be enforced, and it is not useful or realistic to attempt to specify
"profiles" for platform reality. |
GMPI must support the nuances of the various platforms it supports.
The varying areas of the specification should be grouped into profiles
for each platform. Each GMPI plugin is built for a single profile. As
the GMPI specification becomes more complete, the exact details of what
this support entails will become clearer. Hosts may support multiple
profiles. |
| 7 |
Met - LV2 simply disallows plugins from smashing any
global state whatsoever. |
GMPI must define clear and easy-to-follow rules governing access to
those system resources which must be shared between the plug-in and the
host. Examples include the Resource Context on Macintosh and the FPU
state on x86. |
| # |
Status |
Requirement |
| 13 |
Met |
GMPI must be primarily aimed at realtime processing systems, but
must also support offline processing. |
| 14 |
Unmet - LV2 does not include documentation or code
about the general practices for realtime programming. It is
questionable whether this would be appropriate. |
The GMPI SDK must provide best practices and recommendations for
realtime programming. |
| 15 |
Met |
There must be some way for plugins to identify themselves as
potentially unsafe for realtime use. Plugins must be able to indicate
that they run offline (as opposed to realtime). |
| 16 |
Disagree - The meaning and utility of this
requirement is unclear. |
GMPI must provide a way for plugins to require multi-pass
processing (offline only). |
| 17 |
Unmet |
GMPI must include a way for the host to indicate to plugins whether
they are running in realtime or offline mode. Plugins can ignore this
information completely. |
| # |
Status |
Requirement |
| 24 |
Partial - LV2 has an event mechanism, but it is not
used for controls. This is a mistake inherited from LADSPA, and it is
expected to migrate to control events eventually. |
GMPI must implement a time-stamped, sample-accurate event system.
Events are how realtime signals, including control changes, are
represented. |
| 25 |
Met - Events are simply 'sent' synchrononously in a POD
buffer like any other port. |
All events bound for a plugin during a timeslice must be enqueued
before that plugin is activated to process that timeslice. Events must
never be delivered while a plugin is processing. |
| 26 |
Met |
Event timestamps must be measured in sample frames. The final
specification may define sub-sample resolution. |
| 27 |
Met |
Events must be delivered to plugins in temporal order. |
| 28 |
Unmet |
GMPI must support ramped or smoothed events. Ramping or smoothing
must be supported on controls with a real number datatype, at
minimum. |
| 29 |
Unmet |
GMPI must support grouping events into 'gestures'. It must be
possible to include zero or more events for multiple controls in a
gesture. Support for gestures is optional for all plugins. The host
must handle the case of conflicting or overlapping gestures. |
| # |
Status |
Requirement |
| 30 |
Met - The time
extension can be used to send time information to plugins |
GMPI must provide one master clock per graph. The GMPI master clock
must be sample based and provide sufficient range to represent several
hours of time at a high sampling rate (i.e. 64 bits). The final
specification may define sub-sample resolution. Hosts may build
multiple graphs with different master clocks, but all GMPI plugins have
exactly one master clock |
| 31 |
Met - The time
extension can be used to send time information to plugins |
GMPI must provide a music-time clock. Music time is dependent on
several variables such as tempo and meter, and is measured in some
musically useful unit, such as (bars, beats, ticks), or a subdivision
thereof. There may be more than one such clock in a graph. |
| 32 |
Unmet |
GMPI must provide access to a system-global clock (UST) which is
compatible with the OpenML definition of UST. Plugins must be able to
determine the UST time for any sample frame with minimal jitter. |
| 33 |
Met - The time
extension can be used to send time information to plugins, or
control ports may have a suitable designation (e.g.
time:beatsPerMinute) |
GMPI must provide a way for plugins to be notified of changes to
music-time variables, such as tempo and meter. Changes to these
variables must be delivered as timestamped events. There may be more
than 1 change to the same variable within a single processing cycle.
The final specification may provide additional methods of accessing
these variables, such as a semi-static map. |
| 34 |
Met - The time
extension can be used to send time information to plugins |
GMPI must provide a way for plugins to get relative musical timings
(e.g. given a start time, accurately find out when the time is exactly
1 beat later), absolute musical milestones (e.g. accurately find the
start of the next beat), and musical "phase" (e.g. how far into a beat
is sample frame X). |
| 35 |
Unmet - Events based on the time extension can be sent, but
there are no rules for hosts to be aware of this and interpret
them. |
GMPI must provide a way for plugins to control music-time
variables, such as tempo and meter. The final specification will
determine the actual model for this. GMPI must at least equal existing
plugin APIs in this respect. |
| 36 |
Met - The time
extension can be used to send time information to plugins |
GMPI must provide a way for plugins to be notified of changes to
the transport state (e.g. playing or paused). |
| 37 |
Met - The time
extension can be used to send time information to plugins |
GMPI must provide a way for plugins to be notified of changes in
the playback location (e.g. loops or jumps). |
| 38 |
Unmet |
GMPI must provide a way for plugins to accurately convert between
the various timelines, and a TBD list of other time formats (e.g.
SMPTE) within a processing timeslice. |
| # |
Status |
Requirement |
| 39 |
Met - LV2 audio is non-interleaved float
samples. |
All GMPI audio must be PCM data. |
| 40 |
Met - LV2 audio is non-interleaved float
samples. |
All hosts and plugins must support non-interleaved audio data.
TBD: Based on as-yet-unknown benchmarks, the
requirments might be extended to include a per-plugin preference for
interleaved data. This extension will be included if and only if
sufficient net performance gains can be demonstrated.
|
| 41 |
Disagree - "Profiles" are a poor idea. However,
LV2 plugins can use any format for I/O. |
The audio sample datatype a plugin uses must be determined by the
plugin's GMPI profile. |
| 42 |
Met - Ports can be given channel designations from the
port groups
extension. |
All connections between plugins must be bundles of channels with
defined relationships to each other (e.g. a mono stream is one channel,
while a stereo stream is a left channel and a right channel, and a 5.1
stream is a bundle of left, right, center, surround-left,
surround-right, and LFE channels). A plugin may have any number of
input or output bundles, including none at all. |
| 43 |
Disagree - Making plugins deal with encodings is a
poor idea. All audio buffers are single channel float
samples, multi-channel can be expressed simply via metadata and hosts
may encode in the uncommon cases where this is useful. |
Audio streams may represent trivial encodings (e.g. 2 signals =
left and right channels) or non-trivial encodings (e.g. 2 signals = 4
channels, encoded in LtRt). |
| 44 |
Disagree - This is purely a host implementation
decision, and LV2 uses discrete single channel ports always. "Bundles" (port groups) are strictly a metadata concept. |
Connections must be handled atomically with respect to the bundle.
All channels in a bundle are connected or disconnected together. Hosts
may provide mechanisms for unbundling and re-bundling streams. |
| 45 |
Met |
In-place processing (reusing an input buffer as an output buffer)
must be supported by GMPI. If both the plugin and the host support
in-place processing, it may be used. Hosts and plugins that do not
support in-place processing must not need to do anything extra. |
| 46 |
Unmet |
GMPI must provide a performance optimization mechanism for handling
silent audio streams. This mechanism must allow plugins and hosts which
are built to use this optimization to flag silent outputs and detect
silent inputs without examining the buffer contents. |
| # |
Status |
Requirement |
| 47 |
Met |
GMPI must provide a way for plugins to expose an arbitrary set of
explicitly typed parameters. Parameters must be managed by the
host. |
| 48 |
Met - The atom
extension defines many data types, as well as a generic standard
container which can contain any data type. |
GMPI must support at least the following parameter datatypes:
- real number (determined by the plugin's GMPI profile)
- integer
- string
- filename
- enumerated list
- boolean value
- opaque data
It may be desirable to provide distinct
double-precision and single-precision real number types.
It may be desirable to provide distinct 32 bit
and 64 bit integer types, or even just 64 bit integers.
It may be desirable to use the opaque type with
some metadata as the de-facto extensible type. Otherwise we may want
to consider defining some extensible datatype.
|
| 49 |
Met |
All parameters must have associated metadata (e.g. name, minimum
value, maximum value). Metadata will vary depending on the parameter
datatype. All parameters must provide a default value. Plugins should
handle invalid parameters safely. |
| 50 |
Met |
All parameters must be able to use natural values. |
| 51 |
Met - Though literally providing a plugin method for this is a mistake inherited from VST. LV2 hosts may do this simply by using metadata. |
GMPI plugins must be able to provide a parameter-specific method
for producing a string representation of a parameter. |
| 52 |
Met - Though literally providing a plugin method for this is a mistake inherited from VST. LV2 hosts may do this simply by using metadata. |
GMPI plugins must be able to provide a parameter-specific method
for producing a parameter value from a string. |
| 53 |
Met - Though literally providing a plugin method for this is a mistake. LV2 hosts may do this simply by using metadata. |
GMPI plugins must be able to provide a parameter-specific method
for incrementing/decrementing a parameter value from a given value. The
increment/decrement operation must return the new value, but not change
the current value. |
| 54 |
Met - The notOnGUI port
property can be used for this, though it is uncommon and questionable
to do so. |
Parameters must be marked as either hidden or visible. Hidden
parameters should not be represented in UIs. This parameter property
may change over the lifetime of a plugin. |
| 55 |
Met - All LV2 parameters are stateful by
definition. |
Every parameter must be either stateful or non-stateful. This
parameter property may not change over the lifetime of a plugin. |
| 56 |
Met - LV2 makes no automatable distinction,
parameters are simply parameters. |
All parameters must be automatable. Parameter automation is simply
event playback. |
| 57 |
Met - Purely a host implementation decision. |
It must be possible to have many listeners for parameter changes
(e.g. a GUI and a motorized MIDI controller). Managing listeners is the
host's responsibility. |
| 58 |
Unmet |
Plugins must be able to expose inter-parameter linkages. For
example, two parameters may be linked together or not, as determined by
a third parameter. |
| 59 |
Unmet - Control events are needed for this. |
Plugins must be able to perform seemingly spontaneous parameter
changes. For example, a plugin might morph all its parameters from one
state to another based on a parameter input or a MIDI note. |
| 60 |
Unmet - Control events are needed for this. |
GMPI must support dynamic parameter sets. When the parameter set
changes, the host must be notified by the plugin. Hosts must be able to
deny a parameter set change. |
| 61 |
Met - Purely a host implementation decision. |
There must be a way for GMPI plugins to save and restore their
parameter-set state with patches. |
| 62 |
Met - The port groups extension can be
used to group parameters as well. |
GMPI must support grouping of associated parameters. Grouping may
be arbitrarily deeply nested. |
| 63 |
The ideas of channel and patch here
are ill-formed and of questionable utility. |
GMPI must support multi-channel plugins. Each channel may have any
number of parameters and/or IOs, and channels need not be symmetric.
There may be an arbitrary number of channels per plugin. It must be
possible for a host to save just a single channel's patch as well as
the entire state of a plugin, which includes all channels. |
| 64 |
Met - Purely a host implementation decision. |
Parameters must be able to receive events from multiple senders.
The host must handle the routing and merging of events. |
| # |
Status |
Requirement |
| 68 |
Met - As defined by the state extension, a plugin's state
is the value of all its parameters as well as an additional dictionary
which holds any additional state. |
A plugin's state is defined to be the collection of the values of
it's stateful parameters at a given instant. For a host to save the
state of a plugin, it must query all the plugin's stateful parameters
and save them. Likewise, to restore the state of a plugin, a host must
write values to all of the plugin's stateful parameters. |
| 69 |
Met - If plugins use standard atom types for their state, a
standard serialisation in RDF is defined which is implemented by the
sratom library. This
format is identical to the standard presetpreset format. |
GMPI must define a simple file format for storing plugin state
independently of any host or project. These files are presets. The
preset file format must must include the values for all of a plugin's
stateful parameters, thereby completely describing the plugin's state.
The format must also include information to identify the plugin for
which the state is intended. The format must be editable outside of any
host for primitive types. Opaque types must be encoded into the files
in a compatible way. |
| 70 |
Unmet - There is currently no concepts of
banks of presets. |
GMPI must define a simple file format for storing a group of plugin
preset files into a bank of presets. It should be simple to build a
bank of presets from a set of single preset files. A bank file must
also include information to identify the plugin for which the state is
intended. Bank files must be able to contain an arbitrary number of
presets. |
| # |
Status |
Requirement |
| 71 |
Met |
Plugins may have zero or more UIs, including GUIs. Each GUI may
have 1 or more windows. |
| 72 |
Met |
Hosts must support plugins with no UI. They can use parameter and
plugin metadata to automatically generate a UI. All GMPI hosts must
support plugins with no UI. |
| 73 |
Met |
GMPI must define a simple in-process custom UI mechanism. Hosts are
not required to support this, but graphical hosts are strongly
encouraged to do so. |
| 74 |
Met |
GMPI must allow arbitrary toolkit (including platform-specific)
UIs, in a similar manner to what VST and AU do today. |
| 75 |
Met - The external UI extension
provides this, though it is not a part of the main LV2
distribution. |
GMPI must explore a mechanism for out-of-process UIs. Hosts are not
required to support this, but are strongly encouraged to do so. |
| 76 |
Met - Though private access is possible via the
instance access
extension, this is highly discouraged. |
GUIs are not part of a DSP plugin with private access to the DSP
internals. All communication between UI and plugin is via standard
control signals. |
| 77 |
Partial - There is not yet an established standard
for programs or MIDI learn. |
GUIs must be 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. |
| 78 |
Met |
Plugin GUIs must have the option to be resizeable. |
| 79 |
Unmet |
Plugin GUIs must be able to expose static and configurable
keybindings to the host. |
None of the below requirements should be met by handicapping GMPI. In
particular, MIDI has well-known limitations (integer field sizes, message
model, etc.) and those limitations should not be taken as bounds on GMPI.
The GMPI system can and should provide richer and more detailed information
than MIDI is capable of. However GMPI must still interoperate losslessly
with MIDI.
All references to "MIDI" in this section refer to the MIDI 1.0 standard,
as defined by the MMA.
| # |
Status |
Requirement |
| 80 |
Met |
Hosts are not required to support any external music control
protocol, including MIDI. However, it must be possible to create a host
in which users can control plugins from arbitrary external MIDI
sources, such as hardware MIDI controllers or other MIDI software. This
includes (but is not limited to) playing notes, setting parameters,
host-based MIDI learn (click-and-wiggle) and system exclusive (SysEx)
messages. |
| 81 |
Disagree - Plugins simply output MIDI. The destination of that MIDI is a host implementation decision. The role of a particular output can be described in metadata which is sufficient. |
It must be possible for plugins to send MIDI to arbitrary
desitinations outside the host (though the in-graph data need not
necessarily be pure MIDI). Plugins must not need to use
platform-specific MIDI I/O APIs to achieve this. |
| 82 |
Met |
It must be possible for plugins to act as MIDI receivers,
processors, and/or senders (though the in-graph data need not
necessarily be pure MIDI). |
| 83 |
Met - Inherently possible, though uncommon and perhaps questionable. |
It must be possible for a GMPI plugin to act as a proxy for a
hardware MIDI device (though the in-graph data need not necessarily be
pure MIDI). |
| 84 |
Met |
All MIDI-originated events must be timestamped on the same timeline
as all GMPI events. |
| 85 |
Met - LV2 simply uses normalized raw MIDI. |
The GMPI event system must be able to represent all MIDI messages
without any loss of information, including message content and time. |
| 86 |
Unmet |
Plugins which intend their parameters to be driven by MIDI must be
able to expose a mapping of MIDI messages to parameters. The map must
be changeable at runtime, for example when the parameter set
changes. |
| 87 |
Unmet |
Plugins with MIDI-driven parameters, where changes to one
parameter automatically produce changes in other parameters, must use
an Actor to properly model any parameter linkages. |
| # |
Status |
Requirement |
| 88 |
Met |
Instrument plugins should be fundamentally no different than
effects plugins. Any plugin that implements the instrument API can be
played as an instrument. |
| 89 |
Unmet - Possible, though a standard event format is needed (existing plugins use MIDI). |
GMPI must provide a note control mechanism. This must include at
least the ability to turn specific notes on and off. GMPI note control
must provide the ability to turn on the same note number more than
once, and identify exactly which instance of a note an event is
intended for. |
| 90 |
Unmet - Possible, though a standard event format is needed (existing plugins use MIDI). |
GMPI must support fractional pitch numbers. |
| 91 |
Unmet - Possible, though a standard event format is needed (existing plugins use MIDI). |
Voice management must be the domain of the instrument. All that the
host sees is a voice ID. Operations on a voice always use the ID. |
| 92 |
Unmet - LV2 is not currently polyphony aware. |
GMPI must provide the ability for an instrument to define an
arbitrary set of parameters that applies to each voice. These
parameters must be able to indicate whether they apply only to the
start of a voice (e.g. velocity), apply continuously to the voice (e.g.
aftertouch), apply only to the end of a voice (e.g. release
velocity). |
| # |
Status |
Requirement |
| 93 |
Met |
Plugins must be dynamically loadable in their host environments.
This is a platform specific definition, and the GMPI specification must
define the formats for supported operating systems. Dynamically
loadable files (such as .dll or .so files) which contain GMPI plugins
must be differentiable from non-GMPI shared object files. |
| 94 |
Met |
Each plugin (dynamically loadable) file may contain more than one
plugin. |
| 95 |
Met |
A plugin is managed (possibly with other plugins) as part of a
"bundle" that includes the shared object file(s) corresponding to the
plugin(s), and any associated files. These files could be presets,
graphics, help files, manuals, samples, etc. When installed on a
system, all files in the bundle must be located in a single directory.
The bundle directory may contain nested directories, but these
directories are private to the bundle. A bundle directory must never
contain other bundles. |
| 96 |
Met |
Installing a GMPI plugin must be possible by simply unpacking and
copying the plugin bundle to a directory. Nothing more is required.
Plugin vendors may require additional steps (such as registration or
unlocking) for their own plugins to be functional. |
| 97 |
Met |
It must be possible for non-privileged users to install plugins for
their own use on platforms which support non-privileged users. |
| 98 |
Met |
Enumerating plugins is done by recursively scanning 1 or more
directories for GMPI plugin files. The GMPI spec or implementation
groups may decide to provide for static metadata outside the shared
object. If the plugin bundle includes static metadata, hosts should use
that metadata. If the plugin bundle does not include static metadata,
the plugin must be probed for metadata. |
| 99 |
Met |
Plugins may self-categorize into a set of GMPI defined categories
via their metadata. |
| 100 |
Met |
It must be possible to have two plugin files with the same file
name in two different directories. For example, it must be possible to
have two files, foo/demoplugin.dll and bar/demoplugin.dll
in the GMPI plugin search path, and the host must be able to
differentiate the files. |
| # |
Status |
Requirement |
| 103 |
Met - RDF metadata is inherently localizable. |
GMPI plugins must be localizable. The host must expose the current
language preferences to plugins. |
| 104 |
Met - RDF metadata is inherently localizable. |
All user-visible plugin strings must be localizeable, with the
corollary that all identifiers that are used by the host must stay
consistent. For example, a parameter might have the name 'FOO' which is
constant, and a display name, "Foo Frequency" which is
localizable. |
| 105 |
Met - Plugin state generally does not contain
localizable strings. |
All parameter data which is saved as part of a project must not be
localized, which makes saved state locale-independent. |
| 106 |
Met - LV2 uses UTF-8 everywhere. |
GMPI must define a common string encoding. |