Mercurial > hg > vamp-plugin-sdk
comparison src/doc-overview @ 229:3451f7dfa2be distinct-libraries
* more moving
author | cannam |
---|---|
date | Thu, 06 Nov 2008 16:55:15 +0000 |
parents | |
children | cc467e52da4c |
comparison
equal
deleted
inserted
replaced
228:e58242c9ff85 | 229:3451f7dfa2be |
---|---|
1 | |
2 /** \mainpage Vamp Plugin SDK | |
3 | |
4 \section about About Vamp | |
5 | |
6 Vamp is an API for C and C++ plugins that process sampled audio data | |
7 to produce descriptive output (measurements or semantic observations). | |
8 Find more information at http://www.vamp-plugins.org/ . | |
9 | |
10 Although the official API for Vamp plugins is defined in C for maximum | |
11 binary compatibility, we strongly recommend using the provided C++ | |
12 classes in the SDK to implement your own plugins and hosts. | |
13 | |
14 \section plugins For Plugins | |
15 | |
16 Plugins should subclass Vamp::Plugin, and then use a | |
17 Vamp::PluginAdapter to expose the correct C API for the plugin. Read | |
18 the documentation for Vamp::PluginBase and Vamp::Plugin before | |
19 starting. | |
20 | |
21 Plugins should be compiled and linked into dynamic libraries using the | |
22 usual convention for your platform, and should link (preferably | |
23 statically) with -lvamp-sdk. Any number of plugins can reside in a | |
24 single dynamic library. See plugins.cpp in the example plugins | |
25 directory for the sort of code that will need to accompany your plugin | |
26 class or classes, to make it possible for a host to look up your | |
27 plugins properly. | |
28 | |
29 You will also need to ensure that the entry point | |
30 vampGetPluginDescriptor is properly exported (made public) from your | |
31 shared library. The method to do this depends on your linker; for | |
32 example, when using the Windows Visual Studio linker, use the linker | |
33 flag "/EXPORT:vampGetPluginDescriptor". Exported symbols are the | |
34 default with most other current platforms' linkers. | |
35 | |
36 The following example plugins are provided. You may legally reuse any | |
37 amount of the code from these examples in any plugins you write, | |
38 whether proprietary or open-source. | |
39 | |
40 - ZeroCrossing calculates the positions and density of zero-crossing | |
41 points in an audio waveform. | |
42 | |
43 - SpectralCentroid calculates the centre of gravity of the frequency | |
44 domain representation of each block of audio. | |
45 | |
46 - AmplitudeFollower is a simple implementation of SuperCollider's | |
47 amplitude-follower algorithm. | |
48 | |
49 - PercussionOnsetDetector estimates the locations of percussive | |
50 onsets using a simple method described in "Drum Source Separation | |
51 using Percussive Feature Detection and Spectral Modulation" by Dan | |
52 Barry, Derry Fitzgerald, Eugene Coyle and Bob Lawlor, ISSC 2005. | |
53 | |
54 - FixedTempoEstimator calculates a single bpm value which is an | |
55 estimate of the tempo of a piece of music that is assumed to be of | |
56 fixed tempo, using autocorrelation of a frequency domain energy rise | |
57 metric. It has several outputs that return intermediate results used | |
58 in the calculation, and may be a useful example of a plugin having | |
59 several outputs with varying feature structures. | |
60 | |
61 \section hosts For Hosts | |
62 | |
63 Hosts will normally use a Vamp::PluginHostAdapter to convert each | |
64 plugin's exposed C API back into a useful Vamp::Plugin C++ object. | |
65 | |
66 Starting with version 1.1 of the Vamp SDK, there are several classes | |
67 in the Vamp::HostExt namespace that aim to make the host's life as | |
68 easy as possible: | |
69 | |
70 - Vamp::HostExt::PluginLoader provides a very simple interface for a | |
71 host to discover, load, and find out category information about the | |
72 available plugins. Most "casual" Vamp hosts will probably want to | |
73 use this class. | |
74 | |
75 - Vamp::HostExt::PluginInputDomainAdapter provides a simple means for | |
76 hosts to handle plugins that expect frequency-domain input, without | |
77 having to convert the input themselves. | |
78 | |
79 - Vamp::HostExt::PluginChannelAdapter provides a simple means for | |
80 hosts to use plugins that do not necessarily support the same number | |
81 of audio channels as they have available, without having to apply a | |
82 channel management / mixdown policy themselves. | |
83 | |
84 - Vamp::HostExt::PluginBufferingAdapter (new in version 1.2) provides | |
85 a means for hosts to avoid having to negotiate the input step and | |
86 block size, instead permitting the host to use any block size they | |
87 desire (and a step size equal to it). This is particularly useful | |
88 for "streaming" hosts that cannot seek backwards in the input audio | |
89 stream and so would otherwise need to implement an additional buffer | |
90 to support step sizes smaller than the block size. | |
91 | |
92 - Vamp::HostExt::PluginSummarisingAdapter (new in version 2.0) | |
93 provides summarisation methods such as mean and median averages of | |
94 output features, for use in any context where an available plugin | |
95 produces individual values but the result that is actually needed | |
96 is some sort of aggregate. | |
97 | |
98 The PluginLoader class can also use the input domain, channel, and | |
99 buffering adapters automatically to make these conversions transparent | |
100 to the host if required. | |
101 | |
102 Hosts should link with -lvamp-hostsdk. | |
103 | |
104 (The following notes in this section are mostly relevant for | |
105 developers that are not using the HostExt classes, or that wish to | |
106 know more about the policy they implement.) | |
107 | |
108 The Vamp API does not officially specify how to load plugin libraries | |
109 or where to find them. However, the SDK does include a function | |
110 (Vamp::PluginHostAdapter::getPluginPath()) that returns a recommended | |
111 directory search path that hosts may use for plugin libraries. | |
112 | |
113 Our suggestion for a host is to search each directory in this path for | |
114 .DLL (on Windows), .so (on Linux, Solaris, BSD etc) or .dylib (on | |
115 OS/X) files, then to load each one and perform a dynamic name lookup | |
116 on the vampGetPluginDescriptor function to enumerate the plugins in | |
117 the library. The example host has some code that may help, but this | |
118 operation will necessarily be system-dependent. | |
119 | |
120 Vamp also has an informal convention for sorting plugins into | |
121 functional categories. In addition to the library file itself, a | |
122 plugin library may install a category file with the same name as the | |
123 library but .cat extension. The existence and format of this file are | |
124 not specified by the Vamp API, but by convention the file may contain | |
125 lines of the format | |
126 | |
127 \code | |
128 vamp:pluginlibrary:pluginname::General Category > Specific Category | |
129 \endcode | |
130 | |
131 which a host may read and use to assign plugins a location within a | |
132 category tree for display to the user. The expectation is that | |
133 advanced users may also choose to set up their own preferred category | |
134 trees, which is why this information is not queried as part of the | |
135 Vamp API itself. | |
136 | |
137 There is an example host in the "host" directory from which code may | |
138 be drawn. | |
139 | |
140 \section license License | |
141 | |
142 This plugin SDK is freely redistributable under a "new-style BSD" | |
143 licence. See the file COPYING for more details. In short, you may | |
144 modify and redistribute the SDK and example plugins within any | |
145 commercial or non-commercial, proprietary or open-source plugin or | |
146 application under almost any conditions, with no obligation to provide | |
147 source code, provided you retain the original copyright note. | |
148 | |
149 | |
150 */ |