Mercurial > hg > sv-dependency-builds
diff src/vamp-plugin-sdk-2.5/README @ 108:1813f30f2f15
Update Vamp plugin SDK to 2.5
author | Chris Cannam <cannam@all-day-breakfast.com> |
---|---|
date | Thu, 09 May 2013 10:52:46 +0100 |
parents | |
children |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/vamp-plugin-sdk-2.5/README Thu May 09 10:52:46 2013 +0100 @@ -0,0 +1,248 @@ + +Vamp +==== + +An API for audio analysis and feature extraction plugins. + + http://www.vamp-plugins.org/ + +Vamp is an API for C and C++ plugins that process sampled audio data +to produce descriptive output (measurements or semantic observations). + +This is version 2.5 of the Vamp plugin Software Development Kit. + +Plugins and hosts built with this SDK are binary compatible with those +built using version 1.0 of the SDK, with certain restrictions. See +the file README.compat for more details. + +See the file CHANGELOG for a list of the changes in this release. + +A documentation guide to writing plugins using the Vamp SDK can be +found at http://www.vamp-plugins.org/guide.pdf . + + +Compiling and Installing the SDK and Examples +============================================= + +This SDK is intended for use on Windows, OS/X, Linux, and other POSIX +and GNU platforms. + +Please see the platform-specific README file (README.msvc, README.osx, +README.linux) in the build/ directory for details about how to compile +and install the SDK, how to build plugin libraries using it, and how +to install the example plugins so you can use them in a host. + + +What's In This SDK +================== + +This SDK contains the following: + + +vamp/vamp.h +----------- + +The formal C language plugin API for Vamp plugins. + +A Vamp plugin is a dynamic library (.so, .dll or .dylib depending on +platform) exposing one C-linkage entry point (vampGetPluginDescriptor) +which returns data defined in the rest of this C header. + +Although the C API is the official API for Vamp, we don't recommend +that you program directly to it. The C++ abstractions found in the +vamp-sdk and vamp-hostsdk directories (below) are preferable for most +purposes and are more thoroughly documented. + + +vamp-sdk +-------- + +C++ classes for implementing Vamp plugins. + +Plugins should subclass Vamp::Plugin and then use Vamp::PluginAdapter +to expose the correct C API for the plugin. Plugin authors should +read vamp-sdk/PluginBase.h and Plugin.h for code documentation. + +See "examples" below for details of the example plugins in the SDK, +from which you are welcome to take code and inspiration. + +Plugins should link with -lvamp-sdk. + + +vamp-hostsdk +------------ + +C++ classes for implementing Vamp hosts. + +Hosts will normally use a Vamp::PluginHostAdapter to convert each +plugin's exposed C API back into a useful Vamp::Plugin C++ object. + +The Vamp::HostExt namespace contains several additional C++ classes to +do this work for them, and make the host's life easier: + + - Vamp::HostExt::PluginLoader provides a very easy interface for a + host to discover, load, and find out category information about the + available plugins. Most Vamp hosts will probably want to use this + class. + + - Vamp::HostExt::PluginInputDomainAdapter provides a simple means for + hosts to handle plugins that want frequency-domain input, without + having to convert the input themselves. + + - Vamp::HostExt::PluginChannelAdapter provides a simple means for + hosts to use plugins that do not necessarily support the same number + of audio channels as they have available, without having to apply a + channel management / mixdown policy themselves. + + - Vamp::HostExt::PluginBufferingAdapter provides a means for hosts to + avoid having to negotiate the input step and block size, instead + permitting the host to use any block size they desire (and a step + size equal to it). This is particularly useful for "streaming" hosts + that cannot seek backwards in the input audio stream and so would + otherwise need to implement an additional buffer to support step + sizes smaller than the block size. + + - Vamp::HostExt::PluginSummarisingAdapter provides summarisation + methods such as mean and median averages of output features, for use + in any context where an available plugin produces individual values + but the result that is actually needed is some sort of aggregate. + +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. + + +examples +-------- + +Example plugins implemented using the C++ classes. + +These plugins are intended to be useful examples you can draw code +from in order to provide the basic shape and structure of a Vamp +plugin. They are also intended to be correct and useful, if simple. + + - ZeroCrossing calculates the positions and density of zero-crossing + points in an audio waveform. + + - SpectralCentroid calculates the centre of gravity of the frequency + domain representation of each block of audio. + + - PowerSpectrum calculates a power spectrum from the input audio. + Actually, it doesn't do any work except calculating power from a + cartesian complex FFT output. The work of calculating this frequency + domain output is done for it by the host or host SDK; the plugin just + needs to declare that it wants frequency domain input. This is the + simplest of the example plugins. + + - AmplitudeFollower is a simple implementation of SuperCollider's + amplitude-follower algorithm. + + - PercussionOnsetDetector estimates the locations of percussive + onsets using a simple method described in "Drum Source Separation + using Percussive Feature Detection and Spectral Modulation" by Dan + Barry, Derry Fitzgerald, Eugene Coyle and Bob Lawlor, ISSC 2005. + + - FixedTempoEstimator calculates a single beats-per-minute value + which is an estimate of the tempo of a piece of music that is assumed + to be of fixed tempo, using autocorrelation of a frequency domain + energy rise metric. It has several outputs that return intermediate + results used in the calculation, and may be a useful example of a + plugin having several outputs with varying feature structures. + + +skeleton +-------- + +Skeleton code that could be used as a template for your new plugin +implementation. + + +host +---- + +A simple command-line Vamp host, capable of loading a plugin and using +it to process a complete audio file, with its default parameters. + +This host also contains a number of options for listing the installed +plugins and their properties in various formats. For that reason, it +isn't really as simple as one might hope. The core of the code is +still reasonably straightforward, however. + + +Plugin Lookup and Categorisation +================================ + +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 the path +returned by getPluginPath 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. 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. + + +Licensing +========= + +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. + + +See Also +======== + +Sonic Visualiser, an interactive open-source graphical audio +inspection, analysis and visualisation tool supporting Vamp plugins. +http://www.sonicvisualiser.org/ + + +Authors +======= + +Vamp and the Vamp SDK were designed and made at the Centre for Digital +Music at Queen Mary, University of London. + +The SDK was written by Chris Cannam, copyright (c) 2005-2009 +Chris Cannam and QMUL. + +Mark Sandler and Christian Landone provided ideas and direction, and +Mark Levy, Dan Stowell, Martin Gasser and Craig Sapp provided testing +and other input for the 1.0 API and SDK. The API also uses some ideas +from prior plugin systems, notably DSSI (http://dssi.sourceforge.net) +and FEAPI (http://feapi.sourceforge.net). +