Mercurial > hg > vamp-plugin-sdk
comparison vestigial-manual/bullets.html @ 118:d5d7bbb2faf9
...
| author | cannam |
|---|---|
| date | Sun, 24 Feb 2008 16:11:36 +0000 |
| parents | |
| children | e9b5fb4a6ea3 |
comparison
equal
deleted
inserted
replaced
| 117:3b4ff9dc74a8 | 118:d5d7bbb2faf9 |
|---|---|
| 1 <html xmlns:tomboy="http://beatniksoftware.com/tomboy" xmlns:link="http://beatniksoftware.com/tomboy/link" xmlns:size="http://beatniksoftware.com/tomboy/size"><head><META http-equiv="Content-Type" content="text/html; charset=utf-8"><title>Salient points of Vamp document</title><style type="text/css"> | |
| 2 | |
| 3 body { } | |
| 4 h1 { font-size: xx-large; | |
| 5 font-weight: bold; | |
| 6 border-bottom: 1px solid black; } | |
| 7 div.note { overflow: auto; | |
| 8 position: relative; | |
| 9 display: block; | |
| 10 padding: 5pt; | |
| 11 margin: 5pt; | |
| 12 white-space: -moz-pre-wrap; /* Mozilla */ | |
| 13 white-space: -pre-wrap; /* Opera 4 - 6 */ | |
| 14 white-space: -o-pre-wrap; /* Opera 7 */ | |
| 15 white-space: pre-wrap; /* CSS3 */ | |
| 16 word-wrap: break-word; /* IE 5.5+ */ } | |
| 17 </style></head><body><div class="note" id="Salient points of Vamp document" style="width:293;"><a name="#Salient points of Vamp document"></a><h1>Salient points of Vamp document</h1> | |
| 18 <ul><li dir="ltr">Vamp plugin is compiled code delivered in shared library file | |
| 19 </li><li dir="ltr">in C or C++ | |
| 20 </li><li dir="ltr">Needs to be recompiled for each platform | |
| 21 </li><li dir="ltr">Requires a host to be of any use | |
| 22 </li><li dir="ltr">advantages over e.g. matlab: applicable to any host, can be faster, doesn't require supporting framework from commercial application | |
| 23 </li><li dir="ltr">Vamp not an acronym | |
| 24 </li><li dir="ltr">Examples: note onset detector, chromagram, amplitude tracker | |
| 25 </li><li dir="ltr">Plugins don't display, just compute | |
| 26 </li><li dir="ltr">Things a plugin always has: - basic descriptive data [ identifier, name, description, maker ] - processing prefs [ input domain, step block size, channels ] - output descriptors | |
| 27 </li><li dir="ltr">may have - parameter descriptors, programs | |
| 28 </li><li dir="ltr">Vamp plugin inherits Vamp::Plugin which inherits Vamp::PluginBase | |
| 29 </li><li dir="ltr">category not specified by the plugin, but through external metadata files (in a trivial text format) | |
| 30 </li><li dir="ltr">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 | |
| 31 </li><li dir="ltr">Input to process() is quite different depending on whether plugin requests time domain or frequency domain input | |
| 32 </li><li dir="ltr">Plugin can have more than one named output; it calculates features for all of them at once | |
| 33 </li><li dir="ltr">Each call to process() returns zero or more features for each output | |
| 34 </li><li dir="ltr">Each feature has a time, and zero or more values | |
| 35 </li><li dir="ltr">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 | |
| 36 </li><li dir="ltr">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</li></ul> | |
| 37 | |
| 38 | |
| 39 | |
| 40 | |
| 41 | |
| 42 Omissions and future work | |
| 43 | |
| 44 <ul><li dir="ltr">Features do not have duration | |
| 45 </li><li dir="ltr">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 (??)</li></ul> | |
| 46 | |
| 47 | |
| 48 Notes about Vamp itself | |
| 49 | |
| 50 <ul><li dir="ltr">It's not a sophisticated invention. It's complicated by the fact that in theory the plugin should be able to return *anything* | |
| 51 </li><li dir="ltr">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 | |
| 52 </li><li style="list-style-type: none" dir="ltr"></li></ul></div></body></html> |