-
-
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
Passthrough: improve UI / UX #4794
Passthrough: improve UI / UX #4794
Conversation
b9343db
to
d8dc386
Compare
8bcaa10
to
53eb75d
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.
Looks and works good, only one minor finding.
The hotcues are still lit according tho the loaded track. I guess that is OK, or do we want to switch them all off?
this, | ||
&CueControl::cueClear, | ||
Qt::DirectConnection); | ||
connect(m_pCueGoto, |
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.
Some of these controls are event driven.
I can imagine that the logic is struggling if an event happens during disconnected.
Not sure if this actually is an issue because all buttons are momentary and it unlikely that a user presses one during switching ...
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.
Uff, good point. "Unlikely" != impossible : | like release a pressed hotcue when toggling passthrough..
I'll take a look. Hopefully there are only minor UX issues, no crashes..
Well, the reason I started workign on this was that the deck state was not consistent: So I thought the hotcues and (visual) overview seeking should be 'frozen' as well. |
Yes it is frozen with the last state. And when you load another track during pass through the hot cues button and colors changes to the new track. Kind of OK. |
Yeah, because IIRC we agreed that at least some degree of deck preparation should be possible, for when passthrough is disabled. |
That makes sense. |
40c2e89
to
1e797bb
Compare
1e797bb
to
fc56c59
Compare
src/engine/controls/cuecontrol.h
Outdated
@@ -346,6 +351,8 @@ class CueControl : public EngineControl { | |||
ControlObject* m_pHotcueFocusColorNext; | |||
ControlObject* m_pHotcueFocusColorPrev; | |||
|
|||
ControlProxy* m_pPassthrough; |
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.
Unused?
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, because creating and connecting it obviously got lost when splitting cue control changes into separate commits.
so: No, I'll --fixup
@daschuer There is indeed a small issue with blocking Cue controls it seems: |
fc56c59
to
b7be713
Compare
This is workign as before. Somehow my 'track load point' was changed to 'Intro start'. Ready for review. |
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 works good, we have only some violated debug assertions.
Thanks for your review @daschuer I already fixed what you pointed out, |
*ping |
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.
.