Although the official API for Vamp plugins is defined in C for maximum binary compatibility, we strongly recommend using the provided C++ classes in the SDK to implement your own plugins and hosts.
Plugins should be compiled and linked into dynamic libraries using the usual convention for your platform, and should link (preferably statically) with -lvamp-sdk. Any number of plugins can reside in a single dynamic library. See plugins.cpp in the example plugins directory for the sort of code that will need to accompany your plugin class or classes, to make it possible for a host to look up your plugins properly.
Please read the relevant README file for your platform found in the Vamp SDK build/ directory, for details about how to ensure the resulting dynamic library exports the correct linker symbols.
The following example plugins are provided. You may legally reuse any amount of the code from these examples in any plugins you write, whether proprietary or open-source.
The Vamp::HostExt namespace contains several additional C++ classes to do this work for them, and make the host's life easier:
The PluginLoader class can also use the input domain, channel, and buffering adapters automatically to make these conversions transparent to the host if required.
Host authors should also refer to the example host code in the host directory of the SDK.
Hosts should link with -lvamp-hostsdk.
(The following notes in this section are mostly relevant for developers that are not using the HostExt classes, or that wish to know more about the policy they implement.)
The Vamp API does not officially specify how to load plugin libraries or where to find them. However, the SDK does include a function (Vamp::PluginHostAdapter::getPluginPath()) that returns a recommended directory search path that hosts may use for plugin libraries, and a class (Vamp::HostExt::PluginLoader) that implements a sensible cross-platform lookup policy using this path. We recommend using this class in your host unless you have a good reason not to want to. This implementation also permits the user to set the environment variable VAMP_PATH to override the default path if desired.
The policy used by Vamp::HostExt::PluginLoader -- and our recommendation for any host -- is to search each directory in this path for .DLL (on Windows), .so (on Linux, Solaris, BSD etc) or .dylib (on OS/X) files, then to load each one and perform a dynamic name lookup on the vampGetPluginDescriptor function to enumerate the plugins in the library. The example host has some code that may help, but this operation will necessarily be system-dependent.
Vamp also has an informal convention for sorting plugins into functional categories. In addition to the library file itself, a plugin library may install a category file with the same name as the library but .cat extension. The existence and format of this file are not specified by the Vamp API, but by convention the file may contain lines of the format
vamp:pluginlibrary:pluginname::General Category > Specific Category
which a host may read and use to assign plugins a location within a category tree for display to the user. The expectation is that advanced users may also choose to set up their own preferred category trees, which is why this information is not queried as part of the Vamp plugin's API itself. The Vamp::HostExt::PluginLoader class also provides support for plugin category lookup using this scheme.
This plugin SDK is freely redistributable under a "new-style BSD" licence. See the file COPYING for more details. In short, you may modify and redistribute the SDK and example plugins within any commercial or non-commercial, proprietary or open-source plugin or application under almost any conditions, with no obligation to provide source code, provided you retain the original copyright note.