Fix updating cues in WOverwiew

[daschuer]

This aims to fix #16075 and maybe #12620
However this is not yet fully tested and probably incomplete. That why draft state.

The issue is that WOverview is acting on changes of the loaded track and on various Cue related COs.
It assumes that every CO updates happens after all other cue related data is also updated which is wrong and the root cause of the iuse here.

Since that's is not the case we see MANY invalid update calls using incomplete data only if a single cue is set.

The problem problematic function is
WOverview::updateCues() that updates marked from Track data while other date is used from the CO interface.

There is also an issue with a recursive call into the HotCueConteol class. Updating a Hotcue cause updating the track which in turn updates ALL HotCueControls. The order of these updates causes the indifferent test results we have seen.

This is however currently needed, because a single track might be loaded into two decks and that's why a signal is required to update the cues if the other track.

Who has interest helping to look into this?

[ronso0]

Thank you, this fixes the issue with hotcue_set.
Remaining issues:

• removing one hotcue: it's shifted to track start?
• clearing hotcues: all remain until I hover the overview, and even then hotcues at the track start/Cue
• set intro/outro markers: range is updated (if valid) but mark doesn't appear until another one is set (the initial hotcue issue I suppose)

[ronso0]

IIUC it's a timing issue between these two slots, both connected to Track::cuesUpdated

1. CueControl::loadCuesFromTrack()
   • iterates over the cues and sets the position control values etc.
2. WOverview::updateCues
   • iterates over the cues and tries to get the positions etc. from WaveformMark (reads the controls)
   • calls WaveformMarkSet::update()

-> but 2. that may happen before CueControl::loadCuesFromTrack() actually set the position controls??

This is how slots are called currently (this branch), scrolling waveforms disabled, which confirms my theory:

1. WOverview::updateCues
2. WaveformMarkSet::update()
3. WOverview::updateCues
4. WaveformMarkSet::update()
5. CueControl::loadCuesFromTrack()

If this is true, the overview has been updated twice before, once via cuesUpdated and again via the WaveformMark controls.

Should we try to connect the overview to something like CueControl::cueControlsUpdated(), like when can be sure all positions have been updated?
Though, it seems to be cumbersome to connect WOverview to CueControl signals in LegacySkinParser::parseOverview()

[daschuer]

The original issue was fixed in #16088
So this can be closed.