fix: corrected tick lookup for swing playback

[Danielku15]

Issues

Fixes #2657

Proposed changes

There were some incorrect usages of playbackStart and playbackDuration where we should actually use the midi tick lookup.

Especially in swing cases this could lead to wrong playback ranges and seeks.

Checklist

• I consent that this change becomes part of alphaTab under it's current or any future open source license
• Changes are implemented
• New tests were added

Further details

• This is a breaking change
• This change will require update of the documentation/website

[AvaTheArchitect]

Daniel, we retested the SRV / Pride and Joy shuffle cursor issue against alphaTab 1.8.3 after #2702.

Bug is still here but much worse!

alphaTab 1.8.3 appears to degrade native cursor motion globally:
cursor no longer glides smoothly and instead steps/hops note-to-note across playback in addition to parking on the first beat slide in M1. Prior to this on the same It'sMyTabs LouisLam repo the player showed the cursor doing a slingshot in which it would jump twice. But the logs do not pick up the cursor parking:

Original Baseline Testing Prior to the V1.8.3 Version Update:

What the 1.8.1 baseline proves

1. Native timing is monotonic during the visible jumps

Both regression objects show:

timeDelta: +2.666ms
currentTickDelta: +1
isSeek: false
currentTickMovedBackwardWhileTimeForward: false

So alphaTab’s playback clock is not moving backward during the observed slingshot.

2. The native cursor X jumps sharply forward

First jump:

currentTick: 613
nativeBeatX: 122.752 → 164.617
nativeBeatXDelta: +41.865
nativeCursorSharpMoveWhileTimeForward: true

Second jump:

currentTick: 1449
nativeBeatX: 156.831 → 214.569
nativeBeatXDelta: +57.738
nativeCursorSharpMoveWhileTimeForward: true

visual observation: the native cursor races/slingshots forward.

---

After V1.8.3 installed:

The issue still reproduces in a native alphaTab testbed, without Maestro’s custom cursor involved.

Environment:

• Testbed: LouisLam / ItsMyTabs native alphaTab player
• Browser: Chrome on macOS
• Packages:
  • @coderline/alphatab: 1.8.3
  • @coderline/alphatab-vite: 1.8.3
• Playback speed: slow practice speed, same as previous 1.8.1 baseline
• Song/passage: SRV / Pride and Joy, opening shuffle / slide region
• Probe: read-only DevTools probe watching playerPositionChanged, activeBeatsChanged, currentTick, and native .at-cursor-beat transform X

1.8.1 baseline:

• eventCount: 1496
• regressionCount: 2
• currentTick and currentTime were monotonic during both visible jumps
• native cursor X jumped sharply:
  • tick 612 → 613, X 122.752 → 164.617, delta +41.865
  • tick 1448 → 1449, X 156.831 → 214.569, delta +57.738
• currentTickMovedBackwardWhileTimeForward stayed false
• nativeCursorSharpMoveWhileTimeForward was true

1.8.3 comparison:

• eventCount: 1584
• regressionCount: 2
• activeBeatsChanged attached, but active beat identity remains coarse:
  • primaryBeatAbsStart: 0
  • primaryBeatPlaybackStart: 0
  • primaryBeatPlaybackDuration: 3840
  • primaryBeatDuration: 1
  • primaryBeatNotesCount: 0
• The visual failure changed shape:
  • tick ~607: native cursor X = 122.752
  • tick ~642: native cursor X = 155.824
  • tick ~1444: native cursor X is still 155.824
• Visually, this appears as the native cursor parking/holding on the slide/shuffle region before the later transition.

Conclusion:
#2702 changed the behavior, but did not resolve the issue.

In 1.8.1, native alphaTab cursor behavior showed discrete sharp forward jumps in SRV/Pride and Joy shuffle playback.

In 1.8.3, the issue is worse: the native cursor appears to park/hop from anchor to anchor across playback. currentTime and currentTick remain monotonic, but native cursor X stays frozen over many ticks and then jumps to a new visual anchor.

This suggests the remaining bug is not playback clock reversal. It is native cursor visual-anchor lookup/interpolation in swung/shuffle passages.

Additional 1.8.3 evidence:

A longer 1.8.3 run through the opening M1 region produced: (As was just captured in the video evidence that was just recorded)

• eventCount: 19292
• sampleCount: 19292
• regressionCount: 81
• activeBeatsAttached: true
• activeBeatsEventCount: 104

This is materially worse than the 1.8.1 baseline, which produced only 2 native cursor sharp-move regressions.

Observed behavior:

• The native cursor no longer glides smoothly.
• It parks/holds on discrete X anchors while currentTime/currentTick continue forward.
• It then hops to later note/anchor positions.
• Video confirms visible note-to-note stepping throughout playback.

Probe pattern:

• currentTime advances normally
• currentTick advances normally
• isSeek is false during playback samples
• nativeBeatXParsed remains frozen across many samples
• then jumps to a new X anchor

activeBeatsChanged also appears too coarse for this passage:

• activeBeatSamples repeatedly report primaryBeatAbsStart values like 0, 3840, 7680, 11520
• primaryBeatPlaybackStart remains 0
• primaryBeatDuration remains 1
• primaryBeatNotesCount remains 0

Further Conclusion:
The 1.8.3 swing lookup patch appears to have changed the failure mode from sharp cursor jumps to widespread cursor parking/note-hopping. The issue remains native alphaTab cursor visual-anchor lookup/interpolation, not Maestro custom cursor logic.

Will Attach YouTube video here: Or with the compact