-
-
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) hotcue_X_color control: color not stored in cue #12733
Conversation
src/engine/controls/cuecontrol.cpp
Outdated
@@ -2656,6 +2656,10 @@ void HotcueControl::slotHotcueColorChangeRequest(double color) { | |||
} | |||
// qDebug() << "HotcueControl::slotHotcueColorChangeRequest" << color; | |||
m_hotcueColor->setAndConfirm(color); | |||
// Note: for some reason the valueChanged() signal is not emitted, |
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 blocked to avoid endless loops. I think due to the read-only nature, slotHotcueColorChanged() is never called and can be inlined. setAndConfirm() should then only be set at the end when all other checks also have been performed successful.
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.
Please elaborate, I'm not very familiar with the contrl internals.
I see
Lines 289 to 304 in 94ffc14
void ControlDoublePrivate::setAndConfirm(double value, QObject* pSender) { | |
setInner(value, pSender); | |
} | |
void ControlDoublePrivate::setInner(double value, QObject* pSender) { | |
if (m_bIgnoreNops && get() == value) { | |
return; | |
} | |
m_value.setValue(value); | |
emit valueChanged(value, pSender); | |
if (m_bTrack) { | |
Stat::track(m_trackKey, static_cast<Stat::StatType>(m_trackType), | |
static_cast<Stat::ComputeFlags>(m_trackFlags), value); | |
} | |
} |
This emits
valueChanged
, not a value change request. Where is that blocked? I don't see how that would create an infinite loop.
slotHotcueColorChanged()
is indeed never called, and we also have an unused signal hotcueColorChanged
.
I'll adjust that.
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.
It is blocked here:
mixxx/src/control/controlobject.cpp
Line 50 in 94ffc14
// Only emit valueChanged() if we did not originate this change. |
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!
join uncalled slot, remove unusedsignal
943bdb2
to
d4adf53
Compare
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. LGTM
Fixes the hotcue color issue reported in https://mixxx.zulipchat.com/#narrow/stream/113295-controller-mapping/topic/Hotcue.20setting.20script
For some reason the valueChanged() signal is not emitted, therefore slotHotcueColorChanged() not being called and the new color not stored in the cue. The color control is reset as soon as anothe cue is set (track emits cuesUpdated() adn cues are reloaded from track, default color).
Reproducible with Qt5 and Qt6.
without this fix:
https://github.com/mixxxdj/mixxx/assets/5934199/aad6ae0f-2ea3-4825-ae77-7da8ba95b22b
For testing, use this mapping with virtual MIDI device:
load a track to deck1, click Eject on deck2
https://gist.github.com/ronso0/471efe54370a32fa9eb26a571a818dd5