Skin Highlight Controls: highlight Skin Element Groups through controller scripts

[absorb-it]

New feature suggestion: allow highlighting of Skin elements with controller commands. This can be especially useful if you activate skin element groups (like one deck) to be controlled with your hardware controller, while other similar element groups can only be controlled from the mixxx GUI.

This is especially useful when you are going to use a 2 deck hardware controller for 4 decks. Instead of one small blinking LED indicating what Deck you are working on, this can be cleanly indicated in the GUI. If you are using a 2-deck controller to play with 4 decks you will have a look on the GUI anyway.

The example implementation was done for LateNight skins and highlighting of waveform, deckview and deck-equalizers as a group. Maybe it makes sense to make the selection about what to highlight more fine-grained to increase flexibility.

Highlighting can be triggered with engine.setValue("[Skin]", "highlight_deck[1-4]", true/false)

I'm open for suggestions.

[absorb-it]

the preview folder contains some screenshots, and will not be part of any 'release' :)

[ronso0]

This is indeed a neat helper, thanks!

What I don't like is that we now have borders per se, regardless if there's a script using the highlight controls.
( I see a blank/black border is required to keep un/focused decks / mixer columns / waveforms aligned).
Two simple fixes come to mind, no skin modification required:
1.* use 1 for Off and 2 for On in scripts, 0 means no border (admittedly a bit unintuitive)
2. [Skin],highlight_deck[1-4] is 0 by default, and additional helper COs [Skin],focus_deck[1-4] set it to 1 (and 2 for the focused deck(s)) as soon as any deck is focused.
similar to the Mic ducking helper

Regarding the alignment of un/focused regions, we may also set a stacked layout in the DeckContainer and put a WidgetGroup underneath the deck that takes care of the highlight (via background or border).

What do you think?

[absorb-it]

What I don't like is that we now have borders per se, regardless if there's a script using the highlight controls.

right!

Two simple fixes come to mind, no skin modification required:

Thought about this and searched trough the code - there is a third option:

3. Have one separate option to enable/disable external highlighting

This would solve the requirement to give the user some main switch to enable/disable this setting via some controller or skin option - some might like this feature, others might find it too offensive. With this approach it will be even possible to allow this per Settings configuration sidebar on request.

What do you think?

[absorb-it]

Over the day I thought about single-deck controllers or pad-only controllers - it makes sense to implement this in a way that every controller implementation can benefit from it. I think the implementation should be as universal as possible.

Therefore I suggest the following approach with adding some more controls:

• highlights_input_allow(true) - globally toggle highlighting based on controller input
• highlight_deck_X_enable(uint_8) - enable/disable deck- related highlighting with a bitmask:
  • 2⁰ complete outer container
  • 2¹ Spinner
  • 2² Cue/Play
  • 2³ Hotcue
  • 2⁴ Loop
  • 2⁵ Jump
  • 2⁷ Title
• highlight_mixer_X_enable(uint_8) - enable/disable mixer- related highlighting with a bitmask:
  • 2⁰ complete outer container
  • 2¹ EQ
  • 2² Gain
  • 2³ Volume
• highlight_preview_X_enable(uint_8) - enable/disable mixer- related highlighting with a bitmask:
  • 2⁰ complete outer container
  • 2¹ Waveform
  • 2² DeckSettingsGrid
• maybe others like highlight_effectUnit_X_enable(uint_8) and highlight_sampler_X_enable(uint_8)
• highlight_group_X_enable(true) - enable/disable highlight group 1-8
• highlight_group_X(uint_8) - configure highlight group 1-8, default 0x15
  • 2⁰ Deck complete outer container (default on)
  • 2¹ Deck Title (default off)
  • 2² Preview Deck Waveform (default on)
  • 2³ Preview Deck SettingsGrid (default off)
  • 2⁴ Mixer Channel complete outer container (default on)
  • 2⁵ Mixer Channel Eq (default off)
  • 2⁶ Mixer Channel Gain (default off)
  • 2⁷ Mixer Channel Volume (default off)

It's not clear if all those elements can be easily highlighted, but that's something I can figure out on the way. The approach will allow us

• to enable disable the external highlighting on a global level
• use predefined groups for easy highlighting of combined features related to the controller or
• go into the finest detail with changing the highlighting of small button groups

What do you think?

[ronso0]

I think for now we should stick to the basic use case, changing the deck controlled by a controller section. And that is usually the complete deck (transport controls, cues, pitch, mixer column) and effect units (see (1) below).
Note that many mappings for controllers that natively support deck switching per controller side (especially for older models) don't do the deck switching in js but in xml because they have dedicated MIDI/HID messages per deck.So, I'm not sure if if the maintenance / implementation effort for complex controller/UI binding is worth it.

(1) For Fx units we already have [EffectRack1_EffectUnitN],controller_input_active.

[absorb-it]

Implemented now some 'global' option to allow the external highlighting or not. If this is not activated, the layout is not changed a all. Separate options for all 4 decks are available and formatting is done with qss like

#WaveformBox4[highlight_input_allow="1"][highlight_deck="1"] {
    border-color: #82220d;
}

Implemented options are now:

highlight_input_allow
highlight_deck[1-4]

If this seems to be ok like it is I will go trough all styles and try to add some suitable effect for this external highlighting in a final step.

[absorb-it]

Preview:

[ronso0]

Interesting, this works without defining any qproperty in c++ (src/widget/wwidgetgroup.h)?

[absorb-it]

Interesting, this works without defining any qproperty in c++ (src/widget/wwidgetgroup.h)?

added some properties in 39258cb , just did it the same way as "highlight" was implemented with 05488db - and "just works". Most trouble I had finding some trigger to redraw the widget when Border is shown or not. This got solved with 6e64827

Did I missed something for a clean implementation? Had no issues / warnings on the terminal so far.

[ronso0]

added some properties in 39258cb , just did it the same way as "highlight" was implemented with 05488db - and "just works".

Whoops, my bad. For some reason I didn't see any c++ changes in the PR diff.
Looks good, will test this and take a closer look soonish 👍

[absorb-it]

Tonight I will change the naming of the options from "highlight_deck[1-4]" to "highlight_deck_[1-4]" (additional underscore) to keep this aligned with the other options.

[Swiftb0y]

Tonight I will change the naming of the options from "highlight_deck[1-4]" to "highlight_deck_[1-4]" (additional underscore) to keep this aligned with the other options.

I'd prefer highlight_GROUP, where GROUP is an already established group. So for instance highlight_[Channel1]. This would likely simplify the JS a little.

[absorb-it]

Tonight I will change the naming of the options from "highlight_deck[1-4]" to "highlight_deck_[1-4]" (additional underscore) to keep this aligned with the other options.

I'd prefer highlight_GROUP, where GROUP is an already established group. So for instance highlight_[Channel1]. This would likely simplify the JS a little.

done with 8bc1050

[absorb-it]

added documentation PR mixxxdj/manual#802

[ronso0]

I'll try to do a manual test soonish.

FWIW I'm not a big fan of these 5px borders. Why not stick to 1px like focus borders in all skins?

[ronso0]

I think a bit more granularity is indeed required, though I don't think we need the extensive bitmask pattern you proposed above. Can we go with deck | waveform | mixer for now?
For example with 4-deck controllers we'd usually only need the highlight for the decks and waveforms.
On 2-deck controllers with 4 deck capability added via mapping we'd need all three selectors.
I think it's fine to have more calls in the script then when switching decks:

engine.setValue("[Skin]", `highlight_mixer_{$oldDeckGroup}`, 0);
engine.setValue("[Skin]", `highlight_deck_{$oldDeckGroup}`, 0);
engine.setValue("[Skin]", `highlight_waveform_{$oldDeckGroup}`, 0);

engine.setValue("[Skin]", `highlight_mixer_{$newDeckGroup}`, 0);
engine.setValue("[Skin]", `highlight_deck_{$newDeckGroup}`, 0);
engine.setValue("[Skin]", `highlight_waveform_{$newDeckGroup}`, 0);

What do you think?

[absorb-it]

FWIW I'm not a big fan of these 5px borders. Why not stick to 1px like focus borders in all skins?

I found the partially bigger borders more obvious and more appealing, but anyway, I'm not sticking to this. And I can change this for my personal skin if I miss it too much :) Changed to standard highlighting in c826d32

[absorb-it]

What do you think?

Implemented as suggested in e1509c3 , a lot of options... But as we both agree the a more fine-grained control might be required, this is the way.

[github-actions]

This PR is marked as stale because it has been open 90 days with no activity.

[absorb-it]

Anything than wait that can be done to get this implemented? (bot added stale label)

Best regards, Rene

[ronso0]

Sorry this had to wait so long. As ususal priorities shifted and this has been pushed off the table.
Will take a closer look soon (bookmarked, but feel free to ping us again if you have the feeling we forgot about it)

[ronso0]

Back I am : )

A quick test shows that the default mixer has less padding now.
old | this PR

Will do complete test tomorrow 👍

[absorb-it]

A quick test shows that the default mixer has less padding now.

Not on my system. :)

Just compiled the same mixxx-version now once with and once without the patch and did fullscreen screenshots - there are no differences when flipping trough the images at all...

with SkinHighlight PR (18:30):

without PR (18:37):

Regards, Rene