musicxml-grooves misses triplets

[infojunkie]

Attached is the latest musicxml-grooves.log

One class of issue remains, and it's a biggie. The sequence:

[DRUM-SNAREDRUM1:1] Remaining gap of 1 left before note at 3.
[DRUM-SNAREDRUM1:1] Remaining gap of 1 left before note at 3.3333333333333335.
[DRUM-SNAREDRUM1:1] Remaining gap of 1 left before note at 3.6666666666666665.

indicates that the quantization algorithm eagerly converts the first note to a binary-timed note instead of a ternary-timed one, and thus misses the subsequent tuplet altogether. The outcome is something like:

where the 2nd measure is a nonsensical assembly of fractional binary-time notes instead of the original intent of a triplet. The first measure was converted correctly because the first note happened to be have onset/duration attributes that drove the quantizer to recognize it as a ternary-timed note.

[infojunkie]

There was a bug in the triplet detection code that targeted the wrong duration. This has been fixed, but more cases remain as per the latest log.

[infojunkie]

The latest log dropped in size by ~30% which indicates a good progress in handling timing cases.

Still, I am now thinking that my current timing detection algorithm needs a global redesign. The current algorithm's main limitation is that it proceeds linearly and chronologically, examining each note in the measure in turn. This leads to many cases where consecutive note onsets are not compatible in terms of non-binary timings - hence the many log entries where gaps are left between notes - gaps that are smaller than the smallest note unit.

A different approach for timing detection would proceed in a tree fashion, attempting to place the notes on a 2, 3, 5, etc. grid at the level of the measure, then recursively subdividing into one of these primes as needed. This would ensure that no incompatible note onsets are generated.

[infojunkie]

Related: Modeling and Learning Rhythm Structure