(fix) Waveform scratch crossing loop boundaries #13007
Conversation
ronso0
changed the title
ronso0
force-pushed
the
waveform-scratch-loop-fix
branch
from
d4a0daa
to
97b1c4a
Compare
|
This is now cleaned up. |
src/engine/controls/ratecontrol.cpp
Outdated
| // TODO FramePos only for easy validation. | ||
| // Check how to get kLegacyInvalidEnginePosition in order to use sample pos | ||
| // for the entire |
There was a problem hiding this comment.
Why do you want to switch from frame position to sample position?
There was a problem hiding this comment.
it's passed only to PositionScratchController and uses only sample positions for processing anyway, so I thought we'd better convert it early. No issue though, and getting kLegacyInvalidEnginePosition here requires more includes, so I can as well remove the TODO.
|
I remember mentioning this in an issue or zulip post sometime ago, but I can't find it anymore |
|
yeah, we touched this topic sometime, but I can't find it anymore either. |
An important test case, which failed with my previous attempts, is a fast throwback with a very short loop (< 1 beat), then hold the mouse button until scratching (inertia) stopped. This should perform exactly like a throwback with no loop. |
I tested this, and it worked correct! |
|
Great. So I remove the TODO and this is ready? |
PositionScratchController::process() now knows if the play position was wrapped around (and how often) since the last processing. This avoids an infinite wrap-around 'loop', even after the mouse didn't move. Previously, PositionScratchController didn't know if the play position was wrapped around, so it interpreted the raw (huge) sample delta as play pos move and calculated a huge rate, which was then applied by the engine, resulting in a (now true) long sample distance in the next run, which caused another loop wrap-around, and so on...
ronso0
force-pushed
the
waveform-scratch-loop-fix
branch
from
97b1c4a
to
50e16c9
Compare
|
Done. |
|
LGTM! Thank you! |
Previously, scratching with the waveform and crossing loop boundaries at slow rates caused an infinite wrap-around 'loop' even after the mouse was stopped (while still pressed).
Probably affects Spinny scratching, too, but I didn't test it.
PositionScratchController::process() now knows if the play position was wrapped around and calculates the true sample distance travelled.
I notice this would also be helpful for and probably simplify #12951 hotcue_X_indicator control
TL;DR
PositionScratchController didn't know the play position was wrapped around, so it
interpreted the raw (huge) sample delta as play pos move and calculated a huge rate, which was
then applied by the engine, resulting in a (true) long sample distance in the next run,
which caused another loop wrap-around, and so on...