@@ -27,7 +33,7 @@
00006 An API for audio analysis and feature extraction plugins.00007
00008 Centre for Digital Music, Queen Mary, University of London.
-00009 Copyright 2006-2008 Chris Cannam and QMUL.
+00009 Copyright 2006-2009 Chris Cannam and QMUL.00010 00011 Permission is hereby granted, free of charge, to any person00012 obtaining a copy of this software and associated documentation
@@ -100,8 +106,8 @@
00083
00084 #endif
-Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/FixedTempoEstimator_8h.html
--- a/code-doc/FixedTempoEstimator_8h.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/FixedTempoEstimator_8h.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: FixedTempoEstimator.h File Reference
+
-
-
+
@@ -27,7 +33,7 @@
00006 An API for audio analysis and feature extraction plugins.00007
00008 Centre for Digital Music, Queen Mary, University of London.
-00009 Copyright 2006-2007 Chris Cannam and QMUL.
+00009 Copyright 2006-2009 Chris Cannam and QMUL.00010 This file by Mark Levy and Chris Cannam, Copyright 2007-2008 QMUL.00011 00012 Permission is hereby granted, free of charge, to any person
@@ -114,8 +120,8 @@
00193
00194 #endif
-Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/PluginBufferingAdapter_8h.html
--- a/code-doc/PluginBufferingAdapter_8h.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/PluginBufferingAdapter_8h.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: PluginBufferingAdapter.h File Reference
+
-
-
+
PluginBufferingAdapter is a Vamp plugin adapter that allows plugins to be used by a host supplying an audio stream in non-overlapping buffers of arbitrary size. More...
PluginBufferingAdapter is a Vamp plugin adapter that allows plugins to be used by a host supplying an audio stream in non-overlapping buffers of arbitrary size. More...
-Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/PluginChannelAdapter_8h-source.html
--- a/code-doc/PluginChannelAdapter_8h-source.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/PluginChannelAdapter_8h-source.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: PluginChannelAdapter.h Source File
+
-
-
+
@@ -27,7 +33,7 @@
00006 An API for audio analysis and feature extraction plugins.00007
00008 Centre for Digital Music, Queen Mary, University of London.
-00009 Copyright 2006-2007 Chris Cannam and QMUL.
+00009 Copyright 2006-2009 Chris Cannam and QMUL.00010 00011 Permission is hereby granted, free of charge, to any person00012 obtaining a copy of this software and associated documentation
@@ -92,8 +98,8 @@
00148
00149 #endif
-Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/PluginChannelAdapter_8h.html
--- a/code-doc/PluginChannelAdapter_8h.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/PluginChannelAdapter_8h.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: PluginChannelAdapter.h File Reference
+
-
-
+
PluginChannelAdapter is a Vamp plugin adapter that implements a policy for management of plugins that expect a different number of input channels from the number actually available in the source audio data. More...
PluginChannelAdapter is a Vamp plugin adapter that implements a policy for management of plugins that expect a different number of input channels from the number actually available in the source audio data. More...
-Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/PluginHostAdapter_8h-source.html
--- a/code-doc/PluginHostAdapter_8h-source.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/PluginHostAdapter_8h-source.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: PluginHostAdapter.h Source File
+
-
-
+
@@ -27,7 +33,7 @@
00006 An API for audio analysis and feature extraction plugins.00007
00008 Centre for Digital Music, Queen Mary, University of London.
-00009 Copyright 2006-2007 Chris Cannam and QMUL.
+00009 Copyright 2006-2009 Chris Cannam and QMUL.00010 00011 Permission is hereby granted, free of charge, to any person00012 obtaining a copy of this software and associated documentation
@@ -127,8 +133,8 @@
00242 #endif00243
-Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/PluginLoader_8h.html
--- a/code-doc/PluginLoader_8h.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/PluginLoader_8h.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: PluginLoader.h File Reference
+
-
-
+
Vamp::HostExt::PluginLoader is a convenience class for discovering and loading Vamp plugins using the typical plugin-path, library naming, and categorisation conventions described in the Vamp SDK documentation. More...
Vamp::HostExt::PluginLoader is a convenience class for discovering and loading Vamp plugins using the typical plugin-path, library naming, and categorisation conventions described in the Vamp SDK documentation. More...
-Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/PluginSummarisingAdapter_8h-source.html
--- a/code-doc/PluginSummarisingAdapter_8h-source.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/PluginSummarisingAdapter_8h-source.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: PluginSummarisingAdapter.h Source File
+
-
-
+
PluginSummarisingAdapter is a Vamp plugin adapter that 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. More...
PluginSummarisingAdapter is a Vamp plugin adapter that 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. More...
-Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/PluginWrapper_8h-source.html
--- a/code-doc/PluginWrapper_8h-source.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/PluginWrapper_8h-source.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: PluginWrapper.h Source File
+
-
-
+
PluginBufferingAdapter is a Vamp plugin adapter that allows plugins to be used by a host supplying an audio stream in non-overlapping buffers of arbitrary size
PluginChannelAdapter is a Vamp plugin adapter that implements a policy for management of plugins that expect a different number of input channels from the number actually available in the source audio data
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
@@ -792,7 +791,7 @@
A plugin may return 0 if it has no particular interest in the step size. In this case, the host should make the step size equal to the block size if the plugin is accepting input in the time domain. If the plugin is accepting input in the frequency domain, the host may use any step size. The final step size will be set in the initialise() call.
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
-Example plugin that returns a power spectrum calculated (trivially) from the frequency domain representation of each block of audio.
-
-This is one of the simplest possible Vamp plugins, included as an example of how to return the appropriate value structure for this sort of visualisation.
-
+Example plugin that returns a power spectrum calculated (trivially) from the frequency domain representation of each block of audio.
+
+This is one of the simplest possible Vamp plugins, included as an example of how to return the appropriate value structure for this sort of visualisation.
+
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
@@ -691,7 +690,7 @@
A plugin may return 0 if it has no particular interest in the step size. In this case, the host should make the step size equal to the block size if the plugin is accepting input in the time domain. If the plugin is accepting input in the frequency domain, the host may use any step size. The final step size will be set in the initialise() call.
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
@@ -610,9 +609,9 @@
Return any features that have become available after this process call. (These do not necessarily have to fall within the process block, except for OneSamplePerStep outputs.)
@@ -691,7 +690,7 @@
A plugin may return 0 if it has no particular interest in the step size. In this case, the host should make the step size equal to the block size if the plugin is accepting input in the time domain. If the plugin is accepting input in the frequency domain, the host may use any step size. The final step size will be set in the initialise() call.
Vamp::HostExt::PluginBufferingAdapter Class Reference
PluginBufferingAdapter is a Vamp plugin adapter that allows plugins to be used by a host supplying an audio stream in non-overlapping buffers of arbitrary size.
+More...
+
-PluginBufferingAdapter is a Vamp plugin adapter that allows plugins to be used by a host supplying an audio stream in non-overlapping buffers of arbitrary size.
-
-A host using PluginBufferingAdapter may ignore the preferred step and block size reported by the plugin, and still expect the plugin to run. The value of blockSize and stepSize passed to initialise should be the size of the buffer which the host will supply; the stepSize should be equal to the blockSize.
-If the internal step size used for the plugin differs from that supplied by the host, the adapter will modify the sample type and rate specifications for the plugin outputs appropriately, and set timestamps on the output features for outputs that formerly used a different sample rate specification. This is necessary in order to obtain correct time stamping.
-In other respects, the PluginBufferingAdapter behaves identically to the plugin that it wraps. The wrapped plugin will be deleted when the wrapper is deleted.
-
+PluginBufferingAdapter is a Vamp plugin adapter that allows plugins to be used by a host supplying an audio stream in non-overlapping buffers of arbitrary size.
+
+A host using PluginBufferingAdapter may ignore the preferred step and block size reported by the plugin, and still expect the plugin to run. The value of blockSize and stepSize passed to initialise should be the size of the buffer which the host will supply; the stepSize should be equal to the blockSize.
+If the internal step size used for the plugin differs from that supplied by the host, the adapter will modify the sample type and rate specifications for the plugin outputs appropriately, and set timestamps on the output features for outputs that formerly used a different sample rate specification. This is necessary in order to obtain correct time stamping.
+In other respects, the PluginBufferingAdapter behaves identically to the plugin that it wraps. The wrapped plugin will be deleted when the wrapper is deleted.
+
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
Vamp::HostExt::PluginChannelAdapter Class Reference
PluginChannelAdapter is a Vamp plugin adapter that implements a policy for management of plugins that expect a different number of input channels from the number actually available in the source audio data.
+More...
+
-PluginChannelAdapter is a Vamp plugin adapter that implements a policy for management of plugins that expect a different number of input channels from the number actually available in the source audio data.
-
-A host using PluginChannelAdapter may ignore the getMinChannelCount and getMaxChannelCount reported by the plugin, and still expect the plugin to run.
If the plugin supports the provided number of channels directly, PluginChannelAdapter will just run the plugin as normal.
-
-
-
If the plugin only supports exactly one channel but more than one channel is provided, PluginChannelAdapter will use the mean of the channels. This ensures that the resulting values remain within the same magnitude range as expected for mono data.
-
-
-
If the plugin requires more than one channel but exactly one is provided, the provided channel will be duplicated across all the plugin input channels.
-
-If none of the above apply:
-
-
If the plugin requires more channels than are provided, the minimum acceptable number of channels will be produced by adding empty (zero valued) channels to those provided.
-
-
-
If the plugin requires fewer channels than are provided, the maximum acceptable number of channels will be produced by discarding the excess channels.
-
-Hosts requiring a different channel policy from the above will need to implement it themselves, instead of using PluginChannelAdapter.
-Note that PluginChannelAdapter does not override the minimum and maximum channel counts returned by the wrapped plugin. The host will need to be aware that it is using a PluginChannelAdapter, and be prepared to ignore these counts as necessary. (This contrasts with the approach used in PluginInputDomainAdapter, which aims to make the host completely unaware of which underlying input domain is in fact in use.)
-(The rationale for this is that a host may wish to use the PluginChannelAdapter but still discriminate in some way on the basis of the number of channels actually supported. For example, a simple stereo audio host may prefer to reject plugins that require more than two channels on the grounds that doesn't actually understand what they are for, rather than allow the channel adapter to make a potentially meaningless channel conversion for them.)
-In every respect other than its management of channels, the PluginChannelAdapter behaves identically to the plugin that it wraps. The wrapped plugin will be deleted when the wrapper is deleted.
-
Note:
This class was introduced in version 1.1 of the Vamp plugin SDK.
+PluginChannelAdapter is a Vamp plugin adapter that implements a policy for management of plugins that expect a different number of input channels from the number actually available in the source audio data.
+
+A host using PluginChannelAdapter may ignore the getMinChannelCount and getMaxChannelCount reported by the plugin, and still expect the plugin to run.
If the plugin supports the provided number of channels directly, PluginChannelAdapter will just run the plugin as normal.
+
+
+
If the plugin only supports exactly one channel but more than one channel is provided, PluginChannelAdapter will use the mean of the channels. This ensures that the resulting values remain within the same magnitude range as expected for mono data.
+
+
+
If the plugin requires more than one channel but exactly one is provided, the provided channel will be duplicated across all the plugin input channels.
+
+If none of the above apply:
+
+
If the plugin requires more channels than are provided, the minimum acceptable number of channels will be produced by adding empty (zero valued) channels to those provided.
+
+
+
If the plugin requires fewer channels than are provided, the maximum acceptable number of channels will be produced by discarding the excess channels.
+
+Hosts requiring a different channel policy from the above will need to implement it themselves, instead of using PluginChannelAdapter.
+Note that PluginChannelAdapter does not override the minimum and maximum channel counts returned by the wrapped plugin. The host will need to be aware that it is using a PluginChannelAdapter, and be prepared to ignore these counts as necessary. (This contrasts with the approach used in PluginInputDomainAdapter, which aims to make the host completely unaware of which underlying input domain is in fact in use.)
+(The rationale for this is that a host may wish to use the PluginChannelAdapter but still discriminate in some way on the basis of the number of channels actually supported. For example, a simple stereo audio host may prefer to reject plugins that require more than two channels on the grounds that doesn't actually understand what they are for, rather than allow the channel adapter to make a potentially meaningless channel conversion for them.)
+In every respect other than its management of channels, the PluginChannelAdapter behaves identically to the plugin that it wraps. The wrapped plugin will be deleted when the wrapper is deleted.
+
Note:
This class was introduced in version 1.1 of the Vamp plugin SDK.
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
-PluginInputDomainAdapter is a Vamp plugin adapter that converts time-domain input into frequency-domain input for plugins that need it.
-
-This permits a host to use time- and frequency-domain plugins interchangeably without needing to handle the conversion itself.
-This adapter uses a basic Hanning windowed FFT that supports power-of-two block sizes only. If a frequency domain plugin requests a non-power-of-two blocksize, the adapter will adjust it to a nearby power of two instead. Thus, getPreferredBlockSize() will always return a power of two if the wrapped plugin is a frequency domain one. If the plugin doesn't accept the adjusted power of two block size, initialise() will fail.
-The adapter provides no way for the host to discover whether the underlying plugin is actually a time or frequency domain plugin (except that if the preferred block size is not a power of two, it must be a time domain plugin).
-The FFT implementation is simple and self-contained, but unlikely to be the fastest available: a host can usually do better if it cares enough.
-In every respect other than its input domain handling, the PluginInputDomainAdapter behaves identically to the plugin that it wraps. The wrapped plugin will be deleted when the wrapper is deleted.
-
Note:
This class was introduced in version 1.1 of the Vamp plugin SDK.
ProcessTimestampMethod determines how the PluginInputDomainAdapter handles timestamps for the data passed to the process() function of the plugin it wraps, in the case where the plugin is expecting frequency-domain data. More...
Initialise a plugin to prepare it for use with the given number of input channels, step size (window increment, in sample frames) and block size (window size, in sample frames).
Return the amount by which the timestamps supplied to process() are being incremented when they are passed to the plugin's own process() implementation.
+PluginInputDomainAdapter is a Vamp plugin adapter that converts time-domain input into frequency-domain input for plugins that need it.
+
+This permits a host to use time- and frequency-domain plugins interchangeably without needing to handle the conversion itself.
+This adapter uses a basic Hanning windowed FFT that supports power-of-two block sizes only. If a frequency domain plugin requests a non-power-of-two blocksize, the adapter will adjust it to a nearby power of two instead. Thus, getPreferredBlockSize() will always return a power of two if the wrapped plugin is a frequency domain one. If the plugin doesn't accept the adjusted power of two block size, initialise() will fail.
+The adapter provides no way for the host to discover whether the underlying plugin is actually a time or frequency domain plugin (except that if the preferred block size is not a power of two, it must be a time domain plugin).
+The FFT implementation is simple and self-contained, but unlikely to be the fastest available: a host can usually do better if it cares enough.
+In every respect other than its input domain handling, the PluginInputDomainAdapter behaves identically to the plugin that it wraps. The wrapped plugin will be deleted when the wrapper is deleted.
+
Note:
This class was introduced in version 1.1 of the Vamp plugin SDK.
+ProcessTimestampMethod determines how the PluginInputDomainAdapter handles timestamps for the data passed to the process() function of the plugin it wraps, in the case where the plugin is expecting frequency-domain data.
+
+The Vamp specification requires that the timestamp passed to the plugin for frequency-domain input should be that of the centre of the processing block, rather than the start as is the case for time-domain input.
+Since PluginInputDomainAdapter aims to be transparent in use, it needs to handle this timestamp adjustment itself. However, some control is available over the method used for adjustment, by means of the ProcessTimestampMethod setting.
+If ProcessTimestampMethod is set to ShiftTimestamp (the default), then the data passed to the wrapped plugin will be calculated from the same input data block as passed to the wrapper, but the timestamp passed to the plugin will be advanced by half of the window size.
+If ProcessTimestampMethod is set to ShiftData, then the timestamp passed to the wrapped plugin will be the same as that passed to the process call of the wrapper, but the data block used to calculate the input will be shifted back (earlier) by half of the window size, with half a block of zero padding at the start of the first process call. This has the advantage of preserving the first half block of audio without any deterioration from window shaping.
+If ProcessTimestampMethod is set to NoShift, then no adjustment will be made and the timestamps will be incorrect.
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+Retrieve the method used for timestamp adjustment in plugins taking frequency-domain input.
+
+See the ProcessTimestampMethod documentation for details.
+
+
@@ -482,36 +581,12 @@
The Vamp API mandates that the timestamp passed to the plugin for time-domain input should be the time of the first sample in the block, but the timestamp passed for frequency-domain input should be the timestamp of the centre of the block.
The PluginInputDomainAdapter adjusts its timestamps properly so that the plugin receives correct times, but in some circumstances (such as for establishing the correct timing of implicitly-timed features, i.e. features without their own timestamps) the host may need to be aware that this adjustment is taking place.
-If the plugin requires time-domain input, this function will return zero. The result of calling this function before initialise() has been called is undefined.
+If the plugin requires time-domain input or the PluginInputDomainAdapter is configured with its ProcessTimestampMethod set to ShiftData instead of ShiftTimestamp, then this function will return zero.
+The result of calling this function before initialise() has been called is undefined.
Vamp::HostExt::PluginLoader is a convenience class for discovering and loading Vamp plugins using the typical plugin-path, library naming, and categorisation conventions described in the Vamp SDK documentation.
+More...
+
-Vamp::HostExt::PluginLoader is a convenience class for discovering and loading Vamp plugins using the typical plugin-path, library naming, and categorisation conventions described in the Vamp SDK documentation.
-
-This class is intended to greatly simplify the task of becoming a Vamp plugin host for any C++ application.
-Hosts are not required by the Vamp specification to use the same plugin search path and naming conventions as implemented by this class, and are certainly not required to use this actual class. But we do strongly recommend it.
-
Note:
This class was introduced in version 1.1 of the Vamp plugin SDK.
+Vamp::HostExt::PluginLoader is a convenience class for discovering and loading Vamp plugins using the typical plugin-path, library naming, and categorisation conventions described in the Vamp SDK documentation.
+
+This class is intended to greatly simplify the task of becoming a Vamp plugin host for any C++ application.
+Hosts are not required by the Vamp specification to use the same plugin search path and naming conventions as implemented by this class, and are certainly not required to use this actual class. But we do strongly recommend it.
+
Note:
This class was introduced in version 1.1 of the Vamp plugin SDK.
Vamp::HostExt::PluginSummarisingAdapter Class Reference
PluginSummarisingAdapter is a Vamp plugin adapter that 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.
+More...
+
-PluginSummarisingAdapter is a Vamp plugin adapter that 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.
-
-To make use of PluginSummarisingAdapter, the host should configure, initialise and run the plugin through the adapter interface just as normal. Then, after the process and getRemainingFeatures methods have been properly called and processing is complete, the host may call getSummaryForOutput or getSummaryForAllOutputs to obtain summarised features: averages, maximum values, etc, depending on the SummaryType passed to the function.
-By default PluginSummarisingAdapter calculates a single summary of each output's feature across the whole duration of processed audio. A host needing summaries of sub-segments of the whole audio may call setSummarySegmentBoundaries before retrieving the summaries, providing a list of times such that one summary will be provided for each segment between two consecutive times.
-PluginSummarisingAdapter is straightforward rather than fast. It calculates all of the summary types for all outputs always, and then returns only the ones that are requested. It is designed on the basis that, for most features, summarising and storing summarised results is far cheaper than calculating the results in the first place. If this is not true for your particular feature, PluginSummarisingAdapter may not be the best approach for you.
-
Note:
This class was introduced in version 2.0 of the Vamp plugin SDK.
Initialise a plugin to prepare it for use with the given number of input channels, step size (window increment, in sample frames) and block size (window size, in sample frames).
+PluginSummarisingAdapter is a Vamp plugin adapter that 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.
+
+To make use of PluginSummarisingAdapter, the host should configure, initialise and run the plugin through the adapter interface just as normal. Then, after the process and getRemainingFeatures methods have been properly called and processing is complete, the host may call getSummaryForOutput or getSummaryForAllOutputs to obtain summarised features: averages, maximum values, etc, depending on the SummaryType passed to the function.
+By default PluginSummarisingAdapter calculates a single summary of each output's feature across the whole duration of processed audio. A host needing summaries of sub-segments of the whole audio may call setSummarySegmentBoundaries before retrieving the summaries, providing a list of times such that one summary will be provided for each segment between two consecutive times.
+PluginSummarisingAdapter is straightforward rather than fast. It calculates all of the summary types for all outputs always, and then returns only the ones that are requested. It is designed on the basis that, for most features, summarising and storing summarised results is far cheaper than calculating the results in the first place. If this is not true for your particular feature, PluginSummarisingAdapter may not be the best approach for you.
+
Note:
This class was introduced in version 2.0 of the Vamp plugin SDK.
@@ -619,31 +628,6 @@
The plugin must have been fully run (process() and getRemainingFeatures() calls all made as appropriate) before this function is called.
-
-
-
-
-
-
void Vamp::HostExt::PluginWrapper::reset
-
(
-
-
)
-
[virtual, inherited]
-
-
-
-
-
-
-Reset the plugin after use, to prepare it for another clean run.
-
-Not called for the first initialisation (i.e. initialise must also do a reset).
-
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
-PluginWrapper is a simple base class for adapter plugins.
-
-It takes a pointer to a "to be wrapped" Vamp plugin on construction, and provides implementations of all the Vamp plugin methods that simply delegate through to the wrapped plugin. A subclass can therefore override only the methods that are meaningful for the particular adapter.
-
Note:
This class was introduced in version 1.1 of the Vamp plugin SDK.
+PluginWrapper is a simple base class for adapter plugins.
+
+It takes a pointer to a "to be wrapped" Vamp plugin on construction, and provides implementations of all the Vamp plugin methods that simply delegate through to the wrapped plugin. A subclass can therefore override only the methods that are meaningful for the particular adapter.
+
Note:
This class was introduced in version 1.1 of the Vamp plugin SDK.
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
-Vamp::Plugin is a base class for plugin instance classes that provide feature extraction from audio or related data.
-
-In most cases, the input will be audio and the output will be a stream of derived data at a lower sampling resolution than the input.
-Note that this class inherits several abstract methods from PluginBase. These must be implemented by the subclass.
-PLUGIN LIFECYCLE
-Feature extraction plugins are managed differently from real-time plugins (such as VST effects). The main difference is that the parameters for a feature extraction plugin are configured before the plugin is used, and do not change during use.
-1. Host constructs the plugin, passing it the input sample rate. The plugin may do basic initialisation, but should not do anything computationally expensive at this point. You must make sure your plugin is cheap to construct, otherwise you'll seriously affect the startup performance of almost all hosts. If you have serious initialisation to do, the proper place is in initialise() (step 5).
-2. Host may query the plugin's available outputs.
-3. Host queries programs and parameter descriptors, and may set some or all of them. Parameters that are not explicitly set should take their default values as specified in the parameter descriptor. When a program is set, the parameter values may change and the host will re-query them to check.
-4. Host queries the preferred step size, block size and number of channels. These may all vary depending on the parameter values. (Note however that you cannot make the number of distinct outputs dependent on parameter values.)
-5. Plugin is properly initialised with a call to initialise. This fixes the step size, block size, and number of channels, as well as all of the parameter and program settings. If the values passed in to initialise do not match the plugin's advertised preferred values from step 4, the plugin may refuse to initialise and return false (although if possible it should accept the new values). Any computationally expensive setup code should take place here.
-6. Host finally checks the number of values, resolution, extents etc per output (which may vary depending on the number of channels, step size and block size as well as the parameter values).
-7. Host will repeatedly call the process method to pass in blocks of input data. This method may return features extracted from that data (if the plugin is causal).
-8. Host will call getRemainingFeatures exactly once, after all the input data has been processed. This may return any non-causal or leftover features.
-9. At any point after initialise was called, the host may optionally call the reset method and restart processing. (This does not mean it can change the parameters, which are fixed from initialise until destruction.)
-A plugin does not need to handle the case where setParameter or selectProgram is called after initialise has been called. It's the host's responsibility not to do that. Similarly, the plugin may safely assume that initialise is called no more than once.
-
+Vamp::Plugin is a base class for plugin instance classes that provide feature extraction from audio or related data.
+
+In most cases, the input will be audio and the output will be a stream of derived data at a lower sampling resolution than the input.
+Note that this class inherits several abstract methods from PluginBase. These must be implemented by the subclass.
+PLUGIN LIFECYCLE
+Feature extraction plugins are managed differently from real-time plugins (such as VST effects). The main difference is that the parameters for a feature extraction plugin are configured before the plugin is used, and do not change during use.
+1. Host constructs the plugin, passing it the input sample rate. The plugin may do basic initialisation, but should not do anything computationally expensive at this point. You must make sure your plugin is cheap to construct, otherwise you'll seriously affect the startup performance of almost all hosts. If you have serious initialisation to do, the proper place is in initialise() (step 5).
+2. Host may query the plugin's available outputs.
+3. Host queries programs and parameter descriptors, and may set some or all of them. Parameters that are not explicitly set should take their default values as specified in the parameter descriptor. When a program is set, the parameter values may change and the host will re-query them to check.
+4. Host queries the preferred step size, block size and number of channels. These may all vary depending on the parameter values. (Note however that you cannot make the number of distinct outputs dependent on parameter values.)
+5. Plugin is properly initialised with a call to initialise. This fixes the step size, block size, and number of channels, as well as all of the parameter and program settings. If the values passed in to initialise do not match the plugin's advertised preferred values from step 4, the plugin may refuse to initialise and return false (although if possible it should accept the new values). Any computationally expensive setup code should take place here.
+6. Host finally checks the number of values, resolution, extents etc per output (which may vary depending on the number of channels, step size and block size as well as the parameter values).
+7. Host will repeatedly call the process method to pass in blocks of input data. This method may return features extracted from that data (if the plugin is causal).
+8. Host will call getRemainingFeatures exactly once, after all the input data has been processed. This may return any non-causal or leftover features.
+9. At any point after initialise was called, the host may optionally call the reset method and restart processing. (This does not mean it can change the parameters, which are fixed from initialise until destruction.)
+A plugin does not need to handle the case where setParameter or selectProgram is called after initialise has been called. It's the host's responsibility not to do that. Similarly, the plugin may safely assume that initialise is called no more than once.
+
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
@@ -459,7 +458,7 @@
A plugin may return 0 if it has no particular interest in the step size. In this case, the host should make the step size equal to the block size if the plugin is accepting input in the time domain. If the plugin is accepting input in the frequency domain, the host may use any step size. The final step size will be set in the initialise() call.
-Almost all Vamp plugin libraries will want to make use of this. To do so, all they need to do is declare a PluginAdapter<T> for each plugin class T in their library. It's very simple, and you need to know absolutely nothing about how it works in order to use it. Just cut and paste from an existing plugin's discovery function.
+Almost all Vamp plugin libraries will want to make use of this. To do so, all they need to do is declare a PluginAdapter<T> for each plugin class T in their library. It's very simple, and you need to know absolutely nothing about how it works in order to use it. Just cut and paste from an existing plugin's discovery function.
-A base class for plugins with optional configurable parameters, programs, etc.
-
-The Vamp::Plugin is derived from this, and individual Vamp plugins should derive from that.
-This class does not provide the necessary interfaces to instantiate or run a plugin. It only specifies an interface for retrieving those controls that the host may wish to show to the user for editing. It could meaningfully be subclassed by real-time plugins or other sorts of plugin as well as Vamp plugins.
-
+A base class for plugins with optional configurable parameters, programs, etc.
+
+The Vamp::Plugin is derived from this, and individual Vamp plugins should derive from that.
+This class does not provide the necessary interfaces to instantiate or run a plugin. It only specifies an interface for retrieving those controls that the host may wish to show to the user for editing. It could meaningfully be subclassed by real-time plugins or other sorts of plugin as well as Vamp plugins.
+
PluginHostAdapter is a wrapper class that a Vamp host can use to make the C-language VampPluginDescriptor object appear as a C++ Vamp::Plugin object.
+More...
+
-PluginHostAdapter is a wrapper class that a Vamp host can use to make the C-language VampPluginDescriptor object appear as a C++ Vamp::Plugin object.
-
-The Vamp API is defined in vamp/vamp.h as a C API. The C++ objects used for convenience by plugins and hosts actually communicate using the C low-level API, but the details of this communication are handled seamlessly by the Vamp SDK implementation provided the plugin and host use the proper C++ wrapper objects.
-See also PluginAdapter, the plugin-side wrapper that makes a C++ plugin object available using the C query API.
-
+PluginHostAdapter is a wrapper class that a Vamp host can use to make the C-language VampPluginDescriptor object appear as a C++ Vamp::Plugin object.
+
+The Vamp API is defined in vamp/vamp.h as a C API. The C++ objects used for convenience by plugins and hosts actually communicate using the C low-level API, but the details of this communication are handled seamlessly by the Vamp SDK implementation provided the plugin and host use the proper C++ wrapper objects.
+See also PluginAdapter, the plugin-side wrapper that makes a C++ plugin object available using the C query API.
+
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
-If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin. If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
+If this is TimeDomain, the samples provided to the process() function (below) will be in the time domain, as for a traditional audio processing plugin.
+If this is FrequencyDomain, the host will carry out a windowed FFT of size equal to the negotiated block size on the data before passing the frequency bin data in to process(). The input data for the FFT will be rotated so as to place the origin in the centre of the block. The plugin does not get to choose the window type -- the host will either let the user do so, or will use a Hanning window.
@@ -693,7 +692,7 @@
A plugin may return 0 if it has no particular interest in the step size. In this case, the host should make the step size equal to the block size if the plugin is accepting input in the time domain. If the plugin is accepting input in the frequency domain, the host may use any step size. The final step size will be set in the initialise() call.
@@ -52,7 +52,7 @@
private:
Used *m_usedClass;
};
-
If the MAX_DOT_GRAPH_HEIGHT tag in the configuration file is set to 240 this will result in the following graph:
+
This will result in the following graph:
@@ -80,8 +80,8 @@
A yellow dashed arrow denotes a relation between a template instance and the template class it was instantiated from. The arrow is labeled with the template parameters of the instance.
-Generated on Mon Dec 8 14:37:22 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:14 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/graph_legend.png
Binary file code-doc/graph_legend.png has changed
diff -r 4b4db9230e94 -r 0976232e353b code-doc/hierarchy.html
--- a/code-doc/hierarchy.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/hierarchy.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: Hierarchical Index
+
-
-
+
Vamp is an API for C and C++ plugins that process sampled audio data to produce descriptive output (measurements or semantic observations). Find more information at http://www.vamp-plugins.org/ .
Although the official API for Vamp plugins is defined in C for maximum binary compatibility, we strongly recommend using the provided C++ classes in the SDK to implement your own plugins and hosts.
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.
-
Generated on Mon Dec 8 14:37:18 2008 for VampPluginSDK by
+Generated on Thu Sep 24 13:40:13 2009 for VampPluginSDK by
- 1.5.6
+ 1.5.8
diff -r 4b4db9230e94 -r 0976232e353b code-doc/namespaceVamp.html
--- a/code-doc/namespaceVamp.html Wed Sep 23 15:09:53 2009 +0000
+++ b/code-doc/namespaceVamp.html Fri Sep 25 15:40:18 2009 +0000
@@ -1,10 +1,10 @@
VampPluginSDK: Vamp Namespace Reference
+
-
-
+
@@ -236,16 +236,16 @@
The plugin should ensure that parameters have this value on initialisation (i.e. the host is not required to explicitly set parameters if it wants to use their default values).
@@ -262,18 +262,18 @@
The number of values per result of the output.
Undefined if hasFixedBinCount is false. If this is zero, the output is point data (i.e. only the time of each output is of interest, the value list will be empty).
-
If sampleType is VariableSampleRate and this value is non-zero, then it may be used to calculate a resolution for the output (i.e. the "duration" of each sample, in time, will be 1/sampleRate seconds). It's recommended to set this to zero if that behaviour is not desired.
-
-This is the formal plugin API for Vamp. Plugin authors may prefer to use the C++ classes provided in the Vamp plugin SDK, instead of using this API directly. There is an adapter class provided that makes C++ plugins available using this C API with relatively little work, and the C++ headers are more thoroughly documented.
-IMPORTANT: The comments in this file summarise the purpose of each of the declared fields and functions, but do not provide a complete guide to their permitted values and expected usage. Please refer to the C++ headers in the Vamp plugin SDK for further details and plugin lifecycle documentation.
-
+This is the formal plugin API for Vamp. Plugin authors may prefer to use the C++ classes provided in the Vamp plugin SDK, instead of using this API directly. There is an adapter class provided that makes C++ plugins available using this C API with relatively little work, and the C++ headers are more thoroughly documented.
+IMPORTANT: The comments in this file summarise the purpose of each of the declared fields and functions, but do not provide a complete guide to their permitted values and expected usage. Please refer to the C++ headers in the Vamp plugin SDK for further details and plugin lifecycle documentation.
+
Download the Vamp plugin tester (new! version 1.0), a simple
command-line utility that tests your plugins for various common
failure cases. It can't check whether you're getting the right
results, but it can help you write better behaved and more
- resilient plugins. Get the source
- code, OS/X
- universal binary, or Windows
- binary of the initial version 0.1 release.
Queen Mary plugin set (docs) Note onset detector, beat and barline tracker, tempo estimator, key estimator, tonal change detector, structural segmenter, timbral and rhythmic similarity estimator, wavelet scaleogram, adaptive spectrogram, note transcription, chromagram, constant Q spectrogram and MFCC calculation plugins from the Centre for Digital Music at Queen Mary, University of London