comparison src/vamp-hostsdk/PluginSummarisingAdapter.cpp @ 248:c88a3cdb0215

* Tidy up --list-full output a bit * Some documentation, including docs for PluginSummarisingAdapter
author cannam
date Tue, 11 Nov 2008 12:07:09 +0000
parents 521734d2b498
children 4454843ff384
comparison
equal deleted inserted replaced
246:5bfed156b45d 248:c88a3cdb0215
428 PluginSummarisingAdapter::Impl::accumulate(int output, 428 PluginSummarisingAdapter::Impl::accumulate(int output,
429 const Feature &f, 429 const Feature &f,
430 RealTime timestamp, 430 RealTime timestamp,
431 bool final) 431 bool final)
432 { 432 {
433 //!!! to do: use timestamp to determine which segment we're on 433 // What should happen if a feature's duration spans a segment
434 434 // boundary? I think we probably want to chop it, and pretend
435 //!!! What should happen if a feature's duration spans a segment 435 // that it appears in both. A very long feature (e.g. key, if the
436 // boundary? I think we probably want to chop it, and pretend that it 436 // whole audio is in a single key) might span many or all
437 // appears in both -- don't we? do we? A very long feature (e.g. key, 437 // segments, and we want that to be reflected in the results
438 // if the whole audio is in a single key) might span many or all 438 // (e.g. it is the modal key in all of those segments, not just
439 // segments, and we want that to be reflected in the results (e.g. it 439 // the first). This is actually quite complicated to do.
440 // is the modal key in all of those segments, not just the first). 440
441 // That is actually quite complicated to do! 441 // If features spanning a boundary should be chopped, then we need
442 442 // to have per-segment accumulators (and the feature value goes
443 //!!! This affects how we record things. If features spanning a 443 // into both -- with a separate phase to split the accumulator up
444 // boundary should be chopped, then we need to have per-segment 444 // into segments).
445 // accumulators (and the feature value goes into both -- perhaps we
446 // need a separate phase to split the accumulator up into segments).
447 // If features spanning a boundary should be counted only in the first
448 // segment, with their full duration, then we should store them in a
449 // single accumulator and distribute into segments only on reduce.
450 445
451 #ifdef DEBUG_PLUGIN_SUMMARISING_ADAPTER 446 #ifdef DEBUG_PLUGIN_SUMMARISING_ADAPTER
452 std::cerr << "output " << output << ": timestamp " << timestamp << ", prev timestamp " << m_prevTimestamps[output] << ", final " << final << std::endl; 447 std::cerr << "output " << output << ": timestamp " << timestamp << ", prev timestamp " << m_prevTimestamps[output] << ", final " << final << std::endl;
453 #endif 448 #endif
454 449
625 #ifdef DEBUG_PLUGIN_SUMMARISING_ADAPTER_SEGMENT 620 #ifdef DEBUG_PLUGIN_SUMMARISING_ADAPTER_SEGMENT
626 std::cerr << "segment: total results for output " << output << " = " 621 std::cerr << "segment: total results for output " << output << " = "
627 << source.results.size() << std::endl; 622 << source.results.size() << std::endl;
628 #endif 623 #endif
629 624
630 //!!! This is basically nonsense if the results have no values 625 // This is basically nonsense if the results have no values
631 //!!! (i.e. their times and counts are the only things of 626 // (i.e. their times and counts are the only things of
632 //!!! interest) but perhaps it's the user's problem if they 627 // interest)... but perhaps it's the user's problem if they
633 //!!! ask for segmentation in that case 628 // ask for segmentation (or any summary at all) in that case
634 629
635 for (int n = 0; n < source.results.size(); ++n) { 630 for (int n = 0; n < source.results.size(); ++n) {
636 631
637 // This result spans source.results[n].time to 632 // This result spans source.results[n].time to
638 // source.results[n].time + source.results[n].duration. 633 // source.results[n].time + source.results[n].duration.