Problem
Currently alphaTab tightly couples the bar number display to the index of the bar. This works out for most normal songs but there are edge cases which are not covered by this:
- Anacrusis (Pick-Up bars) at start shift the first bar number
- MusicXML allows any out-of-order bar numbering (implicit bars)
Current Behavior
alphaTab allows customizing if bar numbers are displayed, but does not allow customization what actual number a bar should display. The number always follows the index.
Desired Behavior
alphaTab should allow customization of the bar numbers displayed. On any master-bar it should be possible to specify a custom bar number which is valid from that time on.
MusicXML even allows any custom text as bar number. (see number. we should follow the same practice.
Technically we will have to do some custom counting but allow overrides. e.g. if somebody sets 10 on masterbar[0] but nothing else, we should auto-assign 11 to masterbar[1]. For non-numeric customizations we do not increment, e.g. [0] = 10 (user defined) -> [1] = 'X' (user defined) -> [2] = 11 (user defined).
Likely we'll store the custom and actual bar number display on the data model as string.
We should not allow alternative numbering per track/staff, that would be confusing, its a masterbar info.
Formats
- Guitar Pro: Might have 1 Anacrusis Bar, shifts bar numbers by 1
- MusicXML: Fully flexible
- alphaTex: will need a new meta tag.
- Capella: to be checked
Problem
Currently alphaTab tightly couples the bar number display to the index of the bar. This works out for most normal songs but there are edge cases which are not covered by this:
Current Behavior
alphaTab allows customizing if bar numbers are displayed, but does not allow customization what actual number a bar should display. The number always follows the index.
Desired Behavior
alphaTab should allow customization of the bar numbers displayed. On any master-bar it should be possible to specify a custom bar number which is valid from that time on.
MusicXML even allows any custom text as bar number. (see
number. we should follow the same practice.Technically we will have to do some custom counting but allow overrides. e.g. if somebody sets
10onmasterbar[0]but nothing else, we should auto-assign11tomasterbar[1]. For non-numeric customizations we do not increment, e.g.[0] = 10(user defined) ->[1] = 'X'(user defined) ->[2] = 11(user defined).Likely we'll store the custom and actual bar number display on the data model as string.
We should not allow alternative numbering per track/staff, that would be confusing, its a masterbar info.
Formats