Bug #311
ordering of Vamp (summary) outputs
Status: | Resolved | Start date: | 2011-09-21 | ||
---|---|---|---|---|---|
Priority: | Normal | Due date: | |||
Assignee: | Matthias Mauch | % Done: | 80% | ||
Category: | - | Estimated time: | 1.00 hour | ||
Target version: | - |
Description
At last.fm we are using csv output of Vamp summaries. When transforms are defined via n3 files, sonic annotator usually reads them in the order they appear in the RDF file (which is not guaranteed in the first place, I imagine). However, this is not the main problem.
The main problem arises in FeatureExtractionManager.cpp, when the desired outputs are checked for being extracted by the same (and equally parameterized) plugin, and subsequently stored in the map m_plugins: the key in that map are pointers to plugin, and hence have no particular order. Since during output sonic annotator loops over this map, a human-readable plugin order is not guaranteed (sorted by pointer), and in practice it happens that sometimes the outputs of a plugin appear in a different place in the csv-stdout output.
This can be avoided, since the transforms do have a unique order which is "inherited" by the plugins. The plugins can actually be ordered by their first output (or indeed any one of their outputs), and I used this to re-order them prior to the actual output loop. Changes start at line 770 in the attached file.
This solves the problem for me. I admit that this is quite a special problem, but it seems the ordered version is the more elegant solution. Elegant is not how I did it though, so if someone with a better sense of what things should look like in Sonic Annotator could make it more elegant, that would be super!
History
#1 Updated by Chris Cannam almost 13 years ago
- Assignee set to Matthias Mauch
Sorry to take so long and so much prompting to get to this.
The general approach looks sensible enough. One question: at line 390 you introduced the line:
std::sort(transforms.begin(), transforms.end()); // sort for predictable output - though this may actually not help
My impression is that your comment is right -- this won't actually make any difference (the bigger change further down is the one that looks like it should actually work). Can you confirm or deny this?
Chris
#2 Updated by Chris Cannam almost 13 years ago
Slightly modified version of your patch applied at 513230b19248 and 350f61d5d9be. I'm working on the assumption that the sort invocation earlier in the file is not in fact necessary...
#3 Updated by Matthias Mauch almost 13 years ago
Sorry for not spotting this earlier. I should setup some sort of email reminder for my watched SoundSoftware posts.
My impression is that your comment is right -- this won't actually make any difference (the bigger change further down is the one that looks like it should actually work). Can you confirm or deny this?
Yes, that's right, I must have inadvertently left that change in, the real change is where I put my longer comment.
Thanks!
Matthias
#4 Updated by Chris Cannam over 12 years ago
- Status changed from New to Resolved
Should be fixed in v0.7