Feature request: Official setting/API to disable loop highlight when Loop is OFF

[AvaTheArchitect]

Request (TL;DR)

Please add an optional setting/API to control loop-range overlay visibility independently from user interaction—so host apps can hide the range highlight when Loop is OFF.

Design intent / Request:

•	We understand the current behavior may be intentional (treating the range as a persistent “selection state,” not strictly a “loop-on” indicator).
•	The request is not to change the default for everyone, but to add an optional setting/API so host apps can choose the UX model that fits their product:
•	Some apps treat “Loop OFF” = “no loop is active”, and a persistent highlight reads like the loop is still engaged.
•	Others may prefer the current behavior where the range remains visible as a selection.
•	Providing a toggle gives integrators control without disabling user interaction, and reduces support issues (“Loop won’t turn off”, “range is stuck”) for products that follow the “no highlight when off” model.

Desired behavior (optional mode):

•	When Loop is OFF, the score should not display the loop-range overlay/highlight.
•	(Optional but ideal) When Loop is OFF, drag-selection should not create/retain a loop range, unless Loop is explicitly enabled (or the host opts into “persistent selection” behavior).

Requested API / setting
Primary suggestion (one setting with clear modes):

•	settings.player.loopRangeOverlayMode = 'always' | 'onWhenLoopEnabled' | 'off'

Acceptable alternatives:

•	settings.player.showLoopRange = false (illustrative name)
•	api.setLoopRangeOverlayVisible(false) when loopEnabled === false

Why:

•	“Loop OFF” is a clear mental model: no loop is active. A persistent highlight contradicts that model because the score still appears to have an active loop range.
•	In practice this leads to end-user bug reports (“Loop won’t turn off”, “range is stuck”, “playback is broken”) even when playback behavior is correct / designed this way today.
•	Competing tab players (Songsterr / Ultimate Guitar) treat loop highlighting as an active-loop affordance, not a persistent selection state. Adding an option would reduce confusion and support volume.

The Current workaround and why it’s costly:

Today, the only reliable way we’ve found to prevent the persistent loop highlight is to fully disable AlphaTab’s built-in interaction:
• settings.player.enableUserInteraction = false (custom interaction only)

That workaround has real downsides for host apps:
• We lose native interaction behaviors (selection, built-in seek semantics, etc.) and must re-implement them.
• Re-implementing click/seek correctly is non-trivial in real-world GP files:
• repeat passes (structural tick vs expanded tick)
• shuffle/swing passages (beat identity vs visual mapping)
• stale playerPositionChanged bursts after seeks
• edge cases like whole rests / sparse tickCache probing
• This increases integration complexity and bug surface area. In other words, a “loop highlight off when Loop is off” option would avoid forcing apps to disable interaction entirely just to get the desired UX.

If AlphaTab intends the highlight to remain as a persistent “selection,” can we get an official setting to control overlay visibility independently of enableUserInteraction?

This is why we’re requesting a loop-overlay mode option: it solves the UX problem without requiring integrators to disable user interaction and rebuild click-to-seek, repeat-aware tick mapping, and selection logic.

Final thought:

•	Even if the current behavior is by design, an opt-in setting lets apps choose between “persistent range selection” and “loop-only highlight”, matching how many tab players communicate loop state.

(Happy to adapt naming to match AlphaTab conventions.)

“Video: (shows: Loop OFF still displays highlight; expected: no highlight)”

https://youtu.be/1bUrseq3UN0

[Danielku15]

Its unlikel that I will add this to alphaTab. I dont want to intertwine two independent usable features with multiple modes that have to ve maintained and tested.

But I could think of alternative ways to allow easier ways of achieving a specific behaviour in your app integration.

Variant A: splitup enableUserInteraction

alphaTab has currently two interactivity features built in: range selection and click-to-seek. Both controlled with a single flag.

If we splitup this into two settings you can easily disable selection depending on your app state (e.g. looping off).

This shifts complexity out of the alphaTab core into the app specific integration side.

Variant B: extend selection handlers

Alternatively I could imagine that custom selection handlers could have the responsibility to decide whether selection is allowed. A separate flag/callback could decide whether selection is allowed.

In your app you can tie this to the looping state.

Existing alternatives/workarounds

Workaround A

Ser enableUserInteraction to false when looping is off to disable selection. Then listen on click events and implement click-to-seek in your code by taking alphaTab as reference how to do it (lookup beat by coordinate+lookup tick in ticklookup+ set tickposition).

Workaround B

Not tested, but I think you could capture mouse events on the alphaTab container while tunneling and disable propagation depending on your app state. Its likely a bit more tricky to only get selection disabled via such an event filter but technically possible and isolated.

Workaround C (closest to some other apps)

Listen to playbackRangeChanged and auto enable/disable looping based on whether a range is set. This is IMO clearest to users if you want to enforce your logic in the app. As a user it would bother me to enable first looping to be able to select a range (not intuitive).

[AvaTheArchitect]

Thanks for the quick reply — that makes sense, and I agree avoiding a multi-mode “loop overlay” feature in core is reasonable. Variant A (split up enableUserInteraction) would be the best win-win for us and, I think, for integrators in general. Right now enableUserInteraction gates two independent behaviors: 1. range selection (dragging/creating a playbackRange + showing the overlay) 2. click-to-seek In our product, we want click-to-seek to be always available, but we only want range selection when Loop is explicitly enabled in our UI. With the current single flag, the only reliable way we’ve found to prevent the persistent range highlight is disabling all user interaction — and then we’re forced to re-implement click-to-seek + edge cases ourselves (repeat passes / expanded tick mapping, shuffle/swing, post-seek stale events, etc.), which is a lot of integration complexity for what is essentially “disable selection when Loop is off.” Would you consider splitting this into two settings, e.g. something along the lines of: - settings.player.enableRangeSelection (or enableSelection) - settings.player.enableClickToSeek (or enableSeekOnClick) Desired behavior would be: - Loop OFF: selection disabled, click-to-seek enabled - Loop ON: selection enabled, click-to-seek enabled This keeps the features independent (no loop/selection coupling in core), but gives host apps a clean way to match their UX without disabling interaction entirely. If you’d prefer Variant B (a selection handler callback/flag that can veto selection based on app state), we can work with that too — but the split flags feel simplest to document, test, and adopt. Happy to align on naming and/or help test a PR if that’s useful. Thanks again!

…

On Mon, Apr 13, 2026, at 10:39 PM Daniel Kuschny ***@***.***> wrote: Its unlikel that I will add this to alphaTab. I dont want to intertwine two independent usable features with multiple modes that have to ve maintained and tested. But I could think of alternative ways to allow easier ways of achieving a specific behaviour in your app integration. Variant A: splitup enableUserInteraction alphaTab has currently two interactivity features built in: range selection and click-to-seek. Both controlled with a single flag. If we splitup this into two settings you can easily disable selection depending on your app state (e.g. looping off). This shifts complexity out of the alphaTab core into the app specific integration side. Variant B: extend selection handlers Alternatively I could imagine that custom selection handlers could have the responsibility to decide whether selection is allowed. A separate flag/callback could decide whether selection is allowed. In your app you can tie this to the looping state. Existing alternatives/workarounds Workaround A Ser enableUserInteraction to false when looping is off to disable selection. Then listen on click events and implement click-to-seek in your code by taking alphaTab as reference how to do it (lookup beat by coordinate+lookup tick in ticklookup+ set tickposition). Workaround B Not tested, but I think you could capture mouse events on the alphaTab container while tunneling and disable propagation depending on your app state. Its likely a bit more tricky to only get selection disabled via such an event filter but technically possible and isolated. — Reply to this email directly, view it on GitHub <#2658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BNLESQGBGHZCMZBYEWJBGYT4VXFILAVCNFSM6AAAAACXYE6WSWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNJVGIZDMMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[AvaTheArchitect]

To confirm, we’re not asking for an additional loop/selection mode or toggle-like button; we’re asking to split one bundled interaction flag into two independent settings so host apps can disable selection while keeping click-to-seek enabled. While disabling the native cursor is not the same thing, the principle of the idea is similar.

…

On Mon, Apr 13, 2026 at 10:39 PM Daniel Kuschny ***@***.***> wrote: Its unlikel that I will add this to alphaTab. I dont want to intertwine two independent usable features with multiple modes that have to ve maintained and tested. But I could think of alternative ways to allow easier ways of achieving a specific behaviour in your app integration. Variant A: splitup enableUserInteraction alphaTab has currently two interactivity features built in: range selection and click-to-seek. Both controlled with a single flag. If we splitup this into two settings you can easily disable selection depending on your app state (e.g. looping off). This shifts complexity out of the alphaTab core into the app specific integration side. Variant B: extend selection handlers Alternatively I could imagine that custom selection handlers could have the responsibility to decide whether selection is allowed. A separate flag/callback could decide whether selection is allowed. In your app you can tie this to the looping state. Existing alternatives/workarounds Workaround A Ser enableUserInteraction to false when looping is off to disable selection. Then listen on click events and implement click-to-seek in your code by taking alphaTab as reference how to do it (lookup beat by coordinate+lookup tick in ticklookup+ set tickposition). Workaround B Not tested, but I think you could capture mouse events on the alphaTab container while tunneling and disable propagation depending on your app state. Its likely a bit more tricky to only get selection disabled via such an event filter but technically possible and isolated. — Reply to this email directly, view it on GitHub <#2658 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BNLESQGBGHZCMZBYEWJBGYT4VXFILAVCNFSM6AAAAACXYE6WSWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNJVGIZDMMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>