| 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@14 | 80  * examples | 
| cannam@14 | 81 | 
| cannam@14 | 82 Example plugins implemented using the C++ classes.  ZeroCrossing | 
| cannam@14 | 83 calculates the positions and density of zero-crossing points in an | 
| cannam@35 | 84 audio waveform.  SpectralCentroid calculates the centre of gravity of | 
| cannam@14 | 85 the frequency domain representation of each block of audio. | 
| cannam@35 | 86 PercussionOnsetDetector estimates the locations of percussive onsets | 
| cannam@35 | 87 using a simple method described in "Drum Source Separation using | 
| cannam@35 | 88 Percussive Feature Detection and Spectral Modulation" by Dan Barry, | 
| cannam@35 | 89 Derry Fitzgerald, Eugene Coyle and Bob Lawlor, ISSC 2005. | 
| cannam@14 | 90 | 
| cannam@14 | 91  * host | 
| cannam@14 | 92 | 
| cannam@16 | 93 A simple command-line Vamp host, capable of loading a plugin and using | 
| cannam@16 | 94 it to process a complete audio file, with its default parameters. | 
| cannam@16 | 95 Requires libsndfile. | 
| cannam@14 | 96 | 
| cannam@40 | 97 | 
| cannam@40 | 98 Plugin Lookup and Categorisation | 
| cannam@40 | 99 ================================ | 
| cannam@40 | 100 | 
| cannam@40 | 101 The Vamp API does not officially specify how to load plugin libraries | 
| cannam@40 | 102 or where to find them.  However, the SDK does include a function | 
| cannam@40 | 103 (Vamp::PluginHostAdapter::getPluginPath()) that returns a recommended | 
| cannam@40 | 104 directory search path that hosts may use for plugin libraries. | 
| cannam@40 | 105 | 
| cannam@40 | 106 Our suggestion for a host is to search each directory in this path for | 
| cannam@40 | 107 .DLL (on Windows), .so (on Linux, Solaris, BSD etc) or .dylib (on | 
| cannam@40 | 108 OS/X) files, then to load each one and perform a dynamic name lookup | 
| cannam@40 | 109 on the vampGetPluginDescriptor function to enumerate the plugins in | 
| cannam@40 | 110 the library.  The example host has some code that may help, but this | 
| cannam@40 | 111 operation will necessarily be system-dependent. | 
| cannam@40 | 112 | 
| cannam@40 | 113 Vamp also has an informal convention for sorting plugins into | 
| cannam@40 | 114 functional categories.  In addition to the library file itself, a | 
| cannam@40 | 115 plugin library may install a category file with the same name as the | 
| cannam@40 | 116 library but .cat extension.  The existence and format of this file are | 
| cannam@40 | 117 not specified by the Vamp API, but by convention the file may contain | 
| cannam@40 | 118 lines of the format | 
| cannam@40 | 119 | 
| cannam@40 | 120 vamp:pluginlibrary:pluginname::General Category > Specific Category | 
| cannam@40 | 121 | 
| cannam@40 | 122 which a host may read and use to assign plugins a location within a | 
| cannam@40 | 123 category tree for display to the user.  The expectation is that | 
| cannam@40 | 124 advanced users may also choose to set up their own preferred category | 
| cannam@40 | 125 trees, which is why this information is not queried as part of the | 
| cannam@40 | 126 Vamp API itself. | 
| cannam@32 | 127 | 
| cannam@14 | 128 | 
| cannam@42 | 129 Building and Installing the SDK and Examples | 
| cannam@42 | 130 ============================================ | 
| cannam@14 | 131 | 
| cannam@42 | 132 To build the SDK, the simple host, and the example plugins, edit the | 
| cannam@42 | 133 Makefile to suit your platform according to the comments in it, then | 
| cannam@42 | 134 run "make". | 
| cannam@42 | 135 | 
| cannam@42 | 136 Installing the example plugins so that they can be found by other Vamp | 
| cannam@42 | 137 hosts depends on your platform: | 
| cannam@42 | 138 | 
| cannam@44 | 139  * Windows: copy the files | 
| cannam@44 | 140       examples/vamp-example-plugins.dll | 
| cannam@44 | 141       examples/vamp-example-plugins.cat | 
| cannam@44 | 142    to | 
| cannam@44 | 143       C:\Program Files\Vamp Plugins | 
| cannam@42 | 144 | 
| cannam@44 | 145  * Linux: copy the files | 
| cannam@44 | 146       examples/vamp-example-plugins.so | 
| cannam@44 | 147       examples/vamp-example-plugins.cat | 
| cannam@44 | 148    to | 
| cannam@44 | 149       /usr/local/lib/vamp/ | 
| cannam@42 | 150 | 
| cannam@44 | 151  * OS/X: copy the files | 
| cannam@44 | 152       examples/vamp-example-plugins.dylib | 
| cannam@44 | 153       examples/vamp-example-plugins.cat | 
| cannam@44 | 154    to | 
| cannam@44 | 155       /Library/Audio/Plug-Ins/Vamp | 
| cannam@42 | 156 | 
| cannam@42 | 157 When building a plugin or host of your own using the SDK, you will | 
| cannam@44 | 158 need to include the headers from the vamp-sdk directory; then when | 
| cannam@44 | 159 linking your plugin or host, we suggest statically linking the SDK | 
| cannam@44 | 160 code (in preference to distributing it alongside your program in DLL | 
| cannam@44 | 161 form).  An easy way to do this, if using a project-based build tool | 
| cannam@42 | 162 such as Visual Studio or XCode, is simply to add the .cpp files in the | 
| cannam@42 | 163 vamp-sdk directory to your project. | 
| cannam@14 | 164 | 
| cannam@14 | 165 | 
| cannam@14 | 166 Licensing | 
| cannam@14 | 167 ========= | 
| cannam@14 | 168 | 
| cannam@18 | 169 This plugin SDK is freely redistributable under a "new-style BSD" | 
| cannam@42 | 170 licence.  See the file COPYING for more details.  In short, you may | 
| cannam@42 | 171 modify and redistribute the SDK and example plugins within any | 
| cannam@42 | 172 commercial or non-commercial, proprietary or open-source plugin or | 
| cannam@42 | 173 application under almost any conditions, with no obligation to provide | 
| cannam@42 | 174 source code, provided you retain the original copyright note. | 
| cannam@14 | 175 | 
| cannam@14 | 176 | 
| cannam@14 | 177 See Also | 
| cannam@14 | 178 ======== | 
| cannam@14 | 179 | 
| cannam@14 | 180 Sonic Visualiser, an interactive open-source graphical audio | 
| cannam@14 | 181 inspection, analysis and visualisation tool supporting Vamp plugins. | 
| cannam@35 | 182 http://www.sonicvisualiser.org/ | 
| cannam@14 | 183 | 
| cannam@14 | 184 | 
| cannam@44 | 185 Authors | 
| cannam@44 | 186 ======= | 
| cannam@44 | 187 | 
| cannam@44 | 188 Vamp and the Vamp SDK were designed and made at the Centre for Digital | 
| cannam@44 | 189 Music at Queen Mary, University of London.  The SDK code was written | 
| cannam@44 | 190 by Chris Cannam, copyright (c) 2005-2006 Chris Cannam.  Mark Sandler | 
| cannam@44 | 191 and Christian Landone provided ideas and direction, and Mark Levy, Dan | 
| cannam@44 | 192 Stowell, Martin Gasser and Craig Sapp provided testing and other input | 
| cannam@44 | 193 for the 1.0 API and SDK.  The API reuses some ideas from several prior | 
| cannam@44 | 194 plugin systems, notably DSSI (http://dssi.sourceforge.net) and FEAPI | 
| cannam@44 | 195 (http://feapi.sourceforge.net). | 
| cannam@44 | 196 |