Alternative endings for alphaTex

[jonaro00]

Hi,
Thanks for making this project. I'm having very fun playing with it.

The only feature (yet) I wish alphaTex had support for is Alternative endings to repeats. Would appreciate if it was added.
For reference: http://lilypond.org/doc/v2.23/Documentation/notation/long-repeats#alternative-endings

Perhaps the syntax could be:

\ro 3.3.1 | \ae 1 \ae 3 3.3.2*2 | \ae 2 \ae 4 \rc 4 3.3.4*4 |

but I haven't spend much time checking how the parser works and what it can realistically handle.

What do you think?

P.S. Is there a conventional file name extension for alphaTex files?

[Danielku15]

Indeed alternative endings are a missing feature until now in alphaTex. To indicate better the relation on repeats I would maybe rather go for a metadata tag like \re (repeat endings). Instead of requiring \re to be put in front of each ending, I would maybe go for a syntax like:

\ro 3.3.1 | \re 1 3.2.2*2 | \re (2 4) \rc 4 3.3.4*4 |

Looking at the overall alphaTex syntax, in many effects we use parenthesis to group multiple values. The parenthesis can be skipped if there is only 1 value. The parser is implemented a recursive decent parser and extending it should be usually quite simple, you can give it a try if you're interested into adding this feature. With a bit of reading you should be able to understand quite quickly how the logic works.

Example on how beats handle the parsing of either single or multiple values in parenthesis:
https://github.com/CoderLine/alphaTab/blob/develop/src/importer/AlphaTexImporter.ts#L1080

Place where the existing repeat metadata tags are handled:
https://github.com/CoderLine/alphaTab/blob/develop/src/importer/AlphaTexImporter.ts#L1775

The rest of alphaTab should already take care that the repeats are handled correctly. Of course if somebody would write messy repeats, alphaTab would behave like this too.

There is no file extension for alphaTex because I never envisioned it as format to be written into files, but rather to store it in databases or providing it easily through APIs. If I would need to think of one, I guess it would be maybe .atx or .atex

[jonaro00]

Very nice! Then this feature should be fairly easy to implement as you say 😄.

[jonaro00]

Hi again,

I finally gave this a try. Here is my commit: jonaro00@b4028a2

The main functionality of the feature seems to work. There are a few things on my mind that could be discussed before I write a test and Pull Request:

• Naming inconsistencies: Alternate endings (model) vs Repeat endings (suggested tag name \re). Do we keep it like this or use the same name everywhere.
• The following tex shows two unwanted(?) behaviors that might need some fixing:

// Multiple single \re tags (not recommended but works)
// Slide to outside of repeat gives incorrect slide target during 2nd repeat
\ro 1.1.1 | 4.3.4*4 | \re 1 \re 3 1.1.1 | \re 2 \re 4 \rc 4 2.1{ss} | 5.1 | r

// \re tags with parentheses working as intended.
// Alternate beginnings and endings... weird behavior
\ro \re 1 1.1.1 | \re 2 2.1 | \re 3 3.1 | 4.3.4*4 | \re (1 3) 1.1.1 | \re 2 \rc 3 2.1 | r

// Getting out of control: Alternate beginnings, middles and endings
\ro \re 1 1.1.1 | \re 2 2.1 | \re 3 3.1 | 4.3.4*4 | \re 1 1.1.1 | \re 2 2.1 | \re 3 3.1 | 4.3.4*4 | \re (1 3) 1.1.1 | \re 2 \rc 3 2.1 | r

The first example is pretty unrelated to this feature.
The second and third example skips over the middle bars during the first and second repeats. Not sure what causes this. Is this intended (are alternate beginnings even a thing)? Is the issue in my code or elsewhere?

[Danielku15]

• Naming inconsistencies: It would be indeed better to talk about "alternate endings" and use a tag like \ae. As we already have \ro for "Repeat Open" and \rc for "Repeat Close", it would be confusing where the difference between close and ending is.
• I would recommend adding tests for those examples so we can continue on this base. For the issues with the wrong repeats you might want to take this test as a reference:

  alphaTab/test/audio/MidiPlaybackController.test.ts

  Line 58 in 478679f

  it('repeat-with-alphaTex', () => {

  It would allow you/me to debug very scoped why maybe an expected repeat order is not generated.

Alternate Endings can be very tricky and there might be combinations possible that don't result in any meaningful playback order. The commit already looks fine from the general extension of the parsing. 👍

Plus: what I like to do in case of doubts on the right behavior is to create the same file in Guitar Pro and double check the behavior and data model which is parsed. Sometimes there are small details on the data model consistency which are easy to miss unless you have the full overview.

[jonaro00]

I corrected the naming and added two tests for the \ae tag.

For the PlaybackController, I quickly copied the mentioned test case to investigate the weird behavior (bars getting skipped) when alternate "endings" are not at the end of a repeat. I would appreciate if you verify that the behavior expected by my test is indeed the expected behavior when using \ae in such ways. The current fail is:

...which is weird, since the test above passes just fine.

I can't think of any combination of alternate endings that would be "unplayable" yet. This sequence

\ro 1.1.1 | \ae 1 2.1 | 3.1 | \ae 2 4.1 | \rc 2 5.1

is of course weird to have written, but in my opinion it should be playable in the order (by fret) 1 2 3 5 1 3 4 5, but currently it plays 1 2 3 1 4 5...

The commits: https://github.com/jonaro00/alphaTab/commits/develop
Tell me if I should Pull Request at this state.

[Danielku15]

Best would be if you create already a draft Pull Requests. This would allow me to have a closer look.

[jonaro00]

Another related feature request that can also be used to help show & verify the repeat functionalities is "Unfolding" repeats (can be seen in the lilypond example previously linked). This would probably be best suited as an api.settings property, right?

[Danielku15]

Indeed this would be also a new feature which is likely controlled through a new api.settings property. Hard to say at this point how to realize it best but it is likely quite a complex feature despite it's simple result. The key point is that suddenly individual model elements like notes, are rendered multiple times. alphaTab expects elements to be unique on some levels and this unfolding would break the current expectations. Relations like next/previous beats (like for ties/slurs) which are kept within the data model are broken/changed during rendering.

One way to solve this could be to pre-process the input Score and create a new Score which has repeats unfolded within the data model itself like it would have been written without repeats. This keeps the rendering logic as it is and only introduces this preprocessing step.

[jonaro00]

Sounds good, I would have guessed the solution would look something like that.