Michael Willis wrote:I'm curious about the unique-id. The VST id is numeric; the LV2 id is a url string. Is it possible that a different release of a VST plugin might have a different id, even if it is binary compatible?
To identify LADSPA plugins, the similar mechanism was used: decimal LADSPA ID was provided. But with the notice:
Code: Select all
/* This numeric identifier indicates the plugin type
uniquely. Plugin programmers may reserve ranges of IDs from a
central body to avoid clashes. Hosts may assume that IDs are
below 0x1000000. */
unsigned long UniqueID;
/* This identifier can be used as a unique, case-sensitive
identifier for the plugin type within the plugin file. Plugin
types should be identified by file and label rather than by index
or plugin name, which may be changed in new plugin
versions. Labels must not contain white-space characters. */
const char * Label;
So we can use the pair of ID + Label values to identify LADSPA plugin.
About LV2 plugin:
Code: Select all
/**
A globally unique, case-sensitive identifier for this plugin.
This MUST be a valid URI string as defined by RFC 3986. All plugins with
the same URI MUST be compatible to some degree, see
http://lv2plug.in/ns/lv2core for details.
*/
const char * URI;
We use URI to identify LV2 plugins.
What about VST?
Code: Select all
VstInt32 uniqueID; ///< registered unique identifier (register it at Steinberg 3rd party support Web). This is used to identify a plug-in during save+load of preset and project.
So we need to register plugin ID at
http://service.steinberg.de/databases/p ... n?openForm
But not all do this. So hosts are forced to use, for example, .so file name to properly identify the plugin. For example, Renoise does such behaviour.
Now about versions. LADSPA plugins do not have version field in descriptor. So they may change the UniqueID but mostly shouldn't change the Label.
LV2 plugins have such declarations:
Property lv2:minorVersion
minor version
The minor version of an LV2 Resource. This, along with lv2:microVersion, is used to distinguish between different versions of the "same" resource, e.g. to load only the bundle with the most recent version of a plugin. An LV2 version has a minor and micro number with the usual semantics:
The minor version MUST be incremented when backwards (but not forwards) compatible additions are made, e.g. the addition of a port to a plugin.
The micro version is incremented for changes which do not affect compatibility at all, e.g. bug fixes or documentation updates.
Note there is deliberately no major version; all versions with the same URI are compatible by definition. Replacing a resource with a newer version of that resource MUST NOT break anything. If a change violates this rule, then the URI of the resource (which serves as the major version) MUST be changed.
Plugins and extensions MUST adhere to at least the following rules:
All versions of a plugin with a given URI MUST have the "same" set of mandatory (i.e. not lv2:connectionOptional) ports with respect to lv2:symbol and rdf:type. In other words, every port on a particular version is guaranteed to exist on a future version with same lv2:symbol and at least those rdf:types.
New ports MAY be added without changing the plugin URI if and only if they are lv2:connectionOptional and the minor version is incremented.
The minor version MUST be incremented if the index of any port (identified by its symbol) is changed.
All versions of a specification MUST be compatible in the sense that an implementation of the new version can interoperate with an implementation of any previous version.
Anything that depends on a specific version of a plugin (e.g. a serialisation that references ports by index) MUST refer to the plugin by both URI and version. However, implementations should be tolerant and extensions should be designed such that there is no need to do this (e.g. indices should only be meaningful for a particular plugin instance at run-time).
When hosts discover several installed versions of a resource, they SHOULD warn the user and load only the most recent version.
An odd minor or micro version, or minor version zero, indicates that the resource is a development version. Hosts and tools SHOULD clearly indicate this wherever appropriate. Minor version zero is a special case for pre-release development of plugins, or experimental plugins that are not intended for stable use at all. Hosts SHOULD NOT expect such a plugin to remain compatible with any future version. If possible, hosts SHOULD hide such plugins from users unless an "experimental" option is enabled.
And:
Property lv2:microVersion
micro version
The micro component of a Resource's version.
Releases of plugins and extensions MUST be explicitly versioned. Correct version numbers MUST always be maintained for any versioned resource that is published. For example, after a release, if a change is made in the development version in source control, the micro version MUST be incremented (to an odd number) to distinguish this modified version from the previous release.
This property describes half of a resource version. For detailed documentation on LV2 resource versioning, see lv2:minorVersion.
There is no major version. If major version changs, LV2 standard says to change the URI of plugin.
With VST it is simple:
Code: Select all
VstInt32 version; ///< plug-in version (example 1100 for version 1.1.0.0)
The version os plugin is reported with it's Unique VST ID. So while changing version the VST ID probably shouldn't change.