Before:
- If there was a #BPMCHANGE, tana's adjustment would be applied to _the current measure's duration_. This would result in very strange looking, impossible durations (e.g. negative)
- Additionally, this method required us to look ahead to the _next_ measure to determine the adjustment.
- Finally, it required us to keep track of two different durations: measureDurationBase (unadjusted) and measureDuration (adjusted)
After:
- Instead, we now leave the measureDuration as purely as "unadjusted".
- Then, we apply the "BPMCHANGE adjustment" _only_ when computing the fumenOffset start of the next measure.
- This requires us to keep track of both the start *and* end fumenOffset (where end = start + duration)
- However, this greatly simplifies and clarifies the code, since we:
- No longer need to "look ahead" to the next measure to compute the offset adjustment.
- No longer need to keep track of two different measureDurations (adjusted/unadjusted)
- Only need to work with a single pair of measures at a time (measureFumen, measureFumenPrev)
- The measure duration (and fumenOffsetEnd) times are now more comprehensible, since any negative offsets are only applied to the fumenOffsetStart value of the next measure.
After:
- Before: 'OFFSET' = 2nd measure fumenOffset
- After: ('OFFSET'-Full measure duration) = 1st measure fumenOffset
Both methods will produce the same results if no #MEASURE/#BPMCHANGE
commands are present in the first two measures. However, if these
commands ARE present, then you will get wildly different results.
This change doesn't affect 4/6 tests, but for 2/6 tests there were
#MEASURE/#BPMCHANGE commands. For these songs, I had erroneously "fixed"
the OFFSET values, when they were correct all along. So, I reverted them
back to their original values.
Fixes#25.
This PR adds support for multiplayer charts, and adds a new multiplayer
TJA/fumen combo for testing.
This PR is quite small, because the only work that needed to be done is
parsing the course metadata. Once the TJA lines are split into courses,
the actual course-by-course parsing logic is identical to the songs that
came before.
Fixes#6.
This PR adds the remaining changes needed to support branching TJA
songs.
- Properly handling `r` (drumroll) based branching conditions
- Handling commands that come after a measure end but _before_ the first
`#BRANCHSTART` command. (This was not previously covered by
`hol6po.tja`.)
As well, it adds a bit of cleanup/refactoring to the changes from the
previous branch PR (#20).
To test these changes, another new branching TJA-fumen pair is added to
the test suite.
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.
