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
|