Skip to content
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

Closed
mixxxbot opened this issue Aug 23, 2022 · 13 comments
Closed

Changing the tempo of two master synced tracks causes drifting #10024

mixxxbot opened this issue Aug 23, 2022 · 13 comments
Labels
Milestone

Comments

@mixxxbot
Copy link
Collaborator

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).

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2020-06-28T16:28:46Z


We do already have a test for ZeroLatencyRateChange but it looks like it's not good enough. checking this out.

@mixxxbot mixxxbot added the bug label Aug 23, 2022
@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2020-06-28T16:46:49Z


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

@mixxxbot
Copy link
Collaborator Author

Commented by: Swiftb0y
Date: 2020-07-07T12:28:31Z


Not sure what you define as beatmap tracks but they were analyzed with "assume constant tempo" enabled.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2020-07-08T15:20:18Z


"assume constant tempo": beatgrid
that feature off: beatmap

So yeah, I am unable to reproduce this issue as you describe. Can you upload a video of it happening?

@mixxxbot
Copy link
Collaborator Author

Commented by: Swiftb0y
Date: 2020-07-08T15:57:57Z
Attachments: [video capture showing the bug.](https://bugs.launchpad.net/mixxx/+bug/1884324/+attachment/5390813/+files/video capture showing the bug.)


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.
You can see in the video that the beatgrids (and the track with it) drift apart, even though they should stay in sync.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2020-07-08T20:38:10Z


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)

@mixxxbot
Copy link
Collaborator Author

Commented by: Swiftb0y
Date: 2020-07-08T22:39:13Z


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.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2020-07-09T18:19:13Z


Are you moving the slider on the deck that has quantize on, or not? What are the natural bpms of the tracks?

@mixxxbot
Copy link
Collaborator Author

Commented by: Swiftb0y
Date: 2020-07-09T22:08:54Z


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.

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2020-07-10T02:49:20Z


go to internalclock.cpp and comment out the lines:

    if (m_bClockUpdated.fetchAndStoreRelaxed(false)) {
        return;
    }

does that fix it?

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2020-07-13T19:28:04Z


#2940

@mixxxbot
Copy link
Collaborator Author

Commented by: ywwg
Date: 2020-07-13T19:45:49Z


(yes, that fixed it)

@mixxxbot
Copy link
Collaborator Author

Issue closed with status Fix Released.

@mixxxbot mixxxbot transferred this issue from another repository Aug 24, 2022
@mixxxbot mixxxbot added this to the 2.3.0 milestone Aug 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant