Sync Lock: End of track checking is not needed

[ywwg]

It's not necessary to unset leader status at the end of the track based on the playposition heck. It will change automatically anyway.

[ywwg]

Note that if explicit leader is set it will stay on the deck that reached the end of the track and stopped. If people would prefer that it hand off leader to another deck if available we can do that instead. That was the intent of the feature but it was broken in the case that there was no other playing deck.

[JoergAtGithub]

This solves the GUI slowdown for me on Windows!
Regarding the behaviour, I would prefer, if the Explicit Leader is hand over to another deck, or Internal Clock if no other deck is playing. The later case lacks the necessarry visualization in the GUI of cause.

[JoergAtGithub]

If people would prefer that it hand off leader to another deck if available we can do that instead.

Currently we've the following case, which can easily result in jumping beats in the audio output:
1.) Load a track in Deck1 and make it Sync Leader
2.) Load a track in Deck2 and make it Sync Follower
3.) Stop Deck1 manually
4.) Double Click on a track with different BPM in the library
=>The Tempo of the playing Deck2 changes instantaneous to the tempo of the not playing track in Deck1

I think a not playing deck must never stay Sync Leader.

[ywwg]

=>The Tempo of the playing Deck2 changes instantaneous to the tempo of the not playing track in Deck1

In this case of a stopped deck and a newly-loaded track I'm not sure we can predict that the user wants to keep the bpm of the loaded track vs the stopped track. No matter whether a deck is sync leader or follower, all sync decks will have the same BPM. So given the situation where deck 1 has a loaded track and both deck 1 and deck 2 have sync on, if the user loads a track in deck 2, either:

1. deck 2 changes bpm to match stopped deck 1
2. deck 1 changes bpm to match newly-loaded deck 2.

I think option 1, the current behavior, is more predictable because it is more likely that a user wants to keep the set playing at the same speed. If they want deck 2 to keep its natural bpm, they should turn off Sync (or, below, perhaps set it to explicit leader). If I'm misunderstanding your situation please make sure to explain the stopped/playing and sync states of all decks. There are a lot of variables involved.

I am not 100% sure that a stopped deck should be prevented from being explicit leader. What is the use-case for the explicit option if the program can still override the user's choice? The point of explicit leader is to say "no mixxx, I really really want this deck to be in charge". For instance, I might set deck 1 to be explicit master even if it's stopped. Then when I load a new track in deck 1, it would keep the new track's bpm rather than change it to match other sync followers. That seems like a valid case for stopped explicit leader.

[ywwg]

(The primary use-case I have for explicit leader is when two variable-bpm tracks are playing back. The Leader will play at a constant rate, and the follower will adjust its speed to stay in sync, possibly causing audio artifacting unless keylock is engaged)

[Russe]

Currently we've the following case, which can easily result in jumping beats in the audio output:
1.) Load a track in Deck1 and make it Sync Leader
2.) Load a track in Deck2 and make it Sync Follower
3.) Stop Deck1 manually
4.) Double Click on a track with different BPM in the library
=>The Tempo of the playing Deck2 changes instantaneous to the tempo of the not playing track in Deck1

I think a not playing deck must never stay Sync Leader.

I did some tests, but with standard alpha version, not with this PR.
Do you mean with 1.) and 2.) that both decks are playing?
When both are playing and I'm stopping Deck1, than sync leader will hand over to Deck2.
So I'm fine with this behaviour, because 4.) will not cause any tempo change of Deck2.

I can see the tempo change of Deck2 only when Deck2 is currently stopped, so Deck1 will stay as sync leader.
With this behaviour I'm also fine, because when nothing is playing, and I load a track to a sync leader deck this deck should become the real tempo of the track.

[ywwg]

So I'm fine with this behaviour, because 4.) will not cause any tempo change of Deck2.

yes this is how it works currently. I think the most important thing is that a track load does not cause a bpm change to other playing decks.

[Russe]

Any news on this? Can I help with tests or similar to get this to main?

[robbert-vdh]

This also fixes the GUI slowdowns for me.

(this probably doesn't need more confirmation, but it would be nice to get this sorted out)

[ywwg]

With multiple positive replies, and the relatively small amount of code changed, I think we should merge this. And then, if there are any new issues that pop up, we can fix those as they appear.

[robbert-vdh]

Been using this for the last couple weeks with and without sync and I have not yet run into any new issues that could be caused by this change.

[JoergAtGithub]

Thank you!

[ronso0]

may I ask why this bugfix didn't go into 2.4?

[JoergAtGithub]

If I revert the merge in Main using the Revert button, will the PR than be open again to be merged into 2.4?

[ronso0]

As the tooltip says Revert will only "Create a new pull request to revert these changes".
I think the correct approach would be to create another PR from ywwg/sync-end-of-track and target 2.4, merge that, then merge 2.4 into main and resolve the conflicts. @daschuer ?
@ywwg I assume this was actually meant to fix a bug in 2.4, no? since this branch was created before 2.4 was bracnhed off main