When enableAnimatedBeatCursor=false, some section pointers may skip some notes

[Code-Lonely]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I set enableAnimatedBeatCursor to false，Playing normally to the fourth section of a. gp file, the cursor will skip some notes.
I am currently using version 1.2.3, and I have found that this situation does not occur in version 1.2.1

Expected Behavior

The cursor should pass through all notes

Steps To Reproduce

<style>
        .at-wrap {
            width: 80vw;
            height: 80vh;
            margin: 0 auto;
            border: 1px solid rgba(0, 0, 0, 0.12);
            display: flex;
            flex-direction: column;
            overflow: hidden;
            position: relative;
        }
        .at-content {
            position: relative;
            overflow: hidden;
            flex: 1 1 auto;
        }
        .at-viewport {
            overflow-y: auto;
            position: absolute;
            top: 0;
            left: 70px;
            right: 0;
            bottom: 0;
            padding-right: 20px;
        }
        .at-cursor-beat {
            /* Defines the beat cursor */
            background: rgba(64, 64, 255, 0.75);
            width: 3px;
            /*background-color: rgba(6, 191, 253, 0.56);*/
        }
        .at-cursor-bar {
            /* Defines the color of the bar background when a bar is played */
            background: rgba(255, 242, 0, 0.25);
        }
        .at-selection div {
            /* Defines the color of the selection background */
            background: rgba(64, 64, 255, 0.1);
        }
    </style>
<div class="at-main"></div>

let scoreElement = document.querySelector(".at-main");
        const settings = {
            file: "123.gp",
            // tracks: [0],
            // tracks: [4],
            fontDirectory: 'font/',
            tracks: 'all',
            display: {
                layoutMode: 0,
                stretchForce: 1.5,
                staveProfile: 3,
                scale: 1.0
            },
            player: {
                // bufferTimeInMilliseconds: 1000,
                enablePlayer: true,
                enableCursor: true,
                enableElementHighlighting: true,
                enableAnimatedBeatCursor: false,
                soundFont: 'https://cdn.jsdelivr.net/npm/@coderline/alphatab@latest/dist/soundfont/sonivox.sf2',
                // soundFont: 'sonivox2.sf2',
                // scrollElement: document.querySelector(".at-viewport")
            }
        }
        const api = new alphaTab.AlphaTabApi(scoreElement, settings);
        api.isLooping = true
        api.playerReady.on(() => {
            console.log("playerReady====", api.score.tracks)
            api.play();
        });

Link to jsFiddle, CodePen, Project

No response

Found in Version

Other

Platform

Web

Environment

- **OS**:Macos
- **Browser**:Chrome 117.0.5938.149
- **alphaTab Version**: 1.2.3

Anything else?

No response

[Code-Lonely]

123.gp.zip
This is my file

[Code-Lonely]

Geek.2023-10-10.09.20.33.mp4

[Danielku15]

Thanks for reporting this. I will look into this soon. Have you checked already if this problem still occurs in 1.3? I remember touching the area around the cursor placement.

[Code-Lonely]

Yes, I have checked and the issue also exists on 1.3.0

[Code-Lonely]

Could you please repair it as soon as possible

[Code-Lonely]

@Danielku15

[Code-Lonely]

@Danielku15 Hello, may I ask when you can fix this bug? Thank you very much

[Danielku15]

I will write here when I had time to start on this bug and fixed it, no commitments. It's done when it's done.

[Code-Lonely]

I also found an issue where when I tried to change the timePosition attribute, the cursor did not reach the specified position, which should be the same as the above issue

[Danielku15]

The problem seems more general, the enableAnimatedBeatCursor just makes it more visible that the cursor movement and element highlgihting is not really accurate.

I minimized the file to show the problem on a small scale. Also on a single-track display we can clearly see that the highlighting is wrong. Also the grace notes are not the cause.

chrome_6F5vtBG9Cp.mp4

Seems the MidiTickLookup is handling some aspects wrong on the findBeatFast path. When only using findBeatSlow beats are updated correctly. Just sometimes the cursor jumps back to the grace notes hinting potentially to some miscalculations on there too.

123-small.zip