What would you like to see happen next with the Vamp plugin interface?
At the moment we're concentrating on a few enhancements that can be made while retaining binary compatibility and stability in the interface. There will be a Vamp SDK version 1.1 release very shortly, which will add several new classes for hosts to handle plugin lookup and other utility tasks; these will retain binary compatibility and won't affect plugins at all.
However, we'd also like to find out what sort of interest there may be in non-binary compatible additions that may warrant a version 2.0 of the API at some point in future.
Some additions that have been suggested include:
- Give features an optional duration as well as a starting timestamp. At the moment, plugins such as note trackers that return features with duration generally do so by treating (for example) frequency and duration as two separate values in a feature structure's value vector. This is problematic, partly because there is no way to supply separate units for the separate values in the vector (see next point).
- Provide a way to supply separate units for the separate values in a feature's value vector.
- Allow a plugin to declare that a particular output is causal, i.e. that all of the results from that output are returned from process() and (explicitly or implicitly) timestamped within the current process block, instead of being returned in a later block or from getRemainingFeatures. There are various classes of host that could make use of this information, for example if the plugin is providing auxiliary data to be used in a further ongoing calculation.
- Make it possible to group plugin parameters in some way (for example, include "normal user" and "advanced" parameters).
Any other ideas? What problems have you faced with the current API that you may or may not have an idea how to solve? Would you make use of any of the suggestions above?
Chris
