Add float widget to control stem UI

[acolombier]

This PR adds a widget allowing to control stems from the UI.

Due to how waveform are rendered, this widget had a to be a floating widget, which is making it quite unreliable, and thus is likely never to make it to main.

This PR is mostly hear as reference for anyone willing to test stem on legacy UI.

Note that stem can already be controlled on QML UI

[JoergAtGithub]

Let me first state, that I like the floating widget UI approach. But in its current state, it has too many visual glitches.

One approach is of cause to address all these glitches. Another approach might be to put the stem widgets into a collapsing side panel, similar to the beatgrid editing controls on the right site:

While not as elegant as floating widgets, I think the later would be pretty straight forward regarding mergeabilty.

[Eve00000]

or in a deck over the cover art?

[acolombier]

Appreciate the feedback @JoergAtGithub and definitely agree with the statement! I also feel like that floating windows approach is likely to offer a very poor support across some of the more exotic platform we are trying to introduce (WASM, Android, iOS...)

When it comes to having the control somewhere else as you suggested, my only fear is - how do we make that valid for other themes? Your suggestion sounds find for a LateNight, but not sure how we would make that work on Tango, Deere and Shade.
Overall, I'm not sure I really want to make that work for the legacy UI because it requires too much effort to workaround the dated and flawed UI framework (I'm talking about the XML home-made framework here, not the overall UI!), especially when it comes to part of it (waveform/cover-art/spinny) already using workaround preventing a proper use (dedicated OpenGL sub-windows, which makes QWidget composition incompatible with them)

Sadly @Eve00000, putting the control over the spinny suffers from the same limitation: these are sub-rendered section, dedicated to an isolated OpenGL window, so drawing a custom widget required either the same "hack" (floating window) or custom OpenGL rendering, but then widgets won't be interactive.

I would suggest we keep this PR open, so users still have a way to add controls to perform some test and development around stem, but otherwise, I would suggest we keep the stem feature CO-only, so only accessible via controllers and QML, as originally scoped (Actually, QML wasn't, so it is bonus here :D).

[Hot Take]
As I have expressed to a few of the Mixxx developers, I really would like to re-ignite the traction on making the QML interface ready, and having this kind of edge for new UI could be a way to get more of us motivated and excited to make that happen :)
[/Hot Take]

[Eve00000]

I wrote this on Zulip but evidently the connection between Github and Zulip is not a bijection so i copied it here.

Ok, sad indeed. Without visual controls… that means without viewing the chosen effect to.
There should be a visual indication that the loaded track is treated as a stem

Last week I discovered and plaed around with the qml (mixxx.exe —qml)interface too. I lust admit I have no clue of the work needed to finish it. I know there’s a designer in the house wit an incredible knowledge of the gui and the Lixxx-code.

[acolombier]

There should be a visual indication that the loaded track is treated as a stem

The waveform will remain as is, with the per-stem signal!

I have no clue of the work needed to finish it

Finger in the air, I would say it's about 50% done. @m0dB has started preparing some solid design for handling waveform rendering, and there is also some great PoC waiting to be continued on the library from Maarten, Jan and I.
At the current pace, it may be ready in 2-3 years. If we manage to create some momentum tho, I dare dreaming to see it live in less than 12 months :D

Another suggesting could be to keep that floating widget under a a feature flag? (e.g settings, command line argument)

[Eve00000]

Another suggesting could be to keep that floating widget under a a feature flag? (e.g settings, command line argument)

I think that would be a nice option to cover a 'step in' period

[Eve00000]

At the current pace, it may be ready in 2-3 years. If we manage to create some momentum tho, I dare dreaming to see it live in less than 12 months :D

May I ask what the parameters for this calculation are? #contributors and how much time dedicated per day / week / month only to this project? What is best case and worst case scenario? What could help / what could go wrong? (SWOT)
There will still be other things to cover, possible adaptations, solving bugs ...
Time must also be spend at analysis / coordination / testing and certainly at leading the project if it's done by multiple persons they have to be on the same 'channel'.

For me to compare, how much time have you already spend on the stem-project?
Is this (or parts of) something that can be done as a bachelor / master thesis? (In my days with the automation of a library with a vector organized dbase was good for a phd :-) )

[acolombier]

Adding for tracking

---

Two minor remarks regarding the floating widgets:

• It's sometimes difficult to distinguish the colored widget from the waveform which has the same colors. A border in a different color might help.
  
• The effect toggle button is very small an difficult to hit with the mouse

[acolombier]

Closing in favour of #3537