-
-
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
Changing the tempo of two master synced tracks causes drifting #10024
Comments
Commented by: ywwg We do already have a test for ZeroLatencyRateChange but it looks like it's not good enough. checking this out. |
Commented by: ywwg I am unable to reproduce this bug. I created more tests with more iterations and with quantize on, off, and mixed, and the rate changes are all perfect. Were these beatmap tracks? https://github.com/mixxxdj/mixxx/compare/master...ywwg:more-rate-change-tests?expand=1 |
Commented by: Swiftb0y Not sure what you define as beatmap tracks but they were analyzed with "assume constant tempo" enabled. |
Commented by: ywwg "assume constant tempo": beatgrid So yeah, I am unable to reproduce this issue as you describe. Can you upload a video of it happening? |
Commented by: Swiftb0y I'm attaching a quick video demonstrating the issue. I used my controller to move the rateslider but exactly the same occurs when I use the GUI sliders. Keep in mind when reproducing, this only happens when one deck has quantize active, while the other does not. |
Commented by: ywwg The tracks weirdly don't look like they are in sync in the first place, which is strange. Do they stay aligned when you don't adjust the sliders? (I did add tests and do experiments for the exact situation you describe and wasn't able to reproduce the issue) |
Commented by: Swiftb0y Yes they do. They just don't look aligned in the first couple of frames because they don't start quantized which is why reenabled sync at 06s. Unfortunately, recording with OBS also introduced more jitter into the waveforms which is why they look less aligned, but you can see them drifting apart the moment I move the rate slider harshly. I can try to run the tests on my machine and see whether they fail. |
Commented by: ywwg Are you moving the slider on the deck that has quantize on, or not? What are the natural bpms of the tracks? |
Commented by: Swiftb0y The deck doesn't seem to make a difference. The BPM also doesn't make a difference, its even reproducable with two tracks that have exactly the same BPM. however, what does seem to make a difference is whether keylock activated, its still noticeable without keylock, but the effect is magnitudes greater when it is active. |
Commented by: ywwg go to internalclock.cpp and comment out the lines:
does that fix it? |
Commented by: ywwg (yes, that fixed it) |
Issue closed with status Fix Released. |
Reported by: Swiftb0y
Date: 2020-06-19T21:06:23Z
Status: Fix Released
Importance: Medium
Launchpad Issue: lp1884324
Attachments: [video capture showing the bug.](https://bugs.launchpad.net/bugs/1884324/+attachment/5390813/+files/video capture showing the bug.)
When two tracks are playing side-by-side with both decks having master sync active, changes in tempo fader positions lag behind on the follower deck. This causes both decks to drift apart. This only happens when the quantize setting on the decks differ from each other. When the tempo fader of a quantized deck is moved, all other quantized decks don't exhibit this behavior and vice versa.
Has been tested on Linux 2.3.0-beta (build HEAD r7454) (git 2.3 branch).
The text was updated successfully, but these errors were encountered: