When a track with old BPM data is rescanned after it is loaded, the auto-sync value can get crazy

[xerus]

Easily reproducible:
1) Choose two songs with the same BPM
2) Load the first one into a deck and enable auto-sync on both decks
2) For the second one, reset "BPM and Beatgrid" and then manually edit the BPM to be half of what it was before
3) Load the second one into the other deck and watch auto-sync going insane.

-> Auto-sync should recalibrate itself whenever the BPM of a track is changed in any way, instead of blindly changing the speed.

Where this happens in real-life scenarios: When I have the option to "Re-analyze beats when settings change or data is outdated" option enabled and the BPM was embedded and not scanned by Mixxx, it will first assume the embedded BPM, then rescan and go mad if auto-sync is enabled. The worst thing is that THIS WILL SOMETIMES EVEN AFFECT THE TRACK PLAYING IN ANOTHER DECK! Its speed is doubled or halved, and a whole mix can be ruined by this error!

I use Mixxx-2.2.0-rc on Linux

[Daniel Schürmann (daschuer)]

I cannot reproduce any unexpected behavior.

What means: "watch auto-sync going insane"
What exactly happens with the tack, bpm display and rate slider. What should happen instead?

[xerus (xerus2000)]

Oh, did you have the option "Re-analyze beats when settings change or data is outdated" enabled?

The Tracks will be sped up to surreal speeds, up to 720 BPM, depending on how exactly you execute it.

[Daniel Schürmann (daschuer)]

Does it (still) happen with the latest 2.2 Version? We have merged a related PR https://github.com/mixxxdj/mixxx/pull/1924
Does this change the situation?

[xerus (xerus2000)]

I use the mixxxbetas ppa and update my computer daily. Yes, it still happens.

I have now created an unlisted video on YouTube, showing all steps to reproduce this issue: https://youtu.be/1U43L02-vNE

[Daniel Schürmann (daschuer)]

The somehow random jump on the first sync press on the right deck is caused by syncing to a paused sampler. This is fixed here https://github.com/mixxxdj/mixxx/pull/1818 waiting for a review.

[xerus (xerus2000)]

Great! But obviously, the other bug is much more important, since it can completely mess up the playing track simply by loading another one.

[Daniel Schürmann (daschuer)]

I think I got the original issue.
Unfortunately the fix breakers test around sync master.
How can we solve this.
If you set a deck explicite as sync master (no skins has controls for it yet, so the question is only theory) and you change the beatgrid of this master track. What should happen?
I consider this a user error. But Mixxx should respond reasonable. Currently the new speed instantly adopted leading to a speed jump on all folowers. This is probably undesired behaviour.

I propose to disable the master state in this case. The user can enable master middle again afterwards.

[xerus (xerus2000)]

I think it should keep master BPM as is and instead behave as if it was reloading the track with the new BPM.

[Daniel Schürmann (daschuer)]

a fix can be tested here: https://github.com/mixxxdj/mixxx/pull/1955

[Daniel Schürmann (daschuer)]

Now the tempo of the edited Deck changes to match the tempo of the other deck.
It the edited Deck is "sync_mode" = 2 (Master, hidden feature) the edited deck plays with unchanged Tempo but the followers are adjusted.
I hope that is reasonable.

[geozubuntu (geozubuntu)]

In win 7 x86 and
Linux Mint 19.1 x64
with the 2.3.0-alpha-pre (build master r6662)

It happens to me even if I don't change the BPM. If I load the track a 2nd or 3rd time it behaves like that sometimes higher sometimes lower BPM. Check the zip file below.
I tested it with the same track from different albums to be able to check the waveforms as well and compare the sound. See following zip file with pictures from Linux Mint 19 you can check settings and screensots. Check the 2 first tracks and both decks. It changed the deck one to 136 from 170 with no reason.

Keep up the good work.
Best regards

[Daniel Schürmann (daschuer)]

https://github.com/mixxxdj/mixxx/pull/1955 should fix the issue.
Are you able to compile the PR branch?

[geozubuntu (geozubuntu)]

@Daniel Schurman
Unfortunately I don't know how to compile and I don't have the environment installed. I am a tech person not a programmer. I just download the latest master build and install. Is there somewhere an installer containing these fixes so I can install and check ? If yes I can check it.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9550