Sharing ardour projects that have LV2 and VST plugins

Support & discussion regarding DAWs and MIDI sequencers.

Moderators: MattKingUSA, khz

Post Reply
User avatar
Michael Willis
Established Member
Posts: 1451
Joined: Mon Oct 03, 2016 3:27 pm
Location: Rocky Mountains, North America
Has thanked: 69 times
Been thanked: 164 times
Contact:

Sharing ardour projects that have LV2 and VST plugins

Post by Michael Willis »

Many here already know about my orchestra template:

https://github.com/michaelwillis/virtua ... r-template

It uses LV2 plugins and one VST plugin.

I had somebody on #ardour IRC report that they tried to use it, it loaded the LV2 plugins but refused to load the VST. We checked that the VST was installed, the VST path used by ardour was correct, etc.

We noticed that in the project file, the references to the VST looked like this:

Code: Select all

<Processor id="49895" name="LinuxSampler" active="yes" user-latency="0" type="lxvst" unique-id="1280535920" count="1" custom="no">
...while the references to the LV2 plugins looked like this:

Code: Select all

<Processor id="638503" name="Invada Early Reflection Reverb (sum L+R in)" active="yes" user-latency="0" type="lv2" unique-id="http://invadarecords.com/plugins/lv2/erreverb/sum" count="1" custom="no">
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?

There is a LinuxSampler LV2 plugin. Would we have better luck if I switched the ardour project template to abandon VST and use only LV2 plugins?
rghvdberg
Established Member
Posts: 1067
Joined: Mon May 12, 2014 7:11 am
Has thanked: 15 times
Been thanked: 36 times

Re: Sharing ardour projects that have LV2 and VST plugins

Post by rghvdberg »

The way I understand it is, is that lv2 is the Linux format and vst is a compatibility format. So if the purpose of the template is to be used only on Linux, use lv2.
User avatar
sadko4u
Established Member
Posts: 987
Joined: Mon Sep 28, 2015 9:03 pm
Has thanked: 2 times
Been thanked: 360 times

Re: Sharing ardour projects that have LV2 and VST plugins

Post by sadko4u »

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.
LSP (Linux Studio Plugins) Developer and Maintainer.
User avatar
Michael Willis
Established Member
Posts: 1451
Joined: Mon Oct 03, 2016 3:27 pm
Location: Rocky Mountains, North America
Has thanked: 69 times
Been thanked: 164 times
Contact:

Re: Sharing ardour projects that have LV2 and VST plugins

Post by Michael Willis »

Thanks rghvdberg and sadko4u. I think the next step is to have him try creating a new project with a single midi track having the LinuxSampler VST, and then check the unique-id to see if it is different than the one in my project.
Post Reply