-
-
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
Fix issues with half/double and Sync Lock #3899
Conversation
@@ -289,7 +290,8 @@ void SyncControl::updateTargetBeatDistance() { | |||
targetDistance *= kBpmDouble; | |||
} else if (m_masterBpmAdjustFactor == kBpmHalve) { | |||
targetDistance *= kBpmHalve; | |||
if (m_pBeatDistance->get() >= 0.5) { | |||
// Our beat distance CO is still a buffer behind, so take the current value. | |||
if (m_pBpmControl->getBeatDistance(getSampleOfTrack().current) >= 0.5) { |
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.
very proud of this fix. It was hard to track down.
p.s.: I really, really hate half-double syncing and wish I had never done it :P. |
The PR after this will rename master->leader! So let's get this in yes? :) |
Clazy checks failed |
fixed |
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.
Thanks, I noticed no issues when testing this, but I can't really comment on the code changes because I'm not familiar enough with it. Would be good if someone else would have a look.
@@ -1445,6 +1445,23 @@ TEST_F(EngineSyncTest, ZeroBPMRateAdjustIgnored) { | |||
ControlObject::getControl(ConfigKey(m_sGroup2, "rate"))->get()); | |||
} | |||
|
|||
TEST_F(EngineSyncTest, DISABLED_BeatDistanceBeforeStart) { |
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.
Are you planning to fix this in this PR?
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.
no -- this is a much more complex issue and I'm not even sure what's going wrong. This is a pretty rare circumstance, and shouldn't be a release-blocker, let alone a PR-blocker.
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.
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.
I have a notable momentary pitch change in case of a implicit leader deck playing audible and a inaudible follower disables sync.
- Play track A
- Enable Sync A
- Move x-fader to A
- Play track B
- Enable Sync B
- A is implicit Leader
- Nudge Track A
- Disable Sync B
- Hear a tempo dip in Track A -> wrong!
This can be noticed the best if Track A is a 440 Hz Sine wave analyzed with a const beat grid.
src/engine/sync/enginesync.cpp
Outdated
continue; | ||
} | ||
pSyncable->setMasterParams(beatDistance, baseBpm, bpm); | ||
} | ||
} | ||
|
||
bool EngineSync::noPlayingFollowers() const { | ||
Syncable* EngineSync::getOnlyPlayingSyncable() const { |
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.
I think the function name can be improved.
Only playing can also mean that it is playing without being synced or without being audible.
Something like:
getLonlyPlayingSyncronizedSyncable();
getLonlyPlayingSyncable();
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.
do you mean "lonely" ? :) I tried "getUniquePlayingSyncedDeck"
Co-authored-by: Daniel Schürmann <daschuer@mixxx.org>
…st its nudge value
fixed. |
I can confirm the pitch dip issue is fixed with a nudged leader deck. Somehow the leader buttons are now broken. Is this a visual skin issue? The plain main branch is also affected. When I load a new track to a stopped explicit master deck the follower becomes high pitched. |
src/engine/sync/enginesync.cpp
Outdated
if (pOnlyPlayer) { | ||
// Even if we didn't change master, if there is only one player (us), then we should | ||
// reinit the beat distance. | ||
pOnlyPlayer->notifyOnlyPlayingSyncable(); |
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.
can you rename this to something like:
notifyUniquePlaying() or such?
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.
done
this is one of those edge cases. It's an explicit leader, so it's supposed to be in charge of the rate. Should we instead say that loading a new track causes it to relinquish explicit leader state? What's the right behavior? |
fixed with 52786c9 |
Yes the leader button was always meant to be temp. Is it ok if I leave it for now? |
I made the decks a few pixels taller to make room for the button. Is that ok for now? |
Would it be ok if I fix the track load change in the next PR? That's a separate bug from this one and this PR has been hanging around a while. I have a good track record of fixing these things :) |
Co-authored-by: Daniel Schürmann <daschuer@mixxx.org>
…st its nudge value
This conflcts with our conclusion in https://bugs.launchpad.net/mixxx/+bug/1808698. There, we decided that "the second deck is still playing at unity -- it was the leader and it should not change speed just because it reloaded and the bpm changed." The test we wrote has the other decks all changing speed to match the new value. |
I suppose the difference here is between when the beats are updated due to a track load (should resync to the playing bpm) vs beats are updated due to rescan (should keep the slider where it is). |
OK I have a new PR that fixes the track load behavior. It is very far downstream of this PR so I'd really like to get this in so we can move ahead |
friendly ping -- I'd really like to start getting these in |
I have noticed an inconsistency:
2:
I can imagine arguments for both behaviors, but both should behave the same. |
The behavior of nudging is IMHO correct, when playing with three decks. After rethinking the whole, my conclusion is: The current behavior is OK. |
LGTM, Thank you. |
ok cool. There's still a lot to fix with Sync Lock so we'll keep working on it |
One part of Sync Lock that isn't well-described by the code is the idea of which Syncable is responsible for initializing the Sync Leader values. This is not the same as the leader! For instance, when you push and hold sync, that deck becomes the leader but it initializes based on the values of some other deck. This concept was causing problems with half/double bpm calculation. The code is a little more explicit now, and doesn't just assume that the Sync Leader should be the source of sync params.
Also fixed some super edge cases