Playback selection UX: keep the paused cursor independent until Play

[sgabenov]

Note

AI-authored disclosure (alphatab-ai-authored-v1)

Portions of this content were authored by an AI agent. The agent has read
AGENTS.md and the human submitter accepts responsibility for
compliance with the rules in that document.

Is there an existing issue for this?

• I have searched the existing issues.

I have read the contribution rules

• I have read CONTRIBUTING.md and AGENTS.md.

AI authorship

AI-assisted (disclosure block included as described in AGENTS.md).

Current Behavior

Please check a video attached to the issue at hte end of the page! (...a human submitter %)...)

In the Control playground, with playback paused at a note, starting a drag selection moves the playback cursor to the first selected note. Editing the range therefore changes the stopped playback position before pressing Play.

The existing selection boundaries can be adjusted using handles. I would like the selectable boundary to be clearer when hovering over its vertical edge.

This is a request to discuss the playground interaction, rather than a claim that playback ranges and looping should be coupled. I understand the intended independent behavior explained in #2575. The earlier handle-alignment issue #2863 was resolved by #2886; this request concerns subsequent interaction and presentation.

Expected Behavior

My goal is to make selecting a practice passage and following playback feel calmer and more predictable. alphaTab already supports adjusting playback ranges; these are the interaction and presentation changes I tried locally, and I would appreciate your thoughts on whether they would be useful in the playground.

• A quieter selection background. I reduced the selection fill because a strong tint competed with the notation and the playback highlight while reading the score. The selected passage remains identifiable through a light fill and a thin blue outline. The active bar uses a lighter version of the original yellow, so editing a range and following playback have distinct visual cues.
• Different heights for the selection and active-bar highlight. The selection frame covers the complete visual height of the system, including markings and both notation and TAB when present. The playing-bar background follows the staff bounds. Keeping these different extents makes their roles easier to distinguish and reduces the sense of overlapping highlights.
• A more readable playback cursor. I used a 2 px orange line that extends above and below the notation, and placed it behind the note glyphs. I also turned off individual played-note colouring in the example. The aim is to make the position easy to find without covering or recolouring the note being read.
• More discoverable boundary editing. The frame has a thin perimeter and no circular handles. Hovering a left or right edge makes that edge thicker and changes the pointer to a horizontal resize cursor. Either edge can be dragged independently to a note boundary, with a forgiving hit area. This gives a visible indication of where and how to adjust the passage.
• Selection editing leaves the paused position alone. Creating a selection or moving its boundaries does not move the stopped playback cursor. Only pressing Play moves it to the selection start and plays the selected range. Loop remains independent. To me, this makes it easier to adjust a practice passage without losing the place where I paused.
• Less visual competition while playing. Once Play is pressed, the selection's editing frame hides and the active bar and playback cursor remain visible. Pausing restores the frame so the passage can be adjusted again.
• Predictable end of a drag. Releasing the pointer outside the score or cancelling the gesture ends the edit. Boundary edits also preserve the chosen occurrence of a repeated passage rather than unexpectedly switching to another repeat.

The videos below show these behaviours on a notation-only instrument and on an instrument with notation and TAB. They show the local prototype, not the current upstream behaviour. The compact player's controls and layout are only a demonstration harness and are outside the proposed contribution.

These are personal usability preferences from practising with the example. I would be happy to adapt the direction to fit alphaTab's intended interaction model, including keeping it as an optional playground behaviour if that makes more sense.

Steps To Reproduce

1. Run the playground from develop and open /demos/control/.
2. Use the bundled test-data/audio/full-song.gp5 score and the first track, Anette voice.
3. Wait for playback controls to become available; click a note in bar 6 to place the paused cursor.
4. Drag from an earlier note in bar 6 into bar 7, then release.
5. Observe that the stopped cursor moves to the beginning of the selection before Play has been pressed.
6. For the desired notation + TAB interaction, use the fourth track, Emmpu(Acoustic), in the same score.

Link to jsFiddle, CodePen, Project

alphaTab playground and bundled score

Personal-fork review PR and demonstration context. Player controls and layout are outside this proposal; this PR is provided for inspection while upstream scope is discussed.

Version and Environment

Reproduction used the unmodified Control playground files from upstream develop, commit 25ef76d38b482b1cf9959cdfc6fcddfd5cb5b76a, and the locally generated alphaTab engine. The following is actual debug output; its commit/date are the generated engine's build metadata, not the upstream playground revision.

[AlphaTab][VersionInfo] alphaTab 1.9.0
[AlphaTab][VersionInfo] commit: bf3fc48f53d899ccb60454385001787132e04eca
[AlphaTab][VersionInfo] build date: 2026-10-07T08:47:05.171Z
[AlphaTab][VersionInfo] High DPI: 2
[AlphaTab][VersionInfo] Platform: BrowserModule
[AlphaTab][VersionInfo] WebPack: false
[AlphaTab][VersionInfo] Vite: false
[AlphaTab][VersionInfo] Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36
[AlphaTab][VersionInfo] Window Size: 3440x1232
[AlphaTab][VersionInfo] Screen Size: 1800x1169

Platform

Web

Anything else?

The human submitter has reviewed and approved the demonstration videos:

Notation only — first instrument (Anette voice)

notation-only.mp4

Notation + TAB — fourth instrument (Emmpu(Acoustic))

notation-and-tab.mp4

Original upstream Control after dragging a selection

The demonstration videos contain a temporary resize-pointer indicator because browser capture does not reproduce the native resize pointer accurately. Boundary-drag portions are slowed 6x and labelled accordingly. The recording aid is absent from the proposed contribution.

The compact example is only the demonstration harness. Its player controls, layout and styling are outside the intended contribution.

[Danielku15]

This is getting ridculous, you cannot ask your AI to dump truckloads of bug reports to this project. Please keep your bug reports at a reasonable and manageable level. Report bugs so that they make sense for the alphaTab project. you cannot just ask your AI to escalate all items to me. I am not willing to assist fleets of AI agents bombarding me with requests for this project.

[sgabenov]

@Danielku15 sorry for that, as i was doing some work of omr translations into musicxml format and then used your library as a guitar pro exporter. during the pipeline of translations of several books for hundred of pages thete were found some errors in exporting and i asked agent to create a bug report for that. i thought that i could create a PR for that bugs, but you do not apply them withoup issues. anyway don, t want to bug you and wanted to help with development.
if you don't mind, please look at this exect issue, it is done for ui better view and i spend hours to make it look mote easy to read and fixed some behavior on selection. i have provided a video recording for the changes. please check once again, as it is not an llm auto-created issue

[Danielku15]

Overall on your reported issues it rather felt like an AI spam flood. Most descriptions where focusing a lot on your specific usage, hardly any issue described things against alphaTab semantically.

I need to dig into each and every reported item for triage. I want to understand the problem before just dropping in bugfixes for things not even clearly known if its a problem. AIs hallucinate and users might have personal expectations which do not fit the design of alphaTab or format specifications like MusicXML. The bug reports hardly describe what's going on from an alphaTab perspective, they purely describe some external outcome in your test environment for a very specific case.

e.g. #2922 the current behaviour doesn't make sense much as standalone. It doesn't describe at all what you are even trying to achieve.

Don't get me wrong, I appreciate any contribution and reports which fix problems in alphaTab and improve it, but they really have to come in a form that are manageable and make sense for the project. alphaTab is mostly my personal hobby project with some individual contributors passing by and I do this fully in my spare time. There is no big team or company behind this.

In situations like this it might be better to build up a general test-bench in a repository and share it. Then report one issue (or discussion) against the project with the outcome report. We don't need always a strict 1:1 mapping of a problem to a PR, its fine to have some "umbrella" issues addressing multiple improvements at once around a problem domain.