S4 Mk3 screen support

[acolombier]

This PR include support for the S4 Mk3 screen support. It is made to work without #12199 although there is a setting to enable communication between mapping. This way, I can maintain a single mapping definition, without needing to get an API commitment for communication between mapping.

It includes two themes:

• Traktor Pro stock inspired theme
  
• Joe Easton's inspired theme
  

Depends on:

• feat: add file and color controller setting types #13669
• feat: improve screen rendering framework #13737

Here is the list of improvement made on the core mapping

• Beatjump tab
• Stem tab
• Support for beatloop roll inside a loop
• Screen feedback (optional, require Ability for controller to share data at runtime #12199 - temporary merge available on feat/s4-mk3-screen-support-with-shared-data)
• Add library page scroll
• Ability to preview the active deck hotcue
• Ability change the hotcue color

[acolombier]

Consider using reloop_toggle to allow relooping if the beatloop roll was terminated when the slip position was after the loop exit

[acolombier]

@mixxxdj/developers what are you opinion about where this PR is aiming?

I'm now at a stage where the mapping is pretty stable and usable. I appreciate that this introduce a huge amount of source code. I'm afraid there is no alternative, and I think the current screen content is really impressive! (Happy to post a full demo video if you would like me to justify adding 74 QML files...)

I would like to get an agreement in principle before I start working on the documentation PR.

Note that every C++ change is the early version of the dependencies and once those are merged, this PR should include no core source changes.

[ywwg]

I will try to take a look at this soon.

[JoergAtGithub]

Sure, we want to have this feature in Mixxx. This is why we co-financed the S4 Mk3 for Owen.
And as long as the code is device specific, we do not have the high requirements to the code anyway. These only apply for generic code shared between different controllers.

[ywwg]

These only apply for generic code shared between different controllers.

the biggest point of controversy was how the data from the engine is shared with the controller. That is a mechanism that will be used by every controller with a screen, and needs to be safe and efficient. If we are agreed on how that works, then the rest of the changes are good to go

[acolombier]

The approach I went with is a controller settings to enable the API rejected in #12199, is this is a must have for the screen.

As suggested in the PR description, this will allow me to maintain a single code base, and also allow advanced users to build this feature while still using the mainstream mapping.
If you've been following the development of the S4 on Zulip, you've probably noticed that I have been maintaining multiple forks and it has now become unmaintainable so getting it in one code base is a hard requirement on my end.

Obviously, if we ever manage to get a stable API in Mixxx, we can eventually make the migration.

[ywwg]

for sure, we want to get this in and don't want to have forks that need maintenance. I do like the approach of using a controller setting to enable / disable the new API. That limits the blast radius nicely. If/when another controller screen comes online, we can iterate on the design as needed.