A custom divisor like 24 or 32 will result in a range containing
many divisors that are already in the `Common` and `Triplets` presets.
When this happens, it can become impossible to cycle between presets,
because the preset can only be changed if the new divisor isn't already
contained within the current preset's range.
I don't know what this test was trying to do, but it was wrong. Any
offset which is applied should be invisible to the clock's final
`CurrentTime` (and to the user).
Came up as a failure when locally running tests for
ppy/osu-framework#6001 - but the test is actually a previously-known
flaky that I couldn't reproduce the failure of until the aforementioned
PR.
This appears to be a simple race; the test scene queries the track
length from update thread, but the length is actually set on the audio
thread. So it's not unreasonable that given unlucky timing, the length
will not be set by `TrackBass` before it is queried.
To fix, switch assert to until step. I'm generally not really willing
to give this more time of day until this change is proven insufficient.
As it turns out, the tightening of hitcircle lifetimes in editor caused
the test to fail, since the objects were too far apart and at the
starting time of the test, the first object was fully faded out and as
such not alive, therefore leading cyclic selection to fail to select it.
To fix, bring all three objects closer together time-wise so that this
does not happen and the test can continue to exercise its original
behaviour.