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.
To compute the first measure's offset, I currently subtract the first measure's duration from the TJA's OFFSET value.
However, I realized that you actually have to subtract the *second* measure's duration from the TJA offset value. (For 99% of songs, the first two measures will have the same duration, so that's why the bug slipped by.)
Fixes#4.
Commit 1953ffbc23fcbfb80193c573ff4d6c28ab127144 fixes one issue but introduced another:
- Subtracting the drumrolls original position only makes sense if the drumroll starts and ends in the same measure.
- If the drumroll spans multiple measures, though, then the original position is irrelevant, since we want to add the duration from the start of the next measure (i.e. pos=0).
So, this commit makes sure to only subtract the position if the drumroll isn't a multi-measure drumroll.
((NB: This could probably be handled without using a new 'multimeasure' key, but I'm going to wait until the class refactor to tackle this.))
Fixes#16.
The duration calculation wasn't taking into account the starting position of the drumroll, so the drumrolls ended up with a duration that was way too long.
Fixes#1.
