-
-
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
Sync Lock: Differentiate track loading from beats updating #3944
Conversation
35d217c
to
eb3e428
Compare
fix this commit history as well |
Pull Request Test Coverage Report for Build 1156225558
💛 - Coveralls |
ugh this commit history is now borked, fixing... |
a5b0969
to
0d1eb3f
Compare
ok I manually squashed this down to one simple commit. |
For such PRs I think it would be good to add the PR description to the commit message as well. No need to amend the commit, but I think it would be good practice in the future ;-) |
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. Didn't test this yet but code look good.
auto pButtonLeaderSync1 = | ||
std::make_unique<ControlProxy>(m_sGroup1, "sync_mode"); | ||
pButtonLeaderSync1->set(static_cast<double>(SyncMode::LeaderExplicit)); | ||
ProcessBuffer(); | ||
EXPECT_TRUE(isExplicitLeader(m_sGroup1)); | ||
EXPECT_DOUBLE_EQ(160.0, ControlObject::get(ConfigKey(m_sGroup1, "bpm"))); | ||
EXPECT_DOUBLE_EQ(120.0, ControlObject::get(ConfigKey(m_sGroup1, "bpm"))); |
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.
These test value changes are just for easier calculation by hand, right?
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.
Because the behavior of mixxx changed, the test now acts differently than it did before. So, I had to update some of the values. (Where appropriate, I also updated comments)
@@ -533,7 +531,7 @@ void EngineSync::onCallbackEnd(int sampleRate, int bufferSize) { | |||
m_pInternalClock->onCallbackEnd(sampleRate, bufferSize); | |||
} | |||
|
|||
EngineChannel* EngineSync::getLeader() const { | |||
EngineChannel* EngineSync::getLeaderChannel() 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.
Looks unrelated, but but probably makes sense.
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.
yeah it helped clarify -- "getLeader" would seemingly return a Syncable*
Use nullptr instead of NULL (reviewer suggestion) Co-authored-by: Jan Holthuis <holthuis.jan@googlemail.com>
constify bool (reviewer suggestion) Co-authored-by: Jan Holthuis <holthuis.jan@googlemail.com>
src/engine/enginemaster.cpp
Outdated
@@ -281,7 +281,7 @@ void EngineMaster::processChannels(int iBufferSize) { | |||
m_activeChannels.clear(); | |||
|
|||
//ScopedTimer timer("EngineMaster::processChannels"); | |||
EngineChannel* pMasterChannel = m_pMasterSync->getLeader(); | |||
EngineChannel* pMasterChannel = m_pMasterSync->getLeaderChannel(); |
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'm a bit confused about the Master
term here. I should rename it anyway (probably in a dedicated PR), but pMasterChannel
does refer to the sync leader channel not the main output channel, right? This is a bit confusing.
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.
yes, it should be LeaderChannel. I will file a PR to update the language
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.
eh, just fixed it anyway
review note: NULL -> nullptr Co-authored-by: Jan Holthuis <holthuis.jan@googlemail.com>
review note: NULL -> nullptr Co-authored-by: Jan Holthuis <holthuis.jan@googlemail.com>
…ynclock-05-explicitload
Normal loading of tracks now work like expected. |
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 this needs also some love for the instant double case.
ah ok. Yeah I'll take a look at that |
I can't reproduce the issue with doubles you describe. Also in your description you twice describe dragging the follower track onto the leader deck as if they are different cases. Can you please describe this case in detail, like: which decks have sync on? Which decks have tracks? What are the track bpms? Where are the rate sliders? etc etc. |
I was not able to reproduce this issue with const bpm track but it works with a beat map track see: simplescreenrecorder-2021-08-06_09.48.11.mp4 |
Can you test with this branch? https://github.com/ywwg/mixxx/tree/synclock-05-explicitload-debug |
(the bug is that bpmcontrol contains an obsolete function called syncTempo which attempts to duplicate the synclock logic but does a very poor job of it. I have removed the function and replace the few calls to it with proper calls to synclock code) |
fixed conflict |
src/engine/controls/bpmcontrol.cpp
Outdated
} | ||
|
||
syncTempo(); | ||
m_pSyncEnabled->set(value != 0); |
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.
This is the momentary sync of tempo only when right clicking the sync button.
Mapping this to sync enabled will also sync the phase = seeks the track.
The original use case is syncing the tempo without seeking. This is now no longer possible.
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.
moved these controls to the synccontrol and reimplemented using the correct code.
Unfortunately the tempo change issue when doing instant double still exists: simplescreenrecorder-2021-09-12_23.17.05_edit.mp4 |
This is a bug with deck cloning, not Sync. And this only happens with beatmap tracks. I believe this is happening because the order of the clone events is wrong:
The sync operation is taking place before the cloned track has performed its seek -- and at the beginning of the track, the local bpm may be very different. So Mixxx is taking the actual un-seeked local bpm and applying the rate slider, getting a new bpm, and then setting that as the new bpm. So the bpm error will compound in the direction of the rate slider. I don't know a lot about deck cloning so I don't really know how to fix this. But what we should do is do the seek first and then initiate the rate matching. I'd like to consider this issue "mostly fixed" except for this edge case. Let's file a bug for this new issue and get these other fixes in. |
m_pRateRatio->set(target->getBpm() * multiplier / localBpm); | ||
} | ||
|
||
void SyncControl::slotControlBeatSync(double value) { |
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.
This changes the behavior from a momentary control to a permanent switch.
I think we must not change it silently.
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.
fixed
028e849
to
2a66e45
Compare
I can confirm that the instant double issue is no regression from this PR. I have filed https://bugs.launchpad.net/mixxx/+bug/1946385 |
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.
LGTM, Thank you.
thanks for your patience <3 |
When we load a track, we want the deck to sync to other decks.
When we update beats of a Leader deck, we want it to remain at the same playback speed.