Before, I assumed that only mid-measure BPMCHANGE commands would split the measure in two. However, mid-measure SCROLL/GOGO commands *also* split the measure in two.
For non-branching songs, `-1` == `idx_m-1`. But, for branching songs, we will repeatedly visit the same measures to populate the different branches. This means that the relative index `-1` is no longer valid.
This bug wasn't caught because `measureDurationPrev` generally equals `measureDuration` for the first two measures.
However, if there is a BPM change within the first 3 measures, then the wrong `measureDuration` will be used. So, we need to explicitly specify `measureDurationPrev`
This reverts commit af91e9fe47.
I was mistaken. Importing from src is _not_ necessary to perform PyCharm coverage tests. Instead, the package must be installed in editable mode.
The official fumen had some issues where a note ended up in the wrong measure:
- Expected: pos 0.0 on the next measure
- Actual: pos 645 on the prev measure (impossible pos)
They're the same pos, but only pos 0.0 is possible to express in TJA charts, so the fumens themselves had to be updated.
Also, the TJA chart had errors, too:
- The BPMs/SCROLLs in the BPMCHANGE section were incorrect
- Some drumrolls were too short
Fixing these errors caused the failing test to pass.
Instead, we should only update the values once we encounter more notes.
This prevents an issue where a command is used before a BPMCHANGE event:
# 33
# #GOGOEND
# #BPMCHANGE 107
# 33,
If GOGOEND is applied right away, then the first '33' notes will be affected. But, we only want the last '33' notes to be affected.
This will _actually_ perform an in-place test run, rather than importing from the installed package. This is necessary for PyCharm's coverage to ework correctly.
This was initially used to validate the fumen writer to make sure it properly recreated the data from the fumen parser.
Any further byte-comparison will be done in a semantic way through pytest tests.
