Waveform playmarker position shown outside loop, while track is inside loop

[JoergAtGithub]

Bug Description

In the screenshot below, you see the blue actual playmarker position outside the active green loop:

Above the loop size was 15ms and the refresh interval 60fps (16,6ms).

The problem increases with lower framerate (here 20fps - 50ms):

Version

2.4.0beta

OS

Windows11

[ronso0]

I think the short version of the story goes like this:
The playpos CO 'moves on', unaware of the loop, while the engine processes fixed-size buffers and does wrap around the play pos to loop_in, which updates the play pos (visual) one buffer length too late.

not sure how to solve this, or if it's possible at all without rewriting parts if the engine, or copying engine code to waveforms in order to make them aware of loops, repeat, slip mode etc.

[m0dB]

For clarity, where @ronso0 says 'moves on', it actually is: we predict where to play position (and slip position) will be on the next visual frame. It is this prediction that doesn't take looping into account.

I think this can be solved easily by adding loopInfo.startPosition and loopInfo.endPosition from the EngineBuffer's m_pLoopingControl to the arguments to the m_visualPlayPos->set(...) call in EngineBuffer.

In VisualPlayPosition::getAtNextVSync and VisualPlayPosition::getPlaySlipAtNextVSync, we can then adjust the predicted playPosition and slipPosition accordingly.

The code to do the adjustment is in LoopControl::adjustedPositionInsideAdjustedLoop which doesn't seem to use any member variables so it could be moved to a static method.

[ronso0]

Yeah, might work. That's what I meant by "copying engine code to waveforms" 😉

[m0dB]

Right, but I mean that this can be done without any actual code duplication. There are other ways to do this (e.g. replicating the entire loop control at the UI side which would act on the some control parameters) that would certainly involve a lot more "copying engine code to waveforms" 😅

@JoergAtGithub maybe you can give it a try with these suggestions? Otherwise, I can have a go at it. But I assume this is not a blocker for 2.4, so no hurry, right?

[ronso0]

Yep, no blocker, it's 'always' been like this.

Great if it's as easy as you say 👍

[daschuer]

@JoergAtGithub: Can you confirm you have taken the screenshot while playing and that is does not happen when paused?
Than it is the mentioned side effect of quantization of loop cycle, audio buffer and refresh rate.

I am not sure if the mentioned solution by m0dB is worth the work, because this will introduce other issues like waveform moving backwards or stopping. Just like wheels in movies turning backwards in certain speeds.

[JoergAtGithub]

PR is here: #11840
LoopControl::adjustedPositionInsideAdjustedLoop wasn't suitable here, because we don't move the loop itself here. A simple modulus/remainder operation did the job.