| cannam@14 | 1 | 
| cannam@14 | 2 Vamp | 
| cannam@14 | 3 ==== | 
| cannam@14 | 4 | 
| cannam@14 | 5 An API for audio analysis and feature extraction plugins. | 
| cannam@14 | 6 | 
| cannam@44 | 7    http://www.vamp-plugins.org/ | 
| cannam@44 | 8 | 
| cannam@14 | 9 Vamp is an API for C and C++ plugins that process sampled audio data | 
| cannam@18 | 10 to produce descriptive output (measurements or semantic observations). | 
| cannam@14 | 11 | 
| cannam@14 | 12 The principal differences between Vamp and a real-time audio | 
| cannam@14 | 13 processing plugin system such as VST are: | 
| cannam@14 | 14 | 
| cannam@14 | 15  * Vamp plugins may output complex multidimensional data with labels. | 
| cannam@14 | 16    As a consequence, they are likely to work best when the output | 
| cannam@14 | 17    data has a much lower sampling rate than the input.  (This also | 
| cannam@14 | 18    means it is usually desirable to implement them in C++ using the | 
| cannam@14 | 19    high-level base class provided rather than use the raw C API.) | 
| cannam@14 | 20 | 
| cannam@14 | 21  * While Vamp plugins receive data block-by-block, they are not | 
| cannam@14 | 22    required to return output immediately on receiving the input. | 
| cannam@14 | 23    A Vamp plugin may be non-causal, preferring to store up data | 
| cannam@14 | 24    based on its input until the end of a processing run and then | 
| cannam@14 | 25    return all results at once. | 
| cannam@14 | 26 | 
| cannam@14 | 27  * Vamp plugins have more control over their inputs than a typical | 
| cannam@14 | 28    real-time processing plugin.  For example, they can indicate to | 
| cannam@18 | 29    the host their preferred processing block and step sizes, and these | 
| cannam@18 | 30    may differ. | 
| cannam@18 | 31 | 
| cannam@18 | 32  * Vamp plugins may ask to receive data in the frequency domain | 
| cannam@18 | 33    instead of the time domain.  The host takes the responsibility | 
| cannam@18 | 34    for converting the input data using an FFT of windowed frames. | 
| cannam@18 | 35    This simplifies plugins that do straightforward frequency-domain | 
| cannam@18 | 36    processing and permits the host to cache frequency-domain data | 
| cannam@18 | 37    when possible. | 
| cannam@14 | 38 | 
| cannam@14 | 39  * A Vamp plugin is configured once before each processing run, and | 
| cannam@14 | 40    receives no further parameter changes during use -- unlike real | 
| cannam@14 | 41    time plugin APIs in which the input parameters may change at any | 
| cannam@14 | 42    time.  This also means that fundamental properties such as the | 
| cannam@14 | 43    number of values per output or the preferred processing block | 
| cannam@18 | 44    size may depend on the input parameters. | 
| cannam@14 | 45 | 
| cannam@38 | 46  * Vamp plugins do not have to be able to run in real time. | 
| cannam@38 | 47 | 
| cannam@14 | 48 | 
| cannam@14 | 49 About this SDK | 
| cannam@14 | 50 ============== | 
| cannam@14 | 51 | 
| cannam@14 | 52 This Software Development Kit contains the following: | 
| cannam@14 | 53 | 
| cannam@14 | 54  * vamp/vamp.h | 
| cannam@14 | 55 | 
| cannam@14 | 56 The formal C language plugin API for Vamp plugins. | 
| cannam@14 | 57 | 
| cannam@14 | 58 A Vamp plugin is a dynamic library (.so, .dll or .dylib depending on | 
| cannam@14 | 59 platform) exposing one C-linkage entry point (vampGetPluginDescriptor) | 
| cannam@14 | 60 which returns data defined in the rest of this C header. | 
| cannam@14 | 61 | 
| cannam@14 | 62 Although this is the official API for Vamp, we don't recommend that | 
| cannam@14 | 63 you program directly to it.  The C++ abstraction in the SDK directory | 
| cannam@18 | 64 (below) is likely to be preferable for most purposes, and is better | 
| cannam@14 | 65 documented. | 
| cannam@14 | 66 | 
| cannam@14 | 67  * vamp-sdk | 
| cannam@14 | 68 | 
| cannam@14 | 69 C++ classes for straightforwardly implementing Vamp plugins and hosts. | 
| cannam@18 | 70 | 
| cannam@18 | 71 Plugins should subclass Vamp::Plugin and then use a | 
| cannam@18 | 72 Vamp::PluginAdapter to expose the correct C API for the plugin.  Read | 
| cannam@51 | 73 vamp-sdk/PluginBase.h and Plugin.h for code documentation.  Plugins | 
| cannam@51 | 74 should link with -lvamp-sdk. | 
| cannam@18 | 75 | 
| cannam@14 | 76 Hosts may use the Vamp::PluginHostAdapter to convert the loaded | 
| cannam@51 | 77 plugin's C API back into a Vamp::Plugin object.  Hosts should link | 
| cannam@51 | 78 with -lvamp-hostsdk. | 
| cannam@14 | 79 | 
| cannam@64 | 80  * vamp-sdk/hostext | 
| cannam@64 | 81 | 
| cannam@75 | 82 Additional C++ classes to make a host's life easier (introduced in | 
| cannam@75 | 83 version 1.1 of the Vamp SDK). | 
| cannam@64 | 84 | 
| cannam@64 | 85 Vamp::HostExt::PluginLoader provides a very simple interface for a | 
| cannam@64 | 86 host to discover, load, and find out category information about the | 
| cannam@64 | 87 available plugins.  Most "casual" Vamp hosts will probably want to use | 
| cannam@64 | 88 this class. | 
| cannam@64 | 89 | 
| cannam@64 | 90 Vamp::HostExt::PluginInputDomainAdapter provides a simple means for | 
| cannam@64 | 91 hosts to handle plugins that expect frequency-domain input, without | 
| cannam@64 | 92 having to convert the input themselves. | 
| cannam@64 | 93 | 
| cannam@64 | 94 Vamp::HostExt::PluginChannelAdapter provides a simple means for hosts | 
| cannam@64 | 95 to use plugins that do not necessarily support the same number of | 
| cannam@64 | 96 audio channels as they have available, without having to apply a | 
| cannam@64 | 97 channel management / mixdown policy themselves. | 
| cannam@64 | 98 | 
| cannam@75 | 99 The PluginLoader class can also use the input domain and channel | 
| cannam@75 | 100 adapters automatically to make the entire conversion process | 
| cannam@75 | 101 transparent to the host if required. | 
| cannam@64 | 102 | 
| cannam@14 | 103  * examples | 
| cannam@14 | 104 | 
| cannam@14 | 105 Example plugins implemented using the C++ classes.  ZeroCrossing | 
| cannam@14 | 106 calculates the positions and density of zero-crossing points in an | 
| cannam@35 | 107 audio waveform.  SpectralCentroid calculates the centre of gravity of | 
| cannam@14 | 108 the frequency domain representation of each block of audio. | 
| cannam@35 | 109 PercussionOnsetDetector estimates the locations of percussive onsets | 
| cannam@35 | 110 using a simple method described in "Drum Source Separation using | 
| cannam@35 | 111 Percussive Feature Detection and Spectral Modulation" by Dan Barry, | 
| cannam@35 | 112 Derry Fitzgerald, Eugene Coyle and Bob Lawlor, ISSC 2005. | 
| cannam@14 | 113 | 
| cannam@14 | 114  * host | 
| cannam@14 | 115 | 
| cannam@16 | 116 A simple command-line Vamp host, capable of loading a plugin and using | 
| cannam@16 | 117 it to process a complete audio file, with its default parameters. | 
| cannam@64 | 118 Requires libsndfile (http://www.mega-nerd.com/libsndfile/). | 
| cannam@64 | 119 | 
| cannam@64 | 120 If you don't have libsndfile, you may want to edit the Makefile to | 
| cannam@75 | 121 change the default build target from "all" to "sdk", so as to compile | 
| cannam@75 | 122 only the SDK and not the host. | 
| cannam@14 | 123 | 
| cannam@40 | 124 | 
| cannam@40 | 125 Plugin Lookup and Categorisation | 
| cannam@40 | 126 ================================ | 
| cannam@40 | 127 | 
| cannam@40 | 128 The Vamp API does not officially specify how to load plugin libraries | 
| cannam@40 | 129 or where to find them.  However, the SDK does include a function | 
| cannam@40 | 130 (Vamp::PluginHostAdapter::getPluginPath()) that returns a recommended | 
| cannam@75 | 131 directory search path that hosts may use for plugin libraries, and a | 
| cannam@75 | 132 class (Vamp::HostExt::PluginLoader) that implements a sensible | 
| cannam@75 | 133 cross-platform lookup policy using this path.  We recommend using this | 
| cannam@75 | 134 class in your host unless you have a good reason not to want to.  This | 
| cannam@75 | 135 implementation also permits the user to set the environment variable | 
| cannam@75 | 136 VAMP_PATH to override the default path if desired. | 
| cannam@40 | 137 | 
| cannam@75 | 138 The policy used by Vamp::HostExt::PluginLoader -- and our | 
| cannam@75 | 139 recommendation for any host -- is to search each directory in the path | 
| cannam@75 | 140 returned by getPluginPath for .DLL (on Windows), .so (on Linux, | 
| cannam@75 | 141 Solaris, BSD etc) or .dylib (on OS/X) files, then to load each one and | 
| cannam@75 | 142 perform a dynamic name lookup on the vampGetPluginDescriptor function | 
| cannam@75 | 143 to enumerate the plugins in the library.  This operation will | 
| cannam@75 | 144 necessarily be system-dependent. | 
| cannam@40 | 145 | 
| cannam@40 | 146 Vamp also has an informal convention for sorting plugins into | 
| cannam@40 | 147 functional categories.  In addition to the library file itself, a | 
| cannam@40 | 148 plugin library may install a category file with the same name as the | 
| cannam@40 | 149 library but .cat extension.  The existence and format of this file are | 
| cannam@40 | 150 not specified by the Vamp API, but by convention the file may contain | 
| cannam@40 | 151 lines of the format | 
| cannam@40 | 152 | 
| cannam@40 | 153 vamp:pluginlibrary:pluginname::General Category > Specific Category | 
| cannam@40 | 154 | 
| cannam@40 | 155 which a host may read and use to assign plugins a location within a | 
| cannam@40 | 156 category tree for display to the user.  The expectation is that | 
| cannam@40 | 157 advanced users may also choose to set up their own preferred category | 
| cannam@40 | 158 trees, which is why this information is not queried as part of the | 
| cannam@75 | 159 Vamp plugin's API itself.  The Vamp::HostExt::PluginLoader class also | 
| cannam@75 | 160 provides support for plugin category lookup using this scheme. | 
| cannam@32 | 161 | 
| cannam@14 | 162 | 
| cannam@42 | 163 Building and Installing the SDK and Examples | 
| cannam@42 | 164 ============================================ | 
| cannam@14 | 165 | 
| cannam@42 | 166 To build the SDK, the simple host, and the example plugins, edit the | 
| cannam@42 | 167 Makefile to suit your platform according to the comments in it, then | 
| cannam@42 | 168 run "make". | 
| cannam@42 | 169 | 
| cannam@42 | 170 Installing the example plugins so that they can be found by other Vamp | 
| cannam@42 | 171 hosts depends on your platform: | 
| cannam@42 | 172 | 
| cannam@44 | 173  * Windows: copy the files | 
| cannam@44 | 174       examples/vamp-example-plugins.dll | 
| cannam@44 | 175       examples/vamp-example-plugins.cat | 
| cannam@44 | 176    to | 
| cannam@44 | 177       C:\Program Files\Vamp Plugins | 
| cannam@42 | 178 | 
| cannam@44 | 179  * Linux: copy the files | 
| cannam@44 | 180       examples/vamp-example-plugins.so | 
| cannam@44 | 181       examples/vamp-example-plugins.cat | 
| cannam@44 | 182    to | 
| cannam@44 | 183       /usr/local/lib/vamp/ | 
| cannam@42 | 184 | 
| cannam@44 | 185  * OS/X: copy the files | 
| cannam@44 | 186       examples/vamp-example-plugins.dylib | 
| cannam@44 | 187       examples/vamp-example-plugins.cat | 
| cannam@44 | 188    to | 
| cannam@44 | 189       /Library/Audio/Plug-Ins/Vamp | 
| cannam@42 | 190 | 
| cannam@42 | 191 When building a plugin or host of your own using the SDK, you will | 
| cannam@44 | 192 need to include the headers from the vamp-sdk directory; then when | 
| cannam@44 | 193 linking your plugin or host, we suggest statically linking the SDK | 
| cannam@44 | 194 code (in preference to distributing it alongside your program in DLL | 
| cannam@44 | 195 form).  An easy way to do this, if using a project-based build tool | 
| cannam@42 | 196 such as Visual Studio or XCode, is simply to add the .cpp files in the | 
| cannam@42 | 197 vamp-sdk directory to your project. | 
| cannam@14 | 198 | 
| cannam@14 | 199 | 
| cannam@14 | 200 Licensing | 
| cannam@14 | 201 ========= | 
| cannam@14 | 202 | 
| cannam@18 | 203 This plugin SDK is freely redistributable under a "new-style BSD" | 
| cannam@42 | 204 licence.  See the file COPYING for more details.  In short, you may | 
| cannam@42 | 205 modify and redistribute the SDK and example plugins within any | 
| cannam@42 | 206 commercial or non-commercial, proprietary or open-source plugin or | 
| cannam@42 | 207 application under almost any conditions, with no obligation to provide | 
| cannam@42 | 208 source code, provided you retain the original copyright note. | 
| cannam@14 | 209 | 
| cannam@14 | 210 | 
| cannam@14 | 211 See Also | 
| cannam@14 | 212 ======== | 
| cannam@14 | 213 | 
| cannam@14 | 214 Sonic Visualiser, an interactive open-source graphical audio | 
| cannam@14 | 215 inspection, analysis and visualisation tool supporting Vamp plugins. | 
| cannam@35 | 216 http://www.sonicvisualiser.org/ | 
| cannam@14 | 217 | 
| cannam@14 | 218 | 
| cannam@44 | 219 Authors | 
| cannam@44 | 220 ======= | 
| cannam@44 | 221 | 
| cannam@44 | 222 Vamp and the Vamp SDK were designed and made at the Centre for Digital | 
| cannam@64 | 223 Music at Queen Mary, University of London. | 
| cannam@44 | 224 | 
| cannam@64 | 225 The SDK was written by Chris Cannam, copyright (c) 2005-2007 | 
| cannam@64 | 226 Chris Cannam and QMUL. | 
| cannam@64 | 227 | 
| cannam@64 | 228 Mark Sandler and Christian Landone provided ideas and direction, and | 
| cannam@64 | 229 Mark Levy, Dan Stowell, Martin Gasser and Craig Sapp provided testing | 
| cannam@64 | 230 and other input for the 1.0 API and SDK.  The API also uses some ideas | 
| cannam@64 | 231 from prior plugin systems, notably DSSI (http://dssi.sourceforge.net) | 
| cannam@64 | 232 and FEAPI (http://feapi.sourceforge.net). | 
| cannam@64 | 233 |