# Salient points of Vamp document

- Vamp plugin is compiled code delivered in shared library file
- in C or C++
- Needs to be recompiled for each platform
- Requires a host to be of any use
- advantages over e.g. matlab: applicable to any host, can be faster, doesn't require supporting framework from commercial application
- Vamp not an acronym
- Examples: note onset detector, chromagram, amplitude tracker
- Plugins don't display, just compute
- Things a plugin always has: - basic descriptive data [ identifier, name, description, maker ] - processing prefs [ input domain, step block size, channels ] - output descriptors
- may have - parameter descriptors, programs
- Vamp plugin inherits Vamp::Plugin which inherits Vamp::PluginBase
- category not specified by the plugin, but through external metadata files (in a trivial text format)
- Plugin receives non-interleaves audio data as input to process(), returns structured set of feature data representing all features that have been calculated from that audio input
- Input to process() is quite different depending on whether plugin requests time domain or frequency domain input
- Plugin can have more than one named output; it calculates features for all of them at once
- Each call to process() returns zero or more features for each output
- Each feature has a time, and zero or more values
- Any "meaning" of the values (ranges, units etc) is defined by the Output Descriptor associated with the output on which the feature is returned -> potential for more semantics to be added via RDF later
- Time of a feature is either explicit (timestamped in feature) or implicit (based on "time of the process call"), and this depends on the output's sample type

Omissions and future work

- Features do not have duration
- Features can only have a single unit for all bins in the feature. So feature is an "array of values" rather than a point in a multi-dimensional space (??)

Notes about Vamp itself

- It's not a sophisticated invention. It's just complicated by the fact that in theory the plugin should be able to return *anything*
- There is a need to compromise between having one arbitrarily complex return structure with no "meaning", and a set of specific return structures with precisely defined meaning but no way to return anything else. -> classic data representation problem
- A lot about the plugin design is based on existing real-time effects plugin APIs which audio programmers may be familiar with -- rather than on plugins for existing analysis systems or the like