Mercurial > hg > vamp-plugin-sdk
comparison vestigial-manual/bullets.html @ 119:e9b5fb4a6ea3
...
| author | cannam |
|---|---|
| date | Sun, 24 Feb 2008 17:20:30 +0000 |
| parents | d5d7bbb2faf9 |
| children |
comparison
equal
deleted
inserted
replaced
| 118:d5d7bbb2faf9 | 119:e9b5fb4a6ea3 |
|---|---|
| 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> | 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 | 46 |
| 47 | 47 |
| 48 Notes about Vamp itself | 48 Notes about Vamp itself |
| 49 | 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* | 50 <ul><li dir="ltr">It's not a sophisticated invention. It's just 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 | 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 dir="ltr">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 | |
| 52 </li><li style="list-style-type: none" dir="ltr"></li></ul></div></body></html> | 53 </li><li style="list-style-type: none" dir="ltr"></li></ul></div></body></html> |
