The principal technical differences between Vamp and a real-time audio
cannam@0: plugin system such as VST are:
cannam@0:
cannam@0:
cannam@0:
cannam@0:
Vamp plugins may output complex multidimensional data with
cannam@0: labels. As a consequence, they are likely to work best when the
cannam@0: output data has a much lower sampling rate than the input.
cannam@0:
cannam@0:
While Vamp plugins receive their data block-by-block, they
cannam@0: are not required to return output immediately on receiving the
cannam@0: input. A Vamp plugin may be non-causal, preferring to store up
cannam@0: data based on its input until the end of a processing run and
cannam@0: then return all results at once.
cannam@0:
cannam@0:
Vamp plugins have more control over their inputs than a
cannam@0: typical real-time processing plugin. For example, they can
cannam@0: indicate to the host their preferred processing block and step
cannam@0: sizes, and these do not have to be equal.
cannam@0:
cannam@0:
Vamp plugins may ask to receive data in the frequency domain
cannam@0: instead of the time domain. The host takes the responsibility
cannam@0: for converting the input data using an FFT of windowed frames.
cannam@0: This simplifies plugins that do straightforward frequency-domain
cannam@0: processing and permits the host to cache frequency-domain data
cannam@0: when possible.
cannam@0:
cannam@0:
A Vamp plugin is configured once before each processing run,
cannam@0: and receives no further parameter changes during use –
cannam@0: unlike real time plugin APIs in which the input parameters may
cannam@0: change at any time. This means that fundamental properties such
cannam@0: as the number of values per output or the preferred processing
cannam@0: block size may depend on the input parameters. Many Vamp
cannam@0: plugins would be unable to work without this guarantee.
cannam@0:
cannam@0:
Vamp plugins do not have to be able to run in real time.