AlphaTab note gaps vs. empty-bar ballooning #2679
AvaTheArchitect
started this conversation in
General
Replies: 9 comments 4 replies
-
|
I think the supported model here is a little different from Songsterr-style density packing. From the current display settings:
So for your target layout, the supported path seems to be: use page layout + If you want to avoid writing a full row-packing engine, a narrow preprocessing pass in |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
This is actually very helpful and reveals some key pieces we were not aware
of and especially what stretchForce was intended for globally. Thanks so
for your help here definitely appreciate it!
…On Sat, Apr 25, 2026 at 9:12 PM T ***@***.***> wrote:
I think the supported model here is a little different from
Songsterr-style density packing.
From the current display settings:
- stretchForce is global spacing for the layout algorithm; I don't see
a supported way to apply it only to rest-only bars.
- barsPerRow/systemsLayout decide how many bars go into each system.
- when systemsLayoutMode is UseModelLayout, page layout uses
displayScale as a relative per-bar ratio. It does not use displayWidth
in page layout; displayWidth is for horizontal layout.
- For a single rendered track, the model layout is read from
score.tracks[index].systemsLayout and
score.tracks[index].staves[index].bars[index].displayScale; for
multiple rendered tracks it uses score.systemsLayout and
score.masterBars[index].displayScale.
So for your target layout, the supported path seems to be: use page layout
+ UseModelLayout, set row breaks with systemsLayout/defaultSystemsLayout,
and assign smaller displayScale values to empty bars and larger ones to
dense/lyric-heavy bars. That can compress empty bars relative to full bars,
but it is still a bar-level ratio system, not a note-spacing-only setting
or an automatic empty-bar compressor.
If you want to avoid writing a full row-packing engine, a narrow
preprocessing pass in scoreLoaded that classifies bars as empty/rest-only
vs dense and fills systemsLayout + displayScale is probably the closest
supported approach. I would not expect stretchForce alone to solve it
because it is designed to affect the notation spacing globally.
—
Reply to this email directly, view it on GitHub
<#2679 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BNLESQCURYURZ3GHNEUA66D4XWEBZAVCNFSM6AAAAACYGS2GCSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNZRGU4TSNI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
General behavioralphaTab does rhythmic spacing. Here a small excerpt of Behind Bars: 
The algorithm to do this, used by most music notation applications is an algorithm by Gourlay which uses "springs and rods". Rods are the elements placed in a bar/staff and springs are put in-between them to stretch them apart. If you squeeze the whole system, the relative spacing between the items stays the same. The Additionally we have options for the general layout:
The data model has some properties to contribute to these layouts like I'm not sure if you have Guitar Pro, if not, here a screenshot how they allow customization of the layout in the parchment mode: 
+/- allow you to change the number of bars in the system. There is also a separate alphaTab currently uses a logarithmic (log2) spacing formula. Meaning: a quarter-note is half the size of a half-note. The smallest duration in the bar/system defines how wide we should to stretch things so that we are condensed when possible and wider when needed. Generally songsterr is also having a "vertical scroll" layout. I think songsterr is also having rhythmic spacing, but their spacing formula is not logarithmic. This is quite visible in bars like this: 
Testing with the durations we can see they also have some sort of duration aligned spacing: 
Hope that helps understanding in how things work in general. Overall things are following rhythmic spacing where the duration defines the space taken. Individual customization is only allowed limited as it breaks the general principles (e.g. spacing bars with only a rest differently). For the available settings please read through the docs on our website and the tsdocs (d.ts) shipped with alphaTab. Some improvements in rhythmic spacing are upcoming as part of #2591 but beyond that there is nothing special planned to change. there could be potential for having more specialized configurations of the spacing formula to make things more condensed when possible. e.g. some factor configurations. If you want to enter this domain of optimization I can only recommend you: really look beyond the plate of Songster and look what generally the industry is doing and providing. Check the full bandwidth applications like MuseScore, Guitar Pro, Dorico, Capella, Finale + websites like Soundslice, Flat.io, Songsterr and look how they all do spacing and what features they might offer related to spacing. Further interesting references to read are:
TBH: It is rather frustrating for me to hear that often statements that boil down to "we are rebuilding/building a clone of Songsterr, allow us to replicate it 1:1". I am open to discuss concrete improvements based on problems and needs which align with the general principles of music notation. To your concrete points
This is in-line with rhytmic spacing und unlikely to change as you describe it (changing rest only different to bars with content).
This sounds rather strange and you are already in a state of "working around things" and now asking for "workarounds on top of workarounds". 115 bars in one system sounds unrealistic and rather like a bug we can focus on. If the 115 bars are completely empty (basically needing 0-space) we can think of how this situation can be tweaked.
Generally my advice for such setups is: use Then only rely on If there are concrete problems in such a setup, lets look at those specifically. If things are unexpectedly large or small we can troubleshoot the specific scenarios.
This is overly specific. Not sure how to answer this beside: no, you cannot set the spacing for a very specific time signature + content combination. We always use rhythmic spacing.
All settings are documented in the website, and deeper model aspects are documented in the TS Docs of the library. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Round 2: I did some further research on the topic and will explore some adaptions in the spacing algorithm. While we use Gourlay and it used to be the de-facto practice and theory behind music notation spacing, its classical formula is not established that commonly anymore. There are newer adaptions and improvements to this (keeping the spring-rod base algorithm but with adjustments to the spacing calculations). I've setup already some battle-plan for doing a spike covering 3 areas:
My question to you would be: Can you provide me a test data set of 5-10 files showing different constellations of spacing situations? This will allow me to optimize things based on your concrete findings, not just tackle some theoretical combinations. This is a very subjective matter, and the better info I have from your side, the better I can verify my changes bring an improvement. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi Daniel,
I put together a more structured set of notes and test cases. The goal is
not to clone Songsterr 1:1. I’m trying to isolate concrete readability
issues around spacing, system wrapping, lyrics, marker/tempo placement, and
technique/free-text collisions using real GP files.
I also compared several cases against Guitar Pro so the report separates
native alphaTab behavior from app-specific UI preferences. The main
recurring areas are viewport-dependent row spacing, overlay lane priority,
lyrics appearing above the staff, free-text/FX collisions, and inconsistent
P.H. display depending on the file. Now the real testing challenge was I
loaded the same GP files and more on Vite since it's very much a default
version of alphaTab whereas my Next.js webpack version has the forceStretch
that ballooned rest only bars while trying only to add spacing 2.3mm global
to the notation bars only.
I’ll continue adding labeled screenshots and GP files, but this should give
a clearer map of the issues I’m seeing.
https://github.com/AvaTheArchitect/louislam-borrowed-labs
*alphaTab Guitar Pro Spacing, Overlay, and Readability Test Notes.*
(Attached is a PDF copy of this for easy print out)
*Purpose: *
These notes document Guitar Pro tab-rendering issues observed in a
lightweight alphaTab/Vite test environment, with additional comparisons
against Guitar Pro and a separate Maestro.ai alphaTab implementation.
The goal is *not* to clone Songsterr 1:1. The goal is to identify concrete
spacing, wrapping, lyric, marker, tempo, and technique-overlay cases that
affect readability in a guitar-learning and practice interface.
The issues below include:
- Note spacing that becomes too tight in certain rows
- Empty/rest-measure spacing inconsistencies
- FX/free-text overlap
- Lyric overlap or crowding
- Marker/section-name collisions
- Tempo marker collisions
- Chord name, P.M., vibrato, let-ring, and technique-lane conflicts
- Differences between normal-window and full-screen rendering
- Possible file/model differences in how pinch harmonics are encoded or
displayed
For each screenshot/test case, I will label:
- Song
- Track number
- Normal window vs. full screen
- Browser/test environment
- Approximate viewport/container width when available
- Measure numbers where the issue is visible
The goal is to provide concrete reproducible cases rather than broad
statements about spacing.
⸻
*General Observations *
*1. Viewport-dependent spacing: *
Several layout issues become more visible when switching between normal
window and full-screen browser views. In some files, full screen creates
more horizontal room, but the vertical spacing between systems appears to
compress or change in a way that makes overlay collisions worse.
This is different from what I observed in Guitar Pro, where the spacing
between rows appears more stable between normal and full-screen views. For
example, in one Guitar Pro comparison around the Stairway to Heaven solo
section, row spacing stayed approximately the same in normal view and full
screen, while alphaTab/Vite changed more noticeably.
This is not necessarily “Guitar Pro is right and alphaTab is wrong,” but it
suggests that alphaTab’s vertical-scroll layout may recalculate system
spacing in a way that affects overlay readability when wrapping changes.
*2. Overlay lane priority: *
A recurring issue is that marker/section names, tempo markings, chord
names, P.M., let-ring, vibrato, free text, and lyrics do not always appear
to have predictable lane priority.
In practice, this can lead to:
- Section names colliding with chord names
- Tempo markings and section markers competing for the same vertical
space
- P.M. rails floating inconsistently
- FX/free-text comments overlapping with other notation text
- Lyrics appearing above the staff instead of below it
- Vibrato/technique markings losing lane consistency
A predictable vertical stacking model would help significantly.
*3. Note spacing vs. rest-bar spacing: *
The most difficult spacing issue is balancing readable note spacing with
compact rest-only bars.
Higher stretch/spacing can improve note readability in bars with actual
notation, but rest-only bars can become too wide. Lower spacing keeps empty
bars compact but can make dense note bars too tight.
Some rest-only bars also appear wider because of meter/duration content.
For example, in Queen “Bohemian Rhapsody,” rest-only bars in 12/8 or 6/8
with dotted rests appear naturally larger than simpler 4/4 rest-only bars.
That appears musically reasonable, but it contributes to the broader
spacing challenge.
*4. Guitar Pro comparison: *
Guitar Pro exposes several layout and notation controls that help with
readability, including:
- Tab-only view
- Wider horizontal spacing
- Chord/font sizing behavior
- More stable system spacing
- Section markers occupying stable vertical space
- System layout controls
- Pinch harmonic notation options discovery inside Guitar Pro
This suggests that some of the desired behavior is not merely a
Songsterr-style preference, but overlaps with standard professional
tab-layout controls.
⸻
*Test Files / Song Notes: *
*1. Van Halen — “Ain’t Talkin’ ’Bout Love” *
*Track 1 — Normal Screen*
- Lyrics appear above the staff rather than below it.
- Marker/section names appear elevated as a result of lyric placement.
*Track 1 — Full Screen*
- Lyric placement remains above the staff and becomes more crowded.
- Visible crowding/overlap around:
- M36: “you think you’re really cookin’”
- M66: “and looked down…”
- M128: tempo cluster = 60
- At M128, the tempo marker and “Half Time” appear to compete for
vertical priority.
*Track 3 — Full Screen*
- M1: section marker “Intro” collides or crowds with the
TAB/time-signature area.
- P.M. markings are not consistently anchored in a stable lane.
- FX/free-text and section markers appear to share the same vertical
lane in some places.
- M9: “Main Riff” overlaps or crowds with FX/comment text.
- Chord names appear displaced rather than anchored into a consistent
chord lane.
- M24: slide/picking text is tight.
- M25: P.M. alignment is inconsistent and collides with the “Chorus”
marker.
*Track 3 — Normal Screen*
- Similar to full screen.
- Several rows are vertically tight, causing overlay/marker collisions.
⸻
*2. Warrant — “Uncle Tom’s Cabin” *
*Track 3 — Normal Screen*
- Note spacing is tight in some areas, approximately .3cm–.4cm.
- Row spacing is also tight.
- P.M. markings are not consistently anchored in a stable lane.
- Visible around:
- M39
- M68
- Vibrato markings also lose lane consistency in some locations.
*Track 3 — Full Screen*
- Similar to normal screen.
- Tight spacing remains between rows.
- Same general P.M. and vibrato lane issues.
*Track 1 — Full Screen*
- Row spacing remains tight.
- Interesting contrast: note spacing appears better on this track than
Track 3, even with similar note patterns.
- Some notes appear closer to .6cm–.7cm, which is more readable.
- Raised vibrato and P.M. markings still do not consistently sit in a
stable lane.
*Note*
It is not yet clear why similar note patterns are spaced better on Track 1
than on the guitar track. This may be due to track content, source-file
encoding, or row-layout differences.
⸻
*3. Guns N’ Roses — “Welcome to the Jungle” *
*Track 1 — Normal Screen*
- Lyrics appear above the staff instead of below it.
- Lyrics overlap or crowd around:
- M26
- M29
- M36
- M41
*Track 1 — Full Screen*
- Mostly the same as normal screen.
*Track 3 — Full Screen*
- M1: “Intro” overlaps with P.M. / technique placement.
- Tight spacing between rows.
- Note spacing is tight.
*Track 3 — Normal Screen*
- Similar issues as full screen.
⸻
*4. Guns N’ Roses — “Sweet Child O’ Mine” *
*Track 5 — Normal Screen*
- Tight note spacing.
- Significant overlap above bars involving:
- chord names
- P.M. rails
- marker/section names
- Especially visible around:
- M176
- M177
- Note spacing may not be the primary issue here; overlay lane placement
appears more significant.
*Track 5 — Full Screen*
- Similar to normal screen, possibly worse around:
- M130
- M146
- M176
- M177
*Track 1 — Full Screen*
- Lyrics appear above the staff.
- Rows are tight.
- Lyrics overlap or lack vertical spacing around:
- M36
- M42
- M65
- Vibrato appears displaced.
*Track 1 — Normal Screen*
- Overlap visible around:
- M25
- M57
*Track 4 — Normal Screen*
- Overlap visible around:
- M41
- M176
- M177
⸻
*5. Van Halen — “Eruption” *
*Track 1 — Full Screen*
- Full screen appears worse than normal screen.
- Row 1 is crowded.
- “Intro” appears to occupy vertical space, but other overlay lanes then
collide around it.
- Chord names are not consistently anchored.
- M12: visible overlap.
- Note spacing is tight, but the main issue appears to be overlay lane
placement.
*Track 1 — Normal Screen*
- Normal screen appears better than full screen.
- Row 1 has fewer overlapping/misalignment issues.
- Some overlay lane anchoring issues remain.
- Chord names are displaced.
⸻
*6. Stevie Ray Vaughan — “Pride and Joy” *
*Track 2 — Normal Screen*
- Very tight note spacing in several areas, especially around:
- M4
- M15
- M39
- M48
- M52
- M53
- M57
- M59
*Track 1 — Full Screen*
- Lyrics appear above the staff.
- Overlay lanes are off.
- Lyrics overlap around:
- M16
- M17
- M25
- M26
- M30
- M31
- M41
- M43
- M76
*Track 1 — Normal Screen*
- Mostly the same as full screen.
⸻
*7. Extreme — “Rise” *
*Track 1 — Normal Screen*
- This is one of the first files where pinch harmonic labels appear
visibly in alphaTab.
- P.H. appears above:
- M8
- M24
- M48
- M139
- In some locations, the file may show both A.H. and P.H.-style
behavior. Since the examples involve bends, they are likely intended as
P.H.; this may be source-file/tab-authoring related.
- Note spacing is acceptable at the beginning but becomes more
challenged later in solo sections.
- Overlap visible around:
- M65
- M101
- M117
- M119
- M122
- M125
*Track 1 — Full Screen*
- Row spacing appears to decrease in full screen.
- Overlap becomes more visible around:
- M65
- M101
- M117 and onward
⸻
*8. Led Zeppelin — “Stairway to Heaven” *
*Guitar Pro Reference Notes*
Guitar Pro allows standard notation and tablature to be toggled from:
*View → Inspector → Track → View Options → Standard / Tab*
This made it possible to compare tab-only spacing more directly.
Initial comparison suggests Guitar Pro keeps row spacing more consistent
between normal view and full screen. Around the guitar solo section near
M118, Guitar Pro showed approximately *3.9cm* of row spacing in both normal
view and full screen.
By comparison, alphaTab/Vite changed more noticeably. Around M118:
- alphaTab/Vite full screen: approximately 3.0cm
- alphaTab/Vite normal screen: approximately 2.6cm
*Track 2 — Full Screen*
Observed issues:
- Bar-number / alignment issues with section names and chord names
around:
- M1
- M41
- M49
- M109
- With DevTools open, collisions are more visible around these measures.
- With DevTools closed, similar issues remain around:
- M1
- M41
- M138
- M156
- Chord names are not consistently anchored into a stable overlay lane
above the staff.
*Track 2 — Normal Screen*
- Similar issues as full screen.
- Chord names still do not consistently anchor into a stable overlay
lane above the staff.
*Track 1 — Vocals — Normal Screen*
- Lyrics appear above the staff instead of in a lower lyric row.
- This matches the lyric-placement issue seen in several other songs.
*Track 1 — Vocals — Full Screen*
- Full screen does not appear to give lyrics more usable spacing.
- Vertical overhead between rows is reduced, making the layout feel
tighter rather than more readable.
*Track 4 — Electric Guitar Clean — Full Screen*
Row spacing is compromised in several areas, especially around:
- M41
- M49
- M66
- M100
- M109
- M110
- M118
- M138
- M156
*Track 4 — Electric Guitar Clean — Normal Screen*
- Similar issues as full screen.
- Row spacing has slightly more cushion in some places, approximately
0.2cm–0.3cm more, but not consistently.
- Around M118, alphaTab/Vite measured approximately:
- Full screen: 3.0cm
- Normal screen: 2.6cm
*Guitar Pro Comparison*
Guitar Pro appears to keep row spacing fixed between normal and full screen:
- M118 area:
- Guitar Pro normal view: approximately 3.9cm
- Guitar Pro full screen: approximately 3.9cm
This suggests Guitar Pro is preserving a more stable page/engraving layout
across viewport changes, while alphaTab/Vite’s vertical-scroll layout
responds more dynamically to available width.
⸻
*9. Metallica — “One” *
*Track 4 — Distortion Guitar — Normal Screen*
- Row spacing issues around:
- M115
- M149
- M173
- M209
- M237
- Note spacing is also tight, especially in sections with heavy tapping.
*Track 4 — Full Screen*
- Some spacing stayed the same; for example, M149 stayed around 3.0cm.
- M209 changed more noticeably:
- Normal screen: approximately 2.2cm
- Full screen: approximately 2.8cm
- Overlay lane placement did not appear to improve even when more row
spacing became available.
⸻
*10. Night Ranger — “Sister Christian” *
*Track 1 — Overdriven Guitar — Full Screen*
- Overlay lane spacing issue throughout.
- Approximate row spacing observed: 1.6cm.
*Track 1 — Normal Screen*
- Spacing is even tighter, approximately 1.1cm.
- There is very little room above the staff for overlay lanes.
*Track 2 — Distortion Guitar — Normal Screen*
- Tight row spacing.
- Note spacing becomes an issue with bend annotations around:
- M71
- M76
*Track 2 — Full Screen*
- Little to no improvement observed.
⸻
*11. Ozzy Osbourne — “Crazy Train” *
*Track 3 — Distortion Guitar — Normal View*
- Row 2 overlapping.
- Row 3 cramped spacing.
- Chord names are not anchored in a stable lane.
- M36 is very tight for the pick slide; similar issue appears around
M136.
- Free text/comment overlap around:
- M39
- M43
- M73
- M95
- M139
- M107: P.M. and rails are displaced.
*Track 3 — Full Screen*
- M11 overlapping.
- Tight spacing between rows.
- Additional overlap around:
- M39
- M53
- M95
*Track 1 — Vocals — Full Screen*
- Lyrics are very high above the staff.
- In Guitar Pro, the lyrics open under the staff instead of above it,
although both options appear to exist in Guitar Pro’s stylesheet/settings
menus.
*Track 1 — Normal Screen*
- Mostly the same.
⸻
*12. Queen — “Bohemian Rhapsody” *
*Track 3 — Electric Guitar Clean — Normal View*
- Tempo markings/clusters have inconsistent placement.
- Some are anchored lower and correctly, while others appear very high.
- Examples:
- M66–M84: tempo markers appear more correctly anchored
- M55–M65: tempo markers appear too high
- Tight note spacing around M48.
- M41 appears to have a whole rest and fret note 20 in the same spot.
- M41 also shows a whole rest and sustained (15).
- M42 has both a whole rest and fret 20 on high E string, which seems
contradictory unless this is a multi-voice/source-model issue.
*Track 3 — Full Screen*
- Pretty much the same as normal view.
*Additional Rest-Bar Observation*
This file also shows that rest-only bars in different meters behave
differently. For example, 12/8 or 6/8 rest-only bars with dotted rests
appear wider than simpler 4/4 rest-only bars. This may be musically
expected, but it is useful when evaluating rest-measure spacing.
⸻
*Pinch Harmonic / Artificial Harmonic Notes*
A separate area worth testing is P.H. / A.H. display consistency.
In Guitar Pro 7, the Artificial Harmonic dialog allows selecting:
- Artificial
- Pinch
- Tap
- Semi
- Feedback
When “Pinch” is selected, Guitar Pro displays a P.H. marking and rail above
the note. I tested this manually in Van Halen “Ain’t Talkin’ ’Bout Love” as
a demonstration, even though that specific note may not musically require a
pinch harmonic.
This confirms that the Guitar Pro file/model can represent P.H.-style
notation directly. The inconsistency may come from:
- How different GP files encode harmonics
- Whether the file uses A.H. vs P.H.
- Whether the importer maps the harmonic type correctly
- Whether alphaTab chooses to display or suppress the label in specific
cases
This should be tested with files where Guitar Pro clearly displays P.H. and
alphaTab either displays it or does not.
⸻
*Main Issue Categories*
*Category A — alphaTab rendering/collision issues*
These are the areas that seem most appropriate to investigate in alphaTab:
- Free Text / FX comments overlapping other notation text
- Lyrics appearing above the staff when Guitar Pro places them below
- Marker names colliding with chord names or tempo markers
- P.M., let-ring, vibrato, and technique-lane conflicts
- P.H. missing when Guitar Pro displays it
- Viewport-dependent row spacing reducing overlay readability
- Tempo markers/clusters appearing inconsistently high or low
- Lack of predictable lane priority between marker, tempo, chord, lyric,
and technique elements
*Category B — Product/UI customization*
These may be more application-specific and not necessarily alphaTab bugs:
- Moving bar numbers left like Songsterr
- Custom max-width reading column for widescreen displays
- Custom CSS shell for desktop/widescreen reading comfort
- Custom overlay lane system on top of alphaTab
- Custom visual styling to match a learning/practice interface
⸻
*Questions / Areas Where Guidance Would Help*
*1. Recommended native setup*
For a vertical-scroll guitar-learning interface, what is the recommended
native alphaTab setup for:
- readable note spacing,
- compact rest-only bars,
- stable row spacing,
- and predictable overlay placement?
Should this generally be:
- Page layout with Automatic systems layout,
- Page layout with UseModelLayout,
- Parchment layout,
- or another setup?
*2. Overlay collision handling*
Is there currently a supported way to define or influence priority between:
- section markers,
- tempo markings,
- chord names,
- lyrics,
- P.M.,
- let ring,
- vibrato,
- and free text?
If not, would better collision/lane handling be a reasonable feature
request?
*3. Lyrics lane*
For files where Guitar Pro displays lyrics below the staff, is alphaTab
expected to display them below as well? If alphaTab shows them above, is
that likely:
- file-model related,
- notation settings related,
- or a rendering/layout issue?
*4. Free Text / FX comments*
Free Text / FX comments are one of the hardest cases. In Guitar Pro, Free
Text can be attached to notes, but I have not found a per-object vertical
lane or offset control. In alphaTab, these FX comments can collide with
markers, chord names, P.M., and other technique text.
It may help if alphaTab had clearer priority/collision handling for
note-attached Free Text, or a documented way to reserve vertical space for
it.
*5. P.H. / A.H. display*
When Guitar Pro displays a P.H. marking and alphaTab does not, what is the
best way to determine whether the problem is:
- source-file encoding,
- importer mapping,
- harmonic type support,
- or display logic?
⸻
Below are a variety of screenshots from the Guitar Pro discoveries with the
same GP files also that I am using in the Vite system and next.js webpack:
[image: Screenshot 2026-04-26 at 1.10.24 PM.png]
It was during this time that the recent discussion of the Pinch Harmonics
first appeared in the Vite system. It seems that for GP8 files that they
may either be ignored or possibly a mapping issue. I will probably follow
up a PR separate but worth noting briefly:
Evidence & Findings:
1. GP8 vs. GP7 Encoding: Even though the UI menu for "Artificial
Harmonics" (as seen in my attached GP7 screenshot) is identical in both
versions, the underlying XML data for a "Pinch" selection in GP8 is not
being recognized by alphaTab.
2. The "Stripping" Effect: In the GP8 source file, the P.H. is present.
Once rendered in alphaTab/Vite, the note remains, but the harmonic
attribute and the "rail" (dashed line) disappear.
3. The Workaround Proof: I manually re-applied the Pinch Harmonic
using Guitar Pro 7 and saved the file. This "GP7-formatted" data loaded
perfectly into the Vite/alphaTab system without being stripped.
[image: Screenshot 2026-04-26 at 1.10.15 PM.png]
Another screenshot from Extreme — “Rise” where P.H. renders correctly in
multiple places.
The interesting part is that when I upload a GP8 version, the P.H. markings
disappear again. That makes me think alphaTab can display P.H., but certain
GP8 harmonic data may not be mapping through correctly.
[image: Screenshot 2026-04-26 at 10.14.37 PM.png]
One thing I noticed with GP files downloaded from Songsterr is that there
are a few source/layout patterns that can make things harder for alphaTab,
even though Guitar Pro seems to account for them more gracefully.
For example, Songsterr’s UI appears to place bar numbers to the left of the
TAB clef and time signature. I tested a similar approach here as a
work-in-progress comparison. In Songsterr, the bar numbers seem to work
almost like “north stars” for visual alignment: marker/section names line
up directly over those bar numbers, as shown in this example.
That said, I realize this may be more of a Songsterr/UI-style placement
than a native Guitar Pro convention. Guitar Pro and alphaTab both appear to
place bar numbers after the clef/time-signature area by default.
The harder issue is Free Text / Comments. Guitar Pro did not seem to offer
a clean vertical-lane solution for those either, at least not that I could
find. So for alphaTab, this may need one of the following approaches:
- better vertical stacking / collision handling for Free Text comments,
- a way to reserve a lane for note-attached comments,
- or, for player-style use cases, an option to limit/hide certain comments
when they create unreadable collisions.
This seems separate from the main bar-number alignment question.
[image: Screenshot 2026-04-26 at 9.48.42 AM.png]
During the horizontal spacing or force stretch, trying to fix the rest only
bars sometimes created issues like you see here.
[image: Screenshot 2026-04-27 at 11.43.20 AM.png]
This was another useful Guitar Pro comparison.
When I loaded the same GP8 files directly into Guitar Pro, it seemed to
resolve many of the overlap issues automatically. Led Zeppelin — “Stairway
to Heaven” is a good example.
Even though the “Intro” marker is still visually aligned with Bar Number 1,
Guitar Pro stacks the marker/section name above the other content and keeps
the score readable. So while Songsterr’s UI appears to create more
horizontal/left-side spacing for Lane 1 alignment, Guitar Pro takes a
different approach: it preserves the more traditional bar-number placement
but uses vertical stacking/collision avoidance to keep markers, chords, and
other text from colliding.
That seems like the bigger takeaway here: The exact bar-number placement
may be more of a UI preference, but the important behavior is that Guitar
Pro gives marker/section names predictable priority and enough vertical
space to avoid collisions.
[image: Screenshot 2026-04-27 at 11.31.40 AM.png]
This is another good example of the same pattern.
In the Vite/alphaTab system, this section shows overlapping/crowding
between text elements and Section names and Tempo Clusters. But when the
same GP file is opened in Guitar Pro, the overlap is mostly avoided. Guitar
Pro appears to preserve more vertical spacing and better lane integrity
between markers, chord names, technique text, and other notation elements.
So the issue may not be the GP file itself. It may be that Guitar Pro has
stronger collision avoidance / vertical stacking rules for these elements,
while alphaTab currently places some of them too close together in the
available space.
[image: Screenshot 2026-04-27 at 12.01.52 PM.png]
Now when I take the same GP files and load them into the Vite/alphaTab
system, the layout does not hold up the same way.
To be fair, most tabs do not have this much going on with comments,
markers, chords, P.M. rails, lyrics, and other overlays all competing at
once. These files are more like stress tests.
Also, I did find one important exception: Free Text / Comments appear to be
a hard case even in Guitar Pro. When I added comments close together, for
example one in Bar 1 beat 7 and another in Bar 2 beat 3, Guitar Pro also
allowed the same type of comment overlap. So I do not think Guitar Pro has
a perfect solution for Free Text comments either.
That makes me think Free Text / Comments should probably be treated
separately from the rest of the overlay-lane issues.
For alphaTab, the practical options may be:
- improve collision handling for Free Text comments where possible,
- provide a way to reserve a vertical lane for note-attached comments,
- or allow player-style apps to hide/limit dense Free Text comments when
they make the score unreadable.
The bigger distinction is that Guitar Pro seems to handle markers, chord
names, lyrics, tempo markings, and technique text with stronger vertical
spacing/lane integrity, while Free Text comments remain a special problem
even there.
[image: Screenshot 2026-04-27 at 6.32.33 PM.png]
During the Guitar Pro exploration, I made an accidental discovery: Guitar
Pro does support a “Before Tablature” tuning display.
I am not sure when Guitar Pro added this, but in the screenshot I turned it
on just to test it, and then turned off the track name so the tuning
display could sit cleanly to the left of the TAB staff.
I am not making this the main focus of this report, but it does seem
relevant because it shows that Guitar Pro has a supported layout concept
for showing tuning information directly in the left-side system area before
the tablature.
[image: Screenshot 2026-04-27 at 1.04.09 PM.png]
To make the tuning display line up cleanly with the rows underneath, I had
to adjust the spacing here.
In this test, I set the spacing to 6mm and turned Track Name Display off.
That allowed the tuning labels to sit in the left-side system area without
fighting the TAB label or pushing the row out of alignment.
This is not the main focus of the spacing report, but it was useful to see
that Guitar Pro has actual controls for this type of layout behavior.
[image: Screenshot 2026-04-27 at 1.09.45 PM.png]
Next here you can see Guitar Pro cleaned up this file quite a bit just by
uploading it, but had no answers for the Free Text or fx comments
[image: Screenshot 2026-04-27 at 1.39.37 PM.png]
In this screenshot, as you can tell I am using Guitar Pro and removed the
overlapping Free Text / comment, and the section cleans up immediately.
The issue is that I could not find a clean way to move that Free Text
vertically by itself. Even pressing Enter a few times does not really solve
it, because it moves the text within the same lane and still affects the
surrounding layout.
So this seems like a separate hard case: dense Free Text comments can cause
collisions, and even Guitar Pro does not appear to provide a simple
per-comment vertical offset or lane control for this situation.
[image: Screenshot 2026-04-27 at 1.46.01 PM.png]
I also checked the Songsterr demo editor to see how this type of
text/comment is handled there.
It looks like Songsterr is using a custom overlay system that prevents
these items from overlapping. The user-added text still attaches to the
relevant musical area, but the UI appears to manage the vertical placement
so comments do not collide with each other the same way they can in Guitar
Pro or alphaTab/Vite.
That may explain why Songsterr can keep these dense text/comment areas
readable even when the underlying GP file contains a lot of note-attached
annotations.
[image: Screenshot 2026-04-27 at 4.06.55 PM.png]
This screenshot shows where I found the Pinch Harmonic option inside Guitar
Pro.
It is located under the Artificial Harmonic panel. From there, the harmonic
type can be changed from Artificial to Pinch.
That was helpful because it confirmed that Guitar Pro treats Pinch Harmonic
as a specific harmonic type inside the same harmonic editor, rather than as
a separate free-text marking.
[image: Screenshot 2026-04-27 at 4.07.09 PM.png]
For this test, I left the Pinch Harmonic settings at the default values and
pressed Enter to apply it.
I only did this as a quick proof-of-concept to see how Guitar Pro would
encode and display the P.H. marking. The important part is that Guitar Pro
immediately created the P.H. label and harmonic rail from the built-in
harmonic settings, without needing to add it as Free Text.
[image: Screenshot 2026-04-27 at 4.07.20 PM.png]
I was expecting Guitar Pro to add a simple “P.H.” label similar to how A.H.
appears, but it actually added the full dashed harmonic rail directly above
the full bend on fret 7.
Important note: this Van Halen example does not actually require a pinch
harmonic musically. I only used it as a quick demo/discovery test to see
how Guitar Pro would encode and display the P.H. marking.
I saved this test version and loaded it into the Vite system as well. That
is why Van Halen — “Ain’t Talkin’ ’Bout Love” appears twice in the Vite
repo/test library.
The useful discovery is that this GPX/GP7-style file was not stripped on
load. The P.H. label and dashed rail stayed visible in Vite/alphaTab. That
is different from the GP8 files where the P.H. data appears to disappear or
not map through correctly after loading.
[image: Screenshot 2026-04-27 at 4.25.31 PM.png]
And here is the same test file loaded in the Vite/alphaTab system.
A couple of things stand out right away:
- The P.H. marking does render, which is great.
- However, the vertical order changes compared to Guitar Pro. In Guitar
Pro, the P.H. rail was placed closer to the bend where it was added. In
Vite/alphaTab, the P.H. appears at the very top.
- The chord names are also displaced compared to Guitar Pro, where they sit
more cleanly.
So this test seems to confirm two things at once:
1. alphaTab can render the P.H. marking/rail when the file data maps
through correctly.
2. The remaining issue may be vertical ordering/lane placement after
import/rendering, especially when chord names, harmonic markings, bend
markings, and other overlays are all present.
This has been a few days of testing, comparing, and documenting, but I
genuinely love alphaTab and everything you do with it. I hope all of this
helps not just my project, but the whole alphaTab family.
…On Sun, Apr 26, 2026 at 6:26 AM Daniel Kuschny ***@***.***> wrote:
Round 2: I did some further research on the topic and will explore some
adaptions in the spacing algorithm. While we use Gourlay, its classical
formula is not established that commonly anymore. There are newer adaptions
and improvements to this (keeping the spring-rod base algorithm but with
adjustments to the spacing calculations).
I've setup already some battle-plan for doing a spike covering 3 areas:
1. Change the general spacing model from a currnetly
additive/logaritmic one (original gourlay, outdated) to a
power-law/multiplicative based one (closer to modern industry practice)
2. layout refinements for better justification and "overlay content"
which extends the beats (lyrics, tempo markers etc)
3. Some small improvements around width and force calculations
(clamping of forces, ensuring minimum widths).
------------------------------
My question to you would be: Can you provide me a test data set of 5-10
files showing different constellations of spacing situations? This will
allow me to optimize things based on your concrete findings, not just
tackle some theoretical combinations. This is a very subjective matter, and
the better info I have from your side, the better I can verify my changes
bring an improvement.
—
Reply to this email directly, view it on GitHub
<#2679 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BNLESQHA74R75TQGGXUVOVD4XYFBDAVCNFSM6AAAAACYGS2GCSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNZRHA4TKMA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Just a heads-up my email was quite long, so it looks like it hides the
detailed notes I added with the attached screenshots... so if you didn't
see it right away, look for something like this:
[Message clipped] View entire message
<https://mail.google.com/mail/u/1?ui=2&ik=ee9ba224e5&view=lg&permmsgid=msg-a%3Ar7048484524255126774&ser=1>
To open all the rest of the notes
On Mon, Apr 27, 2026 at 7:18 PM Brett Bolzenthal ***@***.***>
wrote:
… Hi Daniel,
I put together a more structured set of notes and test cases. The goal is
not to clone Songsterr 1:1. I’m trying to isolate concrete readability
issues around spacing, system wrapping, lyrics, marker/tempo placement, and
technique/free-text collisions using real GP files.
I also compared several cases against Guitar Pro so the report separates
native alphaTab behavior from app-specific UI preferences. The main
recurring areas are viewport-dependent row spacing, overlay lane priority,
lyrics appearing above the staff, free-text/FX collisions, and inconsistent
P.H. display depending on the file. Now the real testing challenge was I
loaded the same GP files and more on Vite since it's very much a default
version of alphaTab whereas my Next.js webpack version has the forceStretch
that ballooned rest only bars while trying only to add spacing 2.3mm global
to the notation bars only.
I’ll continue adding labeled screenshots and GP files, but this should
give a clearer map of the issues I’m seeing.
https://github.com/AvaTheArchitect/louislam-borrowed-labs
*alphaTab Guitar Pro Spacing, Overlay, and Readability Test Notes.*
(Attached is a PDF copy of this for easy print out)
*Purpose: *
These notes document Guitar Pro tab-rendering issues observed in a
lightweight alphaTab/Vite test environment, with additional comparisons
against Guitar Pro and a separate Maestro.ai alphaTab implementation.
The goal is *not* to clone Songsterr 1:1. The goal is to identify
concrete spacing, wrapping, lyric, marker, tempo, and technique-overlay
cases that affect readability in a guitar-learning and practice interface.
The issues below include:
- Note spacing that becomes too tight in certain rows
- Empty/rest-measure spacing inconsistencies
- FX/free-text overlap
- Lyric overlap or crowding
- Marker/section-name collisions
- Tempo marker collisions
- Chord name, P.M., vibrato, let-ring, and technique-lane conflicts
- Differences between normal-window and full-screen rendering
- Possible file/model differences in how pinch harmonics are encoded
or displayed
For each screenshot/test case, I will label:
- Song
- Track number
- Normal window vs. full screen
- Browser/test environment
- Approximate viewport/container width when available
- Measure numbers where the issue is visible
The goal is to provide concrete reproducible cases rather than broad
statements about spacing.
⸻
*General Observations *
*1. Viewport-dependent spacing: *
Several layout issues become more visible when switching between normal
window and full-screen browser views. In some files, full screen creates
more horizontal room, but the vertical spacing between systems appears to
compress or change in a way that makes overlay collisions worse.
This is different from what I observed in Guitar Pro, where the spacing
between rows appears more stable between normal and full-screen views. For
example, in one Guitar Pro comparison around the Stairway to Heaven solo
section, row spacing stayed approximately the same in normal view and full
screen, while alphaTab/Vite changed more noticeably.
This is not necessarily “Guitar Pro is right and alphaTab is wrong,” but
it suggests that alphaTab’s vertical-scroll layout may recalculate system
spacing in a way that affects overlay readability when wrapping changes.
*2. Overlay lane priority: *
A recurring issue is that marker/section names, tempo markings, chord
names, P.M., let-ring, vibrato, free text, and lyrics do not always appear
to have predictable lane priority.
In practice, this can lead to:
- Section names colliding with chord names
- Tempo markings and section markers competing for the same vertical
space
- P.M. rails floating inconsistently
- FX/free-text comments overlapping with other notation text
- Lyrics appearing above the staff instead of below it
- Vibrato/technique markings losing lane consistency
A predictable vertical stacking model would help significantly.
*3. Note spacing vs. rest-bar spacing: *
The most difficult spacing issue is balancing readable note spacing with
compact rest-only bars.
Higher stretch/spacing can improve note readability in bars with actual
notation, but rest-only bars can become too wide. Lower spacing keeps empty
bars compact but can make dense note bars too tight.
Some rest-only bars also appear wider because of meter/duration content.
For example, in Queen “Bohemian Rhapsody,” rest-only bars in 12/8 or 6/8
with dotted rests appear naturally larger than simpler 4/4 rest-only bars.
That appears musically reasonable, but it contributes to the broader
spacing challenge.
*4. Guitar Pro comparison: *
Guitar Pro exposes several layout and notation controls that help with
readability, including:
- Tab-only view
- Wider horizontal spacing
- Chord/font sizing behavior
- More stable system spacing
- Section markers occupying stable vertical space
- System layout controls
- Pinch harmonic notation options discovery inside Guitar Pro
This suggests that some of the desired behavior is not merely a
Songsterr-style preference, but overlaps with standard professional
tab-layout controls.
⸻
*Test Files / Song Notes: *
*1. Van Halen — “Ain’t Talkin’ ’Bout Love” *
*Track 1 — Normal Screen*
- Lyrics appear above the staff rather than below it.
- Marker/section names appear elevated as a result of lyric placement.
*Track 1 — Full Screen*
- Lyric placement remains above the staff and becomes more crowded.
- Visible crowding/overlap around:
- M36: “you think you’re really cookin’”
- M66: “and looked down…”
- M128: tempo cluster = 60
- At M128, the tempo marker and “Half Time” appear to compete for
vertical priority.
*Track 3 — Full Screen*
- M1: section marker “Intro” collides or crowds with the
TAB/time-signature area.
- P.M. markings are not consistently anchored in a stable lane.
- FX/free-text and section markers appear to share the same vertical
lane in some places.
- M9: “Main Riff” overlaps or crowds with FX/comment text.
- Chord names appear displaced rather than anchored into a consistent
chord lane.
- M24: slide/picking text is tight.
- M25: P.M. alignment is inconsistent and collides with the “Chorus”
marker.
*Track 3 — Normal Screen*
- Similar to full screen.
- Several rows are vertically tight, causing overlay/marker collisions.
⸻
*2. Warrant — “Uncle Tom’s Cabin” *
*Track 3 — Normal Screen*
- Note spacing is tight in some areas, approximately .3cm–.4cm.
- Row spacing is also tight.
- P.M. markings are not consistently anchored in a stable lane.
- Visible around:
- M39
- M68
- Vibrato markings also lose lane consistency in some locations.
*Track 3 — Full Screen*
- Similar to normal screen.
- Tight spacing remains between rows.
- Same general P.M. and vibrato lane issues.
*Track 1 — Full Screen*
- Row spacing remains tight.
- Interesting contrast: note spacing appears better on this track than
Track 3, even with similar note patterns.
- Some notes appear closer to .6cm–.7cm, which is more readable.
- Raised vibrato and P.M. markings still do not consistently sit in a
stable lane.
*Note*
It is not yet clear why similar note patterns are spaced better on Track 1
than on the guitar track. This may be due to track content, source-file
encoding, or row-layout differences.
⸻
*3. Guns N’ Roses — “Welcome to the Jungle” *
*Track 1 — Normal Screen*
- Lyrics appear above the staff instead of below it.
- Lyrics overlap or crowd around:
- M26
- M29
- M36
- M41
*Track 1 — Full Screen*
- Mostly the same as normal screen.
*Track 3 — Full Screen*
- M1: “Intro” overlaps with P.M. / technique placement.
- Tight spacing between rows.
- Note spacing is tight.
*Track 3 — Normal Screen*
- Similar issues as full screen.
⸻
*4. Guns N’ Roses — “Sweet Child O’ Mine” *
*Track 5 — Normal Screen*
- Tight note spacing.
- Significant overlap above bars involving:
- chord names
- P.M. rails
- marker/section names
- Especially visible around:
- M176
- M177
- Note spacing may not be the primary issue here; overlay lane
placement appears more significant.
*Track 5 — Full Screen*
- Similar to normal screen, possibly worse around:
- M130
- M146
- M176
- M177
*Track 1 — Full Screen*
- Lyrics appear above the staff.
- Rows are tight.
- Lyrics overlap or lack vertical spacing around:
- M36
- M42
- M65
- Vibrato appears displaced.
*Track 1 — Normal Screen*
- Overlap visible around:
- M25
- M57
*Track 4 — Normal Screen*
- Overlap visible around:
- M41
- M176
- M177
⸻
*5. Van Halen — “Eruption” *
*Track 1 — Full Screen*
- Full screen appears worse than normal screen.
- Row 1 is crowded.
- “Intro” appears to occupy vertical space, but other overlay lanes
then collide around it.
- Chord names are not consistently anchored.
- M12: visible overlap.
- Note spacing is tight, but the main issue appears to be overlay lane
placement.
*Track 1 — Normal Screen*
- Normal screen appears better than full screen.
- Row 1 has fewer overlapping/misalignment issues.
- Some overlay lane anchoring issues remain.
- Chord names are displaced.
⸻
*6. Stevie Ray Vaughan — “Pride and Joy” *
*Track 2 — Normal Screen*
- Very tight note spacing in several areas, especially around:
- M4
- M15
- M39
- M48
- M52
- M53
- M57
- M59
*Track 1 — Full Screen*
- Lyrics appear above the staff.
- Overlay lanes are off.
- Lyrics overlap around:
- M16
- M17
- M25
- M26
- M30
- M31
- M41
- M43
- M76
*Track 1 — Normal Screen*
- Mostly the same as full screen.
⸻
*7. Extreme — “Rise” *
*Track 1 — Normal Screen*
- This is one of the first files where pinch harmonic labels appear
visibly in alphaTab.
- P.H. appears above:
- M8
- M24
- M48
- M139
- In some locations, the file may show both A.H. and P.H.-style
behavior. Since the examples involve bends, they are likely intended as
P.H.; this may be source-file/tab-authoring related.
- Note spacing is acceptable at the beginning but becomes more
challenged later in solo sections.
- Overlap visible around:
- M65
- M101
- M117
- M119
- M122
- M125
*Track 1 — Full Screen*
- Row spacing appears to decrease in full screen.
- Overlap becomes more visible around:
- M65
- M101
- M117 and onward
⸻
*8. Led Zeppelin — “Stairway to Heaven” *
*Guitar Pro Reference Notes*
Guitar Pro allows standard notation and tablature to be toggled from:
*View → Inspector → Track → View Options → Standard / Tab*
This made it possible to compare tab-only spacing more directly.
Initial comparison suggests Guitar Pro keeps row spacing more consistent
between normal view and full screen. Around the guitar solo section near
M118, Guitar Pro showed approximately *3.9cm* of row spacing in both
normal view and full screen.
By comparison, alphaTab/Vite changed more noticeably. Around M118:
- alphaTab/Vite full screen: approximately 3.0cm
- alphaTab/Vite normal screen: approximately 2.6cm
*Track 2 — Full Screen*
Observed issues:
- Bar-number / alignment issues with section names and chord names
around:
- M1
- M41
- M49
- M109
- With DevTools open, collisions are more visible around these
measures.
- With DevTools closed, similar issues remain around:
- M1
- M41
- M138
- M156
- Chord names are not consistently anchored into a stable overlay lane
above the staff.
*Track 2 — Normal Screen*
- Similar issues as full screen.
- Chord names still do not consistently anchor into a stable overlay
lane above the staff.
*Track 1 — Vocals — Normal Screen*
- Lyrics appear above the staff instead of in a lower lyric row.
- This matches the lyric-placement issue seen in several other songs.
*Track 1 — Vocals — Full Screen*
- Full screen does not appear to give lyrics more usable spacing.
- Vertical overhead between rows is reduced, making the layout feel
tighter rather than more readable.
*Track 4 — Electric Guitar Clean — Full Screen*
Row spacing is compromised in several areas, especially around:
- M41
- M49
- M66
- M100
- M109
- M110
- M118
- M138
- M156
*Track 4 — Electric Guitar Clean — Normal Screen*
- Similar issues as full screen.
- Row spacing has slightly more cushion in some places, approximately
0.2cm–0.3cm more, but not consistently.
- Around M118, alphaTab/Vite measured approximately:
- Full screen: 3.0cm
- Normal screen: 2.6cm
*Guitar Pro Comparison*
Guitar Pro appears to keep row spacing fixed between normal and full
screen:
- M118 area:
- Guitar Pro normal view: approximately 3.9cm
- Guitar Pro full screen: approximately 3.9cm
This suggests Guitar Pro is preserving a more stable page/engraving layout
across viewport changes, while alphaTab/Vite’s vertical-scroll layout
responds more dynamically to available width.
⸻
*9. Metallica — “One” *
*Track 4 — Distortion Guitar — Normal Screen*
- Row spacing issues around:
- M115
- M149
- M173
- M209
- M237
- Note spacing is also tight, especially in sections with heavy
tapping.
*Track 4 — Full Screen*
- Some spacing stayed the same; for example, M149 stayed around 3.0cm.
- M209 changed more noticeably:
- Normal screen: approximately 2.2cm
- Full screen: approximately 2.8cm
- Overlay lane placement did not appear to improve even when more row
spacing became available.
⸻
*10. Night Ranger — “Sister Christian” *
*Track 1 — Overdriven Guitar — Full Screen*
- Overlay lane spacing issue throughout.
- Approximate row spacing observed: 1.6cm.
*Track 1 — Normal Screen*
- Spacing is even tighter, approximately 1.1cm.
- There is very little room above the staff for overlay lanes.
*Track 2 — Distortion Guitar — Normal Screen*
- Tight row spacing.
- Note spacing becomes an issue with bend annotations around:
- M71
- M76
*Track 2 — Full Screen*
- Little to no improvement observed.
⸻
*11. Ozzy Osbourne — “Crazy Train” *
*Track 3 — Distortion Guitar — Normal View*
- Row 2 overlapping.
- Row 3 cramped spacing.
- Chord names are not anchored in a stable lane.
- M36 is very tight for the pick slide; similar issue appears around
M136.
- Free text/comment overlap around:
- M39
- M43
- M73
- M95
- M139
- M107: P.M. and rails are displaced.
*Track 3 — Full Screen*
- M11 overlapping.
- Tight spacing between rows.
- Additional overlap around:
- M39
- M53
- M95
*Track 1 — Vocals — Full Screen*
- Lyrics are very high above the staff.
- In Guitar Pro, the lyrics open under the staff instead of above it,
although both options appear to exist in Guitar Pro’s stylesheet/settings
menus.
*Track 1 — Normal Screen*
- Mostly the same.
⸻
*12. Queen — “Bohemian Rhapsody” *
*Track 3 — Electric Guitar Clean — Normal View*
- Tempo markings/clusters have inconsistent placement.
- Some are anchored lower and correctly, while others appear very high.
- Examples:
- M66–M84: tempo markers appear more correctly anchored
- M55–M65: tempo markers appear too high
- Tight note spacing around M48.
- M41 appears to have a whole rest and fret note 20 in the same spot.
- M41 also shows a whole rest and sustained (15).
- M42 has both a whole rest and fret 20 on high E string, which seems
contradictory unless this is a multi-voice/source-model issue.
*Track 3 — Full Screen*
- Pretty much the same as normal view.
*Additional Rest-Bar Observation*
This file also shows that rest-only bars in different meters behave
differently. For example, 12/8 or 6/8 rest-only bars with dotted rests
appear wider than simpler 4/4 rest-only bars. This may be musically
expected, but it is useful when evaluating rest-measure spacing.
⸻
*Pinch Harmonic / Artificial Harmonic Notes*
A separate area worth testing is P.H. / A.H. display consistency.
In Guitar Pro 7, the Artificial Harmonic dialog allows selecting:
- Artificial
- Pinch
- Tap
- Semi
- Feedback
When “Pinch” is selected, Guitar Pro displays a P.H. marking and rail
above the note. I tested this manually in Van Halen “Ain’t Talkin’ ’Bout
Love” as a demonstration, even though that specific note may not musically
require a pinch harmonic.
This confirms that the Guitar Pro file/model can represent P.H.-style
notation directly. The inconsistency may come from:
- How different GP files encode harmonics
- Whether the file uses A.H. vs P.H.
- Whether the importer maps the harmonic type correctly
- Whether alphaTab chooses to display or suppress the label in
specific cases
This should be tested with files where Guitar Pro clearly displays P.H.
and alphaTab either displays it or does not.
⸻
*Main Issue Categories*
*Category A — alphaTab rendering/collision issues*
These are the areas that seem most appropriate to investigate in alphaTab:
- Free Text / FX comments overlapping other notation text
- Lyrics appearing above the staff when Guitar Pro places them below
- Marker names colliding with chord names or tempo markers
- P.M., let-ring, vibrato, and technique-lane conflicts
- P.H. missing when Guitar Pro displays it
- Viewport-dependent row spacing reducing overlay readability
- Tempo markers/clusters appearing inconsistently high or low
- Lack of predictable lane priority between marker, tempo, chord,
lyric, and technique elements
*Category B — Product/UI customization*
These may be more application-specific and not necessarily alphaTab bugs:
- Moving bar numbers left like Songsterr
- Custom max-width reading column for widescreen displays
- Custom CSS shell for desktop/widescreen reading comfort
- Custom overlay lane system on top of alphaTab
- Custom visual styling to match a learning/practice interface
⸻
*Questions / Areas Where Guidance Would Help*
*1. Recommended native setup*
For a vertical-scroll guitar-learning interface, what is the recommended
native alphaTab setup for:
- readable note spacing,
- compact rest-only bars,
- stable row spacing,
- and predictable overlay placement?
Should this generally be:
- Page layout with Automatic systems layout,
- Page layout with UseModelLayout,
- Parchment layout,
- or another setup?
*2. Overlay collision handling*
Is there currently a supported way to define or influence priority between:
- section markers,
- tempo markings,
- chord names,
- lyrics,
- P.M.,
- let ring,
- vibrato,
- and free text?
If not, would better collision/lane handling be a reasonable feature
request?
*3. Lyrics lane*
For files where Guitar Pro displays lyrics below the staff, is alphaTab
expected to display them below as well? If alphaTab shows them above, is
that likely:
- file-model related,
- notation settings related,
- or a rendering/layout issue?
*4. Free Text / FX comments*
Free Text / FX comments are one of the hardest cases. In Guitar Pro, Free
Text can be attached to notes, but I have not found a per-object vertical
lane or offset control. In alphaTab, these FX comments can collide with
markers, chord names, P.M., and other technique text.
It may help if alphaTab had clearer priority/collision handling for
note-attached Free Text, or a documented way to reserve vertical space for
it.
*5. P.H. / A.H. display*
When Guitar Pro displays a P.H. marking and alphaTab does not, what is the
best way to determine whether the problem is:
- source-file encoding,
- importer mapping,
- harmonic type support,
- or display logic?
⸻
Below are a variety of screenshots from the Guitar Pro discoveries with
the same GP files also that I am using in the Vite system and next.js
webpack:
[image: Screenshot 2026-04-26 at 1.10.24 PM.png]
It was during this time that the recent discussion of the Pinch Harmonics
first appeared in the Vite system. It seems that for GP8 files that they
may either be ignored or possibly a mapping issue. I will probably follow
up a PR separate but worth noting briefly:
Evidence & Findings:
1. GP8 vs. GP7 Encoding: Even though the UI menu for "Artificial
Harmonics" (as seen in my attached GP7 screenshot) is identical in both
versions, the underlying XML data for a "Pinch" selection in GP8 is not
being recognized by alphaTab.
2. The "Stripping" Effect: In the GP8 source file, the P.H. is
present. Once rendered in alphaTab/Vite, the note remains, but the harmonic
attribute and the "rail" (dashed line) disappear.
3. The Workaround Proof: I manually re-applied the Pinch Harmonic
using Guitar Pro 7 and saved the file. This "GP7-formatted" data loaded
perfectly into the Vite/alphaTab system without being stripped.
[image: Screenshot 2026-04-26 at 1.10.15 PM.png]
Another screenshot from Extreme — “Rise” where P.H. renders correctly in
multiple places.
The interesting part is that when I upload a GP8 version, the P.H.
markings disappear again. That makes me think alphaTab can display P.H.,
but certain GP8 harmonic data may not be mapping through correctly.
[image: Screenshot 2026-04-26 at 10.14.37 PM.png]
One thing I noticed with GP files downloaded from Songsterr is that there
are a few source/layout patterns that can make things harder for alphaTab,
even though Guitar Pro seems to account for them more gracefully.
For example, Songsterr’s UI appears to place bar numbers to the left of
the TAB clef and time signature. I tested a similar approach here as a
work-in-progress comparison. In Songsterr, the bar numbers seem to work
almost like “north stars” for visual alignment: marker/section names line
up directly over those bar numbers, as shown in this example.
That said, I realize this may be more of a Songsterr/UI-style placement
than a native Guitar Pro convention. Guitar Pro and alphaTab both appear to
place bar numbers after the clef/time-signature area by default.
The harder issue is Free Text / Comments. Guitar Pro did not seem to offer
a clean vertical-lane solution for those either, at least not that I could
find. So for alphaTab, this may need one of the following approaches:
- better vertical stacking / collision handling for Free Text comments,
- a way to reserve a lane for note-attached comments,
- or, for player-style use cases, an option to limit/hide certain comments
when they create unreadable collisions.
This seems separate from the main bar-number alignment question.
[image: Screenshot 2026-04-26 at 9.48.42 AM.png]
During the horizontal spacing or force stretch, trying to fix the rest
only bars sometimes created issues like you see here.
[image: Screenshot 2026-04-27 at 11.43.20 AM.png]
This was another useful Guitar Pro comparison.
When I loaded the same GP8 files directly into Guitar Pro, it seemed to
resolve many of the overlap issues automatically. Led Zeppelin — “Stairway
to Heaven” is a good example.
Even though the “Intro” marker is still visually aligned with Bar Number
1, Guitar Pro stacks the marker/section name above the other content and
keeps the score readable. So while Songsterr’s UI appears to create more
horizontal/left-side spacing for Lane 1 alignment, Guitar Pro takes a
different approach: it preserves the more traditional bar-number placement
but uses vertical stacking/collision avoidance to keep markers, chords, and
other text from colliding.
That seems like the bigger takeaway here: The exact bar-number placement
may be more of a UI preference, but the important behavior is that Guitar
Pro gives marker/section names predictable priority and enough vertical
space to avoid collisions.
[image: Screenshot 2026-04-27 at 11.31.40 AM.png]
This is another good example of the same pattern.
In the Vite/alphaTab system, this section shows overlapping/crowding
between text elements and Section names and Tempo Clusters. But when the
same GP file is opened in Guitar Pro, the overlap is mostly avoided. Guitar
Pro appears to preserve more vertical spacing and better lane integrity
between markers, chord names, technique text, and other notation elements.
So the issue may not be the GP file itself. It may be that Guitar Pro has
stronger collision avoidance / vertical stacking rules for these elements,
while alphaTab currently places some of them too close together in the
available space.
[image: Screenshot 2026-04-27 at 12.01.52 PM.png]
Now when I take the same GP files and load them into the Vite/alphaTab
system, the layout does not hold up the same way.
To be fair, most tabs do not have this much going on with comments,
markers, chords, P.M. rails, lyrics, and other overlays all competing at
once. These files are more like stress tests.
Also, I did find one important exception: Free Text / Comments appear to
be a hard case even in Guitar Pro. When I added comments close together,
for example one in Bar 1 beat 7 and another in Bar 2 beat 3, Guitar Pro
also allowed the same type of comment overlap. So I do not think Guitar Pro
has a perfect solution for Free Text comments either.
That makes me think Free Text / Comments should probably be treated
separately from the rest of the overlay-lane issues.
For alphaTab, the practical options may be:
- improve collision handling for Free Text comments where possible,
- provide a way to reserve a vertical lane for note-attached comments,
- or allow player-style apps to hide/limit dense Free Text comments when
they make the score unreadable.
The bigger distinction is that Guitar Pro seems to handle markers, chord
names, lyrics, tempo markings, and technique text with stronger vertical
spacing/lane integrity, while Free Text comments remain a special problem
even there.
[image: Screenshot 2026-04-27 at 6.32.33 PM.png]
During the Guitar Pro exploration, I made an accidental discovery: Guitar
Pro does support a “Before Tablature” tuning display.
I am not sure when Guitar Pro added this, but in the screenshot I turned
it on just to test it, and then turned off the track name so the tuning
display could sit cleanly to the left of the TAB staff.
I am not making this the main focus of this report, but it does seem
relevant because it shows that Guitar Pro has a supported layout concept
for showing tuning information directly in the left-side system area before
the tablature.
[image: Screenshot 2026-04-27 at 1.04.09 PM.png]
To make the tuning display line up cleanly with the rows underneath, I had
to adjust the spacing here.
In this test, I set the spacing to 6mm and turned Track Name Display off.
That allowed the tuning labels to sit in the left-side system area without
fighting the TAB label or pushing the row out of alignment.
This is not the main focus of the spacing report, but it was useful to see
that Guitar Pro has actual controls for this type of layout behavior.
[image: Screenshot 2026-04-27 at 1.09.45 PM.png]
Next here you can see Guitar Pro cleaned up this file quite a bit just by
uploading it, but had no answers for the Free Text or fx comments
[image: Screenshot 2026-04-27 at 1.39.37 PM.png]
In this screenshot, as you can tell I am using Guitar Pro and removed the
overlapping Free Text / comment, and the section cleans up immediately.
The issue is that I could not find a clean way to move that Free Text
vertically by itself. Even pressing Enter a few times does not really solve
it, because it moves the text within the same lane and still affects the
surrounding layout.
So this seems like a separate hard case: dense Free Text comments can
cause collisions, and even Guitar Pro does not appear to provide a simple
per-comment vertical offset or lane control for this situation.
[image: Screenshot 2026-04-27 at 1.46.01 PM.png]
I also checked the Songsterr demo editor to see how this type of
text/comment is handled there.
It looks like Songsterr is using a custom overlay system that prevents
these items from overlapping. The user-added text still attaches to the
relevant musical area, but the UI appears to manage the vertical placement
so comments do not collide with each other the same way they can in Guitar
Pro or alphaTab/Vite.
That may explain why Songsterr can keep these dense text/comment areas
readable even when the underlying GP file contains a lot of note-attached
annotations.
[image: Screenshot 2026-04-27 at 4.06.55 PM.png]
This screenshot shows where I found the Pinch Harmonic option inside
Guitar Pro.
It is located under the Artificial Harmonic panel. From there, the
harmonic type can be changed from Artificial to Pinch.
That was helpful because it confirmed that Guitar Pro treats Pinch
Harmonic as a specific harmonic type inside the same harmonic editor,
rather than as a separate free-text marking.
[image: Screenshot 2026-04-27 at 4.07.09 PM.png]
For this test, I left the Pinch Harmonic settings at the default values
and pressed Enter to apply it.
I only did this as a quick proof-of-concept to see how Guitar Pro would
encode and display the P.H. marking. The important part is that Guitar Pro
immediately created the P.H. label and harmonic rail from the built-in
harmonic settings, without needing to add it as Free Text.
[image: Screenshot 2026-04-27 at 4.07.20 PM.png]
I was expecting Guitar Pro to add a simple “P.H.” label similar to how
A.H. appears, but it actually added the full dashed harmonic rail directly
above the full bend on fret 7.
Important note: this Van Halen example does not actually require a pinch
harmonic musically. I only used it as a quick demo/discovery test to see
how Guitar Pro would encode and display the P.H. marking.
I saved this test version and loaded it into the Vite system as well. That
is why Van Halen — “Ain’t Talkin’ ’Bout Love” appears twice in the Vite
repo/test library.
The useful discovery is that this GPX/GP7-style file was not stripped on
load. The P.H. label and dashed rail stayed visible in Vite/alphaTab. That
is different from the GP8 files where the P.H. data appears to disappear or
not map through correctly after loading.
[image: Screenshot 2026-04-27 at 4.25.31 PM.png]
And here is the same test file loaded in the Vite/alphaTab system.
A couple of things stand out right away:
- The P.H. marking does render, which is great.
- However, the vertical order changes compared to Guitar Pro. In Guitar
Pro, the P.H. rail was placed closer to the bend where it was added. In
Vite/alphaTab, the P.H. appears at the very top.
- The chord names are also displaced compared to Guitar Pro, where they
sit more cleanly.
So this test seems to confirm two things at once:
1. alphaTab can render the P.H. marking/rail when the file data maps
through correctly.
2. The remaining issue may be vertical ordering/lane placement after
import/rendering, especially when chord names, harmonic markings, bend
markings, and other overlays are all present.
This has been a few days of testing, comparing, and documenting, but I
genuinely love alphaTab and everything you do with it. I hope all of this
helps not just my project, but the whole alphaTab family.
On Sun, Apr 26, 2026 at 6:26 AM Daniel Kuschny ***@***.***>
wrote:
> Round 2: I did some further research on the topic and will explore some
> adaptions in the spacing algorithm. While we use Gourlay, its classical
> formula is not established that commonly anymore. There are newer adaptions
> and improvements to this (keeping the spring-rod base algorithm but with
> adjustments to the spacing calculations).
>
> I've setup already some battle-plan for doing a spike covering 3 areas:
>
> 1. Change the general spacing model from a currnetly
> additive/logaritmic one (original gourlay, outdated) to a
> power-law/multiplicative based one (closer to modern industry practice)
> 2. layout refinements for better justification and "overlay content"
> which extends the beats (lyrics, tempo markers etc)
> 3. Some small improvements around width and force calculations
> (clamping of forces, ensuring minimum widths).
>
> ------------------------------
>
> My question to you would be: Can you provide me a test data set of 5-10
> files showing different constellations of spacing situations? This will
> allow me to optimize things based on your concrete findings, not just
> tackle some theoretical combinations. This is a very subjective matter, and
> the better info I have from your side, the better I can verify my changes
> bring an improvement.
>
> —
> Reply to this email directly, view it on GitHub
> <#2679 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/BNLESQHA74R75TQGGXUVOVD4XYFBDAVCNFSM6AAAAACYGS2GCSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNZRHA4TKMA>
> .
> You are receiving this because you authored the thread.Message ID:
> ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
@AvaTheArchitect It might be better to use the GitHub UI to reply to contribute to discussions. WIth using mail you might see outdated messages and reply to stale information, messages cannot be structured hierarchically, formatting is lost, it generates additional noise (mail details) in GitHub and attachments do not work at all. The link you shared is only accessible to you. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Daniel — understood on using the GitHub UI directly. Sorry for the noisy email-style replies and the Gmail clipping issue. To make this easier to use for your spacing spike, I’m condensing the earlier long email into a smaller dataset with one clear purpose per file. The goal is not to clone Songsterr 1:1. I’m trying to isolate concrete readability issues around spacing, system wrapping, lyrics, marker/tempo placement, and technique/free-text collisions using real GP files. To make this easier to use for your spacing spike, I’ll condense the earlier notes into a smaller 5–10 file dataset with one clear purpose per file. Condensed spacing/overlay test dataset
I’ll attach the GP files and the most relevant screenshots directly here through the GitHub UI, instead of relying on email attachments/links. The main purpose of this dataset is to help isolate:
Separate side observations like P.H./A.H. mapping, tuning display before tablature, and bar-number placement can be moved into separate tickets so this discussion stays focused on spacing and overlay readability. |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
I cannot see any attachment to this post. did you forget to upload it? |
Beta Was this translation helpful? Give feedback.
-
|
Yes — you’re right, I forgot to attach the image. Sorry about that. The specific thing I was trying to show is the interaction between SongBook-style layout / fixed grid behavior and horizontal stretching:
None of these were tested on the alphaTab-vite v1.8.1 only on the alphaTab v1.8.1 and Webpack v1.8.1: Here are the images from this issue: One clarification: I think there may be two related behaviors here, not just one. In one of the screenshots it shows the more severe case: dense material becomes heavily compressed/collided in a horizontal strip, making the notation unreadable. The second/third screenshots show the opposite side of the spacing tradeoff: in SongBook/page-style layout, sparse or rest-heavy bars can stretch very wide across the row. This becomes more obvious when fixed grid / bars-per-row constraints are layered on top, because the row still has to justify across the available width. So the pattern I’m trying to document is:
Here are a few things that were tested when this this all happened: For clarity, the “ballooning” screenshots were from a Maestro.ai P6 layout experiment. The grid/spacing knobs being tested were mainly:
The dense/page profile that amplified the behavior was essentially: display: {
layoutMode: "Page",
systemsLayoutMode: "Automatic",
barsPerRow: 5,
stretchForce: 0.6,
minBarWidth: 180,
justifyLastSystem: true,
}
The medium/narrow variants changed only the fixed row count:
barsPerRow: 4 // medium
barsPerRow: 3 // narrow
The sparse/rest-heavy test profile was:
display: {
layoutMode: "Page",
systemsLayoutMode: "Automatic",
barsPerRow: 8,
stretchForce: 0.6,
minBarWidth: 40,
justifyLastSystem: false,
}
The behavior I was trying to document was that fixed bars-per-row/grid constraints can amplify both sides of the spacing tradeoff:
* dense passages can become crowded/compressed,
* sparse/rest-heavy bars can stretch/balloon across the available row,
* and the effect changes depending on barsPerRow, stretchForce, minBarWidth, and row justification.
I’ll keep these labeled as Maestro.ai P6 layout-profile experiments and separate them from any screenshots taken from native/default alphaTab. |
Beta Was this translation helpful? Give feedback.
-
Screenshot Notes / Guitar Pro ComparisonBelow are the screenshot notes that were clipped in my earlier email reply. I am reposting them directly through the GitHub UI so they are easier to view and reference. The screenshots use the same GP files tested in:
The main purpose is to compare spacing, overlay-lane behavior, and readability across the same source files. 
One thing I noticed with GP files downloaded from Songsterr is that there are a few source/layout patterns that can make things harder for alphaTab, even though Guitar Pro seems to account for them more gracefully. For example, Songsterr’s UI appears to place bar numbers to the left of the TAB clef and time signature. I tested a similar approach here as a work-in-progress comparison. In Songsterr, the bar numbers seem to work almost like “north stars” for visual alignment: marker/section names line up directly over those bar numbers, as shown in this example. That said, I realize this may be more of a Songsterr/UI-style placement than a native Guitar Pro convention. Guitar Pro and alphaTab both appear to place bar numbers after the clef/time-signature area by default. The harder issue is Free Text / Comments. Guitar Pro did not seem to offer a clean vertical-lane solution for those either, at least not that I could find. So for alphaTab, this may need one of the following approaches:
This seems separate from the main bar-number alignment question. 
During the horizontal spacing or force stretch, trying to fix the rest only bars sometimes created issues like you see here. 
This was another useful Guitar Pro comparison. When I loaded the same GP8 files directly into Guitar Pro, it seemed to resolve many of the overlap issues automatically. Led Zeppelin — “Stairway to Heaven” is a good example. Even though the “Intro” marker is still visually aligned with Bar Number 1, Guitar Pro stacks the marker/section name above the other content and keeps the score readable. So while Songsterr’s UI appears to create more horizontal/left-side spacing for Lane 1 alignment, Guitar Pro takes a different approach: it preserves the more traditional bar-number placement but uses vertical stacking/collision avoidance to keep markers, chords, and other text from colliding. That seems like the bigger takeaway here: The exact bar-number placement may be more of a UI preference, but the important behavior is that Guitar Pro gives marker/section names predictable priority and enough vertical space to avoid collisions. 
This is another good example of the same pattern. In the Vite/alphaTab system, this section shows overlapping/crowding between text elements and Section names and Tempo Clusters. But when the same GP file is opened in Guitar Pro, the overlap is mostly avoided. Guitar Pro appears to preserve more vertical spacing and better lane integrity between markers, chord names, technique text, and other notation elements. So the issue may not be the GP file itself. It may be that Guitar Pro has stronger collision avoidance / vertical stacking rules for these elements, while alphaTab currently places some of them too close together in the available space. 
Now when I take the same GP files and load them into the Vite/alphaTab system, the layout does not hold up the same way. To be fair, most tabs do not have this much going on with comments, markers, chords, P.M. rails, lyrics, and other overlays all competing at once. These files are more like stress tests. Also, I did find one important exception: Free Text / Comments appear to be a hard case even in Guitar Pro. When I added comments close together, for example one in Bar 1 beat 7 and another in Bar 2 beat 3, Guitar Pro also allowed the same type of comment overlap. So I do not think Guitar Pro has a perfect solution for Free Text comments either. That makes me think Free Text / Comments should probably be treated separately from the rest of the overlay-lane issues. For alphaTab, the practical options may be:
The bigger distinction is that Guitar Pro seems to handle markers, chord names, lyrics, tempo markings, and technique text with stronger vertical spacing/lane integrity, while Free Text comments remain a special problem even there. 
Next here you can see Guitar Pro cleaned up this file quite a bit just by uploading it, but had no answers for the Free Text or fx comments 
In this screenshot, as you can tell I am using Guitar Pro and removed the overlapping Free Text / comment, and the section cleans up immediately. The issue is that I could not find a clean way to move that Free Text vertically by itself. Even pressing Enter a few times does not really solve it, because it moves the text within the same lane and still affects the surrounding layout. So this seems like a separate hard case: dense Free Text comments can cause collisions, and even Guitar Pro does not appear to provide a simple per-comment vertical offset or lane control for this situation. 
I also checked the Songsterr demo editor to see how this type of text/comment is handled there. It looks like Songsterr is using a custom overlay system that prevents these items from overlapping. The user-added text still attaches to the relevant musical area, but the UI appears to manage the vertical placement so comments do not collide with each other the same way they can in Guitar Pro or alphaTab/Vite. That may explain why Songsterr can keep these dense text/comment areas readable even when the underlying GP file contains a lot of note-attached annotations. This has been a few days of testing, comparing, and documenting, but I genuinely love alphaTab and everything you do with it. I hope all of this helps not just my project, but the whole alphaTab family. |
Beta Was this translation helpful? Give feedback.
0 replies
-
During the Guitar Pro exploration, I made an accidental discovery: Guitar Pro does support a “Before Tablature” tuning display. I am not sure when Guitar Pro added this, but in the screenshot I turned it on just to test it, and then turned off the track name so the tuning display could sit cleanly to the left of the TAB staff. I am not making this the main focus of this report, but it does seem relevant because it shows that Guitar Pro has a supported layout concept for showing tuning information directly in the left-side system area before the tablature. 
To make the tuning display line up cleanly with the rows underneath, I had to adjust the spacing here. In this test, I set the spacing to 6mm and turned Track Name Display off. That allowed the tuning labels to sit in the left-side system area without fighting the TAB label or pushing the row out of alignment. This is not the main focus of the spacing report, but it was useful to see that Guitar Pro has actual controls for this type of layout behavior. Tuning Display Before Tablature — possible reopen requestOne separate side discovery from the Guitar Pro comparison: While checking Guitar Pro layout settings, I found that Guitar Pro supports displaying tuning before the tablature. By enabling the tuning display and turning off the track name, the tuning labels can sit cleanly in the left-side system area before the TAB staff. I know we previously discussed tuning placement and it was closed as not planned. At the time, I may have framed it too much like a custom preference. This new Guitar Pro finding seems relevant because it shows that displaying tuning before the tablature is supported by Guitar Pro itself. So the request may be better framed as a Guitar Pro compatibility/layout option rather than a custom UI preference. I’m not trying to derail the P6 spacing thread, but I wanted to mention it here because it came up while comparing Guitar Pro behavior directly. If it makes sense, this could be moved into the earlier tuning issue or reopened as a focused request with screenshots. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Tuning display in staff was not closed, its in the backlog #2446 |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Daniel — we are using AlphaTab Page layout / SongBook notation for guitar tab.
We are trying to create similar note gap spacing Songsterr-like layout for a sparse guitar track with many empty/rest bars mixed with note-heavy solo bars. The reason is that with Songs that use heavy annotations and bends along with pick and finger slides, and even many tracks with lyrics the spacing becomes way too tight. And if there is fx comments above the notes in the overlay lanes (they don't make the bars longer) they tend to overlap and the same thing with lyrics on tracks as well that seem to depending a more note spacing. Not sure what math you use, but best way I can describe the spacing is ours might be about .3 cm to .4 cm for single notes and 8 note bars. But many of these gp files I am using rely on more of a .6 cm to .8 cm spacing.
The problem:
What is the intended AlphaTab way to:
Are there supported settings for:
Also, should systemsLayout be set on score, track, or masterBars, and does it require UseModelLayout before score load?
Here is an example in full screen where I got the stretchForce to increase the space between the notes, but it balloons the empty bars at the same time. So I am missing something here?
This one now on the Vite I did the same thing and made changes, but just as I get the empty rest bars small again, the note spacing gets smaller as well.
This one I cannot even explain what is happening here as the note gap I want is good on the first Row and M34-38 is what I am aiming for here, but then the next row the gaps are huge! So I have no idea what I am doing here! Clearly LOL
This is what we are trying to achieve something similar to this where I can fit up to 19 bars in row one on Full screen (15 when not in full screen) when they are empty rest bars like this. Having the 3/4 empty rest bar with a little extra spacing would be nice but it's not critical.
Here is one of the bigger reasons for the note spacing. Is many of the gp3 and gp5 and gp8 files the Lyrics when they are added under notes if the TAB was created by someone who used the wider spacing to add the lyrics when we load them up the overlap and same with fx comments and sometimes as well the Tempo Clusters and the Marker Section Names will overlap
So as you can see I am a bit clueless on how to go about this one!
Thank you for your help and guidance.
Beta Was this translation helpful? Give feedback.
All reactions