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