user-configurable waveform band colours

[mixxxbot]

Reported by: mxmilkiib Date: 2020-09-23T20:17:42Z Status: Confirmed Importance: Wishlist Launchpad Issue: lp1896834 Tags: preferences, waveform

---

It would be handy if the user could change the colours of the bands of a waveform to their own preference, rather than changes having to be made at the skin level.

[mixxxbot]

Commented by: Be-ing Date: 2020-09-26T01:19:02Z

---

Is this really helpful? Let's not keep adding preferences just because someone wants to change something.

[mixxxbot]

Commented by: ronso0 Date: 2020-09-26T11:00:22Z

---

There are situations where this can be helpful:

• adjust colors to your preference
• choose stronger colors/contrasts to compensate visual disabilities, screen quality, lighting situation

For the Preferences I think this can be handled with [ ] "override skin colors" checkbox [high] [mid] [low] color chooser below each bands gain spinbox

[mixxxbot]

Commented by: Holzhaus Date: 2021-03-09T01:36:50Z

---

I think we should design special color schemes, such as:

• Regular Colors
• Protanomaly
• Protanopia
• Deuteranomaly
• Deuteranopia
• Tritanomaly
• Achromatopsia
• Tetrachromat
• High Contrast

These should be implemented globally and it should be possible to override them at the skin level for better integration into the skin.

[mxmilkiib]

I'd love my waveforms to be styled as in Rekordbox. See Zulip convo.

Related: #12326

[daschuer]

The original bug requests to configure colors. This is IMHO to complex for a regular user. Let's optimize the current waveforms regarding certain aspects. The is a use case to clone the Recordbox waveforms to have a matching appearance on all platforms. This is already tracked in https://github.com/mixxxdj/mixxx/issues/11833 Can we close this one as "not planned"?

[mxmilkiib]

11833 is about the dynamic height of the waveform. The conversation strayed into decoupling waveform style from skin, but the idea of such "presets" or whatever was strangely shot down so in that issue thread. Only now I realise I had already made a prior feature request about that specific issue.

Edit: I've already lost my Rekordbox colours clone because the skin was overwritten on reinstall of another build.

Edit2: I'd think there's also the visual accessibility angle to this

[ronso0]

Edit: I've already lost my Rekordbox colours clone because the skin was overwritten on reinstall of another build.

User mods (skins, mappings, keyboard config) should always go into the user directory https://manual.mixxx.org/2.4/en/chapters/appendix/settings_directory.html See https://github.com/mixxxdj/mixxx/wiki/Creating-Skins#change-an-existing-skin

[ronso0]

Can we close this one as "not planned"?

Why? The customization (frontend) can be simple. We can merge my first proposal with @Holzhaus's (presets to address visual disabilities). We'd have three color boxes and a combobox with these items:

• Colors set by skin
• Preset1
• Preset2
• ...
• Custom -> unlocks three color pickers (unlocks Edit buttons next to each color preview box

Preset can also be color schemes from other software. Quite some work to build the backend, but the UI/UX can be simple.

[mxmilkiib]

User mods (skins, mappings, keyboard config) should always go into the user directory https://manual.mixxx.org/2.4/en/chapters/appendix/settings_directory.html See https://github.com/mixxxdj/mixxx/wiki/Creating-Skins#change-an-existing-skin

So Deere uses relative paths, e.g., <Style src="skin:../Deere/style.qss" etc.

This breaks when the skin directory is copied from /usr/share/mixxx/skins/ to ~/.mixxx/skins/

Copying a non-altered Deere/ into ~/.mixxx/skins/ gives two default "Deere" skin menu entries plus the new "Deere-whatever", which works, but isn't elegant.

I missed/forgot that skins can have sub colour schemes, like LateNight has Classic and PaleMoon, but this, AFAIU, suffers the same kind of problem;

a) the scheme is pointed to from the main skin.xml, under /usr/, access of which is beyond regular users,

b) the sub xml/qml filename that [usually I guess] is pointed to by skin.xml that defines the waveform colours is not standardised,

c) a+b means one can't just (do an easier code change and have it so the user can) drop a single file in the same directory name as the base skin but under ~/.mixxx/skins/XXX/subscheme instead to overwrite/suppliment the originally available style/styles, let alone a single file with just three or six new lines to define alternative waveform colours.

[mxmilkiib]

For the record, for anyone looking to change Deere waveform colours but not get their head around understanding the entire skin system; with the solution that duplicates Deere/ in the same user accessible directory (~/.mixxx/skins/) as the newcopy copy;

one needs to a) edit skin.xml, replacing "Deere/" with "Deere-newcopy/" (i.e, in vim, :%s/Deere\//Deere-newcopy/gc)

then b) edit desk_singletons.xml; change the DeckWaveform object section from containing "skin:../Deere/deck_waveform.xml" to be "skin:../Deere-newcopy/deck_waveform.xml"

and c) edit deck_waveform.xml to add the desired colour hex codes in the SignalHighColor, SignalMidColor and SignalLowColor tags

whilst d) making sure that in the Preferences/Waveform section, the "Waveform type" is set to just "Filtered" not "Filtered (GLSL)" (this one is a bug: #12449)

Edit: for what it is worth, this is an inelegent hack that a) duplicates all skin files, rather than just deck_waveform.xml, and b) ignores the skin styling system, which I ignored because it appeared more baroque to quickly achieve a solution from, especially using a skin that has no existing template substyles nor sets the waveform colour style in the its .qss not .xml.

[ronso0]

Yes, the way the templates of the base skin are set/read is inconvenient for skin mods. But indeed copying the source skin is the safer way since the built-in skin may change at any time, which would break the mod.

I'll look into it, maybe there's a fix possible on the c++ side.

Edit I think separating user skins and built-in skins in the skin combobox would already help.

[ronso0]

FYI a fix for the skin mod issue is in #12463

[acolombier]

Once #13220 is merged, it will be easy to add the ability for waveform to use user-specified colour, defined with a colour picker in the preferences, and allowing easy tweak of the colour defined in the theme. That should help accommodating user with colour perception disabilities as well as different tastes, without having to edit skin files directly. Happy to look add adding that option if that PR gets in.

[mxmilkiib]

@acolombier that would be marvellous, thank you!

A quick note again to tie discussion history together being that #11833 ended up touching on presets also, though presets are a step beyond a picker, which would be incredibly handy itself as it stands.

Fwiw, to note, post perusing label:waveform and seeing #7929; another simple skin config value that could be exposed in the Preferences is the waveform align config to optionally only display one side of a waveform.

[acolombier]

This is still very bare bone and is lacking features (e.g reset option in context menu), but I'd be keen to hear some early feedback before I spend more time on it!

https://github.com/mixxxdj/mixxx/assets/7086688/ab311f89-8343-41c6-9394-405e0144d505

[Swiftb0y]

maybe have a configure button along with a color preview per band?

[Swiftb0y]

how does it work for uncolored waveforms?

[acolombier]

Yes sorry, I should have given a bit of context. The context menu will show all the color that the waveform uses so it can be overwritten. In this example, only "bass color" was defined. AFAIK, all waveforms have at least one colour since them empty waveform is equivalent to disable waveform, isn't that correct?

[Swiftb0y]

I think so yeah.

[Swiftb0y]

Thanks for the explanation.