(fix) Waveform scratching: fix seeking to hotcue (reduced, alt. for #14059)

[ronso0]

This is #14059 without the member/slot refactoring, i.e. just the fixes + switch to parented_ptr etc.
I hope this lowers the barrier to get the fix into 2.5.1

Original description:

---

This is a first (still dirty) fix for #13981

TL;DR
it's now possible to seek to hotcues while doing wave scratches.
Scratching at/across loop boundaries (active) still works.

Recently I compared the available methods for scratching with controllers, and while PositionScratchController (developed for waveform scratching) turned out to be the best (for me, no drift, smooth at low rates, nice spinback) I couldn't really use it as I want to because seeking to hotcues while scratching (holding the wheel, or turning very slowly) produced insanely high rates, and didn't stop at the cue pos.

Even though the bug is fixed I still consider this 'dirty' because I don't fully understand what was going wrong with the filters after seeking.

[daschuer]

How does the m_seekSamplePos relates to currentSamplePos?
Can you add a source code comment? Are they equal for one call?

[ronso0]

After seeking, the engine is still using the 'old' playpos, so m_seekSamplePos is different from currentSamplePos, unless rate is 0, of course. (0 or close to 0 is my use case with the controller btw)

Here's the call hierarchy:

EngineBuffer::
processTrackLocked
+ processSeek()
| + setNewPlaypos( seekPosition )
|   + RateControl::notifySeek( seekPosition )
|     + PositionScratchController::notifySeek( seekPosition )
+ RateControl::calculateSpeed
|   + currPos = EngineControl::getFrameInfo().currPos
|   + PositionScratchController::process( currPos )
|   + PositionScratchController::getRate( currPos )
get framesRead with RateControl speed
+ m_playPos = ReadAheadManager::getFilePlaypositionFromLog( m_playPos, framesRead )
+ setFrameInfo()
+ EngineControl::setFrameInfo()
+ RateControl::process

This is obviously not a complete fix (and I'm not sure that can be done in PosScratchController alone) because no matter if we adopt the seek immediatly or delayed in the 2nd call after notifySeek, there's always a visual stop and a dip in rate (though not 0) when moving the mouse with constant speed (as far as that is possible with a track pad with acceleration).

Regardless, I'm in favor of merging this simple fix while we keep debugging.
Given the fact that this bug has been around for very long and we got not reports, I assume not many user seek while wave scratching (and even less use the scratch_position for controllers) and it'd be good to fulfill at least the basic expectation that seeking doesn't cause major glitches.

The perfect implementation would IMO be that the mouse/controller move is computed as if there was no seek, ie. get rid of the rate dip. (btw I'm not entirely sure if that's currently the case with controller scratch methods)

[daschuer]

I have tested a bit an it turns out that the new position is applied second process() call so you need to skip one or put the adoption of the seek position at the bottom of the process() call. The adoptSeekPos does also not work right. I think we need to reset the m_samplePosDeltaSum instead. I have tried this but it fails as well. At one version it seeks to the cue point and the immediately back to the original position. So we probably need to tweak the value and just subs tact the seek distance or such. (not tested).

Testing with the maximum audio buffer size was by the way the best to trace what actually happens.

[ronso0]

I have tested a bit an it turns out that the new position is applied second process()

FWIW I could never observe that exact the seek position is used for PositionScratchController::process(), there was always a diff (usable minimum was ~100 samples). I figured that with a version where I waited until the currPos and stored seekPos were close and then adopted the seekPos as prevPos 6927fdc

I think we need to reset the m_samplePosDeltaSum instead. I have tried this but it fails as well.

Thought so, too, and tried it as well as some other combinations, but none worked.
Except this one.

At one version it seeks to the cue point and the immediately back to the original position.

Yes, IIUC that is the original issue that causes the high rate.

So we probably need to tweak the value and just subs tact the seek distance or such. (not tested).

If you like to debug further (I don't) and you figure something I'm happy to test it!

[ronso0]

In order to keep you review I have decided to close #14059, rebased this one (fix conflicts) and adopt the only different commit from #14059.
Also reworded a commit because the already merged parented_ptr commit already contains the PositionScratchController refactoring.

Will address your review soon.

[daschuer]

Here it is: ronso0#90

[ronso0]

there's always a visual stop and a dip in rate

I think that occured simply because I used hotkeys for seeking.
If I use a virt. MIDI script and let that do the timed seeking all is good, the waveform sticks to the pointer even while seeking 👍

[daschuer]

Here is a final bit: ronso0#91

[daschuer]

LGTM, thank you.