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 gain issue with cloned tracks #12435
Conversation
Does this also fix #11788 ? |
33e0425
to
6bc888b
Compare
src/test/enginesynctest.cpp
Outdated
EXPECT_DOUBLE_EQ(87.5, | ||
ControlObject::getControl(ConfigKey(m_sGroup1, "bpm"))->get()); | ||
|
||
EXPECT_NEAR( | ||
m_pChannel1->getEngineBuffer()->m_pSyncControl->getBeatDistance(), | ||
m_pChannel2->getEngineBuffer()->m_pSyncControl->getBeatDistance(), | ||
kMaxFloatingPointErrorHighPrecision); | ||
|
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.
by removing these ProcessBuffers the two checks at the bottom are identical -- does it fail if play advances?
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.
Ah Ok, I did not realize that this was a test. I will revert it.
Done. |
I confirm this fixes #10550 But it seems there is a difference in how clones are aligned (without Sync) in 2.4 compared to 2.3.6, there seems to be some tiny offset / flanger. |
Let's focus on #10550 which aims to fix all flanger effects, independent of sync and quantize. There is no need for a recording. If you are able to create a flanger, please describe the steps and you may also share the file. Than I can hunt down the issue. |
Well, with two recordings you can compare the result of 2.3.6 and 2.4 much easier than running two Mixxx versions yourself. Yes, this needs to go to a separate issue. |
There was a similar ssue, that is fixed in #10550 does that fix the issue for you? |
We're in the PR that fixes #10550 ;) I noticed the effect with this PR, then I tested with 2.4 (identical) and with 2.3 from the ppa (issue not present). |
Ah ok. Is it a fixed bpm track? |
Nope, variable BPM. Approx. 105-145 |
I have discovered and fixed a ramping issue with ReplayGain that is now fixed. I can reproduce the Flanger issue with Soundtouch + Keylock enabled. My guess is that the fresh initialized filters behave different compared to the established filters of the playing deck. Rubberband does not show the issue. Not sure if we can fix it from the Mixxx code. This is out of scope of this PR. @ronso0 can you confirm this? |
This should also fix the flipping test HotcueControlTest.CueGotoAndPlay on Launchpad, because the result original depends on thread timing. |
@ronso0 can we merge this now? |
I don't understand the EnginePregain changes, sorry. What about moving those commits to another PR? |
You can find the first part of this PR here: #12515 |
Okay, #12515 targets main, so please remove the pregain commits here. |
#12515 is now for 2.4 with removed gain commits. |
Done. |
|
||
if (m_bSmoothFade) { | ||
float seconds = static_cast<float>(m_timer.elapsed().toDoubleSeconds()); | ||
if (seconds < kFadeSeconds) { | ||
// Fade smoothly | ||
if (seconds < kFadeSeconds && m_dSpeed != 0.0 && m_dOldSpeed != 0.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.
does this mean that once the replaygain is calculated, mixxx will now change the gain while the track is playing back?
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 condition applies the replay gain instantly without fading if the track is or was stopped. If it plays, fading is done.
The logic that a analyzer replay gain is not applied when playing is handled here:
mixxx/src/mixer/basetrackplayer.cpp
Line 711 in 59ca3a2
// Do not change replay gain when track is playing because |
0.00420177,0.00420177 | ||
0.00288188,0.00288188 | ||
0.00147617,0.00147617 | ||
0,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.
why are these all zeros now?
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.
That seems to be wrong. I will have a look.
0.00245179,0.00245179 | ||
0.00116233,0.00116233 | ||
0,0 | ||
0,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.
why are these all zeroes now?
@@ -527,7 +527,6 @@ void BaseTrackPlayerImpl::slotTrackLoaded(TrackPointer pNewTrack, | |||
m_pDuration->set(0); | |||
m_pFileBPM->set(0); | |||
m_pKey->set(0); | |||
setReplayGain(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.
why was this the wrong place to put the replaygain setting?
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 it was too late, the first engine call uses the replay gain of the previous loaded track.
@ywwg thank you for your good review. The test changes where wrong. |
@@ -1,6 +1,6 @@ | |||
-0.000926289,-0.000926289 | |||
-0.00185258,-0.00185258 | |||
-0.00277897,-0.00277897 | |||
-0.00277896,-0.00277896 |
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 will revert this rounding artefact during fixup
988ddbd
to
c57c3ec
Compare
No, I will create one. |
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.
thank you!
All green after debase and an approval from @ywwg. So it is ready to go. |
This PR fixes #10550 Via a couple of single fixes regarding using the right data at the right time.
This finally allows to play two cloned tracks with changing tempo without that the leader applies future or outdated tempo changes to the follower.