Fix wrong visual play position when inside loop

[JoergAtGithub]

Closes: #11836

The loop is now considered in VisualPlayPosition::getAtNextVSync which determines the visual play position used fo the waveform rendering. The play position indicator is no always inside an active loop. Forward and reverse playing direction is considered.

It wasn't neccessary to change VisualPlayPosition::getPlaySlipAtNextVSync because this is only used for the spinnies, which do not visualize loops. Therefore no special handling for slip position was necesarry.

Furthermore I unified some odd sympol naming in the VisualPlayPosition code.

[m0dB]

Nice to see it was indeed straightforward and could be done with a few changes!

[daschuer]

It wasn't neccessary to change VisualPlayPosition::getPlaySlipAtNextVSync because this is only ...

The slip position also follows loops. Even though there are no loop markers on the spinners, it would be correct to consider loops as well.

[JoergAtGithub]

The slip position also follows loops

This seems to be another bug. According to our manual, not to follow loops is explicitly the purpose of the Slip mode:

When active, the playback continues muted in the background during a loop, reverse, scratch, etc.

[ronso0]

I think @daschuer refers to the situation where a loop is enabled before slip mode is enabled, see #11435

[ronso0]

FWIW I noticed the offset with quantized full-track loops aka repeat where the playpos would be before track start for a glimpse, and then jump to the actual engine playpos.
Hence I was thinking about using LoopingControl::nextTrigger (which considers both loops and repeat) when I gave my pessimistic view on a quick fix.

[JoergAtGithub]

It wasn't neccessary to change VisualPlayPosition::getPlaySlipAtNextVSync because this is only ...

The slip position also follows loops. Even though there are no loop markers on the spinners, it would be correct to consider loops as well.

In general I agree, but this is out of scope of this waveform PR!
I tried to create a follow-up PR for the spinnies, but I struggled with the behaviour of the Slip Mode in general. It just not does what I expect from a Slip mode, and the documentation doesn't helped me to get a better understanding.

[daschuer]

This does not work with catching loops in font of the play position. In this case the waveform shows already the loop.

[daschuer]

I think this must only applied when the data.m_playPos is on one side of the loop marker and the interpolatedPlayPos is on the other side.

[JoergAtGithub]

I've commited a fix.

[daschuer]

You can use exactly the same code in getPlaySlipAtNextVSync() for the spinnies for both positions slip and normal.
Both will follow the loop.

[JoergAtGithub]

You can use exactly the same code in getPlaySlipAtNextVSync() for the spinnies for both positions slip and normal. Both will follow the loop.

I don't think it's that easy for the slip position, because it depends on the order of activation of loop and slip mode. I worked already on a follow-up PR for the spinnies, but than found: #11844

[JoergAtGithub]

Based on #11848 I could easily add the code for the slip indicator in the spinnies too.
The new code also fixes the visual bug, that the slip indicator appeared for a moment at 12 o'clock position when enabling it.

[JoergAtGithub]

Ping

[daschuer]

Thank you. Two remaining comments.

[daschuer]

Loop Start and End should be only read atomically. This avoids that the position can slip out during moving the loop.
In this case LoopInfo should be returned, or both values in a single call.

[daschuer]

Can you add a brief comment about armed?

[JoergAtGithub]

Requested changes are done!

[daschuer]

LGTM, Thank you