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
-