-
-
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
Adjust ReplayGain: Allow user to update the replaygain value based on a deck pregain value. #4031
Conversation
Thanks for working on this! This feature has been at the back of my to-do list for a long time. WTrackMenu is also used for the right click menu of the library where multiple tracks can be selected. So I think the first commit should be removed and the second one rebased. |
As for the UI, I think adding this to WTrackMenu is okay, but I'd primarily want to use it by mapping a ControlPushButton on a controller. |
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, in general it looks good. I have added some findings.
That does not work if the replay gain value has been reset before. |
in cases where more than one track is selected, TrackModel is set. Currently m_trackPointerList is only initialized in code in a single place, inside loadTrack:
It is never initialized from another list, or ranged, etc. Therefore it's never used by more than one track. |
A track can be loaded in more than one deck -- either the button would have to be per-deck, or we would have to guess which pregain the user meant to use as a reference. How would you want to bind the button? |
Give each deck a ControlPushButton. |
Ah, in that case |
I wonder why this over-engineering has not been detected yet?! It should better be changed in a separate, preliminary PR. |
is the commit wrong as-is? It will be annoying to strip out of this PR, but I'd like to have an actual reason to do so. |
I agree, let's not be pedantic about splitting up the PR. As long as it's in a cleanly separate commit I think it's fine. |
The Real Problem™ is that wtrackmenu should not store important state in one of two places (a model or a pointer). So I could understand this commit as being unnecessary / wasted effort if someone else is going to go through and clean up the file to be consistent. HOWEVER, the change as written is strictly an improvement -- it removes a lot of unused / dead code and leaves things in a more understandable state. |
@Be-ing I added pushbuttons, can you test to see if they work as you hope? |
Pull Request Test Coverage Report for Build 1071599741
💛 - Coveralls |
@@ -192,6 +192,13 @@ BaseTrackPlayerImpl::BaseTrackPlayerImpl( | |||
|
|||
m_pRateRatio = make_parented<ControlProxy>(getGroup(), "rate_ratio", this); | |||
m_pPitchAdjust = make_parented<ControlProxy>(getGroup(), "pitch_adjust", this); | |||
|
|||
m_pUpdateReplayGainFromDeckGain = std::make_unique<ControlPushButton>( | |||
ConfigKey(getGroup(), "update_replaygain_from_pregain")); |
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 quite a verbose name for a ControlObject... how about just update_replaygain
... or set_replaygain
? store_replaygain
?
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 like the name. Our other CO names are often extremely ambiguous (so this PR introduces inconsistency 😅). You suggestions sound like I can set a the replaygain value directly, not like a button CO that takes only 1 and 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.
yeah I don't know how to make it shorter and include the ideas of both the deck pregain and the track replaygain. "apply_pregain_to_replaygain" ?
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 don't see how to remove any more words without making it confusing, and I don't think we have any limitations on CO name length
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 haven't thought of any better name, so... 🤷 I won't object to merging this over finding a better name.
This works, yay! I used it to manually set the ReplayGain for a track which I remembered to play way louder than others. The automatic reset of the gain knob to unity was surprising at first but I think it makes sense. |
Auuuugh the "close and comment" strikes again... |
yaij, finally a co for this! |
I believe all comments are addressed |
@ywwg Please document the behaviour and the new CO in the PR decription. |
… a deck pregain value. Currently accessible by right clicking loaded decks, including preview deck
Always refer to "pregain" instead of "deck gain".
Merge now or after the manual has been updated? |
@ywwg Please create and link a PR for the manual, then we can merge. |
Not a blocker for merge, but coveralls points out that a bunch of lines are not covered by any test:
Would be nice to add a test for this. |
Added a test. Manual PR: mixxxdj/manual#417 |
PR appears to be approved -- who wants to merge? |
Thank you! LGTM |
Currently accessible by right clicking loaded decks, including preview deck.
Also accessible through a new a new per-deck control pushbutton: "[ChannelX]", "update_replaygain_from_pregain". When pressed, the pregain of the associated deck is applied to the replaygain value.