-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Brake: fix infinite run out #4705
Conversation
Draft until I can confirm it's fixed with some 'real life' tests with my controller. |
c920555
to
0932604
Compare
@@ -16,6 +16,8 @@ constexpr int kDecks = 16; | |||
// timer. | |||
constexpr int kScratchTimerMs = 1; | |||
const double kAlphaBetaDt = kScratchTimerMs / 1000.0; | |||
// stop ramping at a rate which doesn't produce any audible output anymore | |||
const double kBrakeRampToRate = 0.01; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const double kBrakeRampToRate = 0.01; | |
constexpr double kBrakeRampToRate = 0.01; |
Thank you for investigating. |
I don't mind if the refactring has to wait. Also, the code hasn't changed since 2.3 AFAICT so I'll rebase this onto 2.3 |
Uff, we didn't test spinback after my most recent brake fixes #1085
I'll prepare a fix for both issues. |
Superseded by #4708 (2.3) |
Multiple times I experienced that
engine.brake()
would slow down the deck until the waveforms halted butplay
was never disabled.I suspected a broken controller button (faulty debounce filter) to initiate
brake
again, but I could also reproduce it with a MIDI Through script a few times.There is at least one possibility that the
rampTo
rate was crossed butscratchProcess
didn't stop, thus slowing down to zero and accelerating again very, very slowly:I fixed that
That and some more simplification and I couldn't reproduce the bug anymore 🤷♂️