Grand staff rendering using AlphaTex

[gburlet]

Description

As a user I would like to be able to render notes on a grand staff using AlphaTex as input, for example piano music.

Possible Solutions

I believe that AlphaTab already supports grand staff rendering, however this is only available when rendering from GuitarPro format if I'm not mistaken.

Current Workarounds

Write the music data as GuitarPro and have AlphaTab render that instead.

@Danielku15 do you have any documentation available or can you point me to any detailed documentation that specifies what the format of a .gpx file is? I remember reading that it's a compressed file of some sort. In the meantime, perhaps I can write out the score as a .gpx file and have AlphaTab render that.

[Danielku15]

Thanks for your request. I think depending on your actual goal there are multiple solutions to the problem. Feel free to pick any proposal 😄

Proposal 1: Extend AlphaTab with Multi-Track and Grand Staff Support

Effort: Low. I could provide this by today.

I will need to come up with a good solution how to define multiple staffs and tracks in alphaTex. Luckily I lately restructured how the staff creation works to be closer to GP.

I thought of keeping it simple and use a simple bar-meta to start a new track or staff. They would simply need to be the first meta of a bar.

Like:

\title "Multi Track and Staffs"
.
\track "Piano" // First track start

  \staff{showscore} // first staff start (showscore, showtabs as flags) 
  \tuning piano
  \instrument  acousticgrandpiano
  c4 d4 e4 f4

  \staff{showscore} // second staff start 
  \clef F4 // grand-staff F4 clef
  c2 c2 c2 c2 

\track "Guitar" // Second track start
  \staff{showtabs} // tab guitar 
  1.2 3.2 0.1 1.1

Both tracks rendered would look like this:

Proposal 2: Creating Guitar Pro files

Effort: Low. No real AlphaTab development needed. Maybe some tech-doc effort.

Alternatively, if you prefer it that way, you could also generate guitar pro files. There are multiple possibilities if you can generate GP files:

1. You go for the "old" Guitar Pro 6 format which has some wierd GPX container. The best documentation I have is the comments in the code.
   If you go for the uncompressed container, it should be possible to create a write but I would not recommend this.
2. You go for the new Guitar Pro 7 format. It is simply a zip file containing the .gp files.
3. I could also simply accept a raw XML string containing the score.gpif (similar to MusicXML).

You only would need to study the score.gpif structure or my parser code to find out how to create proper score.gpif XMLs.

I could offer you both: Extending AlphaTex or you go for the GPIF XML in any container format. If you prefer GPX over the newer GP I could try to create an exporter code for you.

Proposal 3: Using JSON

Effort: Low. No real AlphaTab development needed. Maybe some tech-doc effort.

If you are using only the Web/JavaScript version of AlphaTab you could also hop on the JSON format. AlphaTab internally has a JSON exporter/importer which is used to transmit a score structure between the DOM-Thread and the WebWorkers.

The format is not really documented but I could also invest some effort there. It is basically the normal alphaTab model hierarchy without cyclic references and some extras (e.g. for tied notes).

Proposal 4: Providing a model builder

Effort: High. Providing all required operations as an API would need quite some time.

Last but not least I could also extend alphaTab with a better model builder API. It depends on how you or your users write the music sheets. I always thought it would be the first step towards a UI editor if I can provide some methods that allow creating and modifying the data model using a structured API.

Then you could use any of the existing APIs to export alphaTab for storage. Here I could also then start providing an export to more data formats.

[gburlet]

Proposal 1: Extend AlphaTab with Multi-Track and Grand Staff Support

Proposal 1 looks like it would suit my needs and also help out others in the AlphaTab community. I see you've already started on it, nice! The metadata structure looks good to me 👍

One outstanding issue preventing piano music rendering in AlphaTex is that tied notes are not supported for non-stringed instruments #206.

Proposal 3: Using JSON

This also looks interesting and I wasn't aware of this. It looks like it would be a good format to tap into all of the rendering potential in AlphaTab that isn't already available through the AlphaTex interface; for example, features that are implemented to read GuitarPro files that don't have a corresponding AlphaTex specification. It would be great to get some more information on this and see if it could be used as an alternative to AlphaTex.

Edit: I think I found the relevant code in the javascript source: alphaTab.model.JsonConverter.ScoreToJsonand alphaTab.model.JsonConverter.JsonToScore. I could use that to reverse engineer the file structure. Not sure how to tell AlphaTab to load this though.

Edit: I've used the functions I found to convert a few AlphaTab scores to the JSON format used by the workers for rendering. The JSON files look very detailed. My only worry with this approach is:

1. File bloat: a score that can be described in 4KB of AlphaTex becomes 1.5MB of JSON
2. Stability: the structure of AlphaTex hasn't changed much since I started using AlphaTab in 2014 or 2015. Given the amount of detail in the JSON file format, if modifications are made to accommodate new features the workers might not be able to render older JSON files. Do you think that's true?

[Danielku15]

Proposal 1 is more or less implemented and the docs are updated to reflect the new feature. I didn't check in detail yet if I didn't break anything but the new functionality is covered by tests.

For #206 I started to have a look already but the changes are not yet ready.

Looks like you already found all neccessary bits and pieces for the JSON conversion.

File bloat: a score that can be described in 4KB of AlphaTex becomes 1.5MB of JSON

The thing is that the JSON structure is a fully serialized data model. That means it contains really every property of the data model with name and value, that bloats. AlphaTex is obviously a lot smaller as it only defines the values beside the defaults. Maybe some compression (zip, gz) might help but obviously never that much like AlphaTex. I'm not sure if the JSON structure could be minimized in a reasonable way. I would definitly need to do more manual serialization and value checking to remove parts that are not needed.

Stability: the structure of AlphaTex hasn't changed much since I started using AlphaTab in 2014 or 2015.
As the JSON serializer is required to do a proper communication between DOM and Worker, it is always up-to-date with all features. AlphaTex got a bit feature-stale as I didn't get alot of feedback and requests there. So I was focusing a bit more on the GP functionalities.
I think there is not too much missing in alphaTex should be an easy task to extend the parts as needed. I'm happy to accept any requests and contributions (PRs) that might add missing parts.

[gburlet]

I'll do some QA on my end and report back 👍

[gburlet]

I rendered a few piano scores using AlphaTex minus the tied notes and the renderings looks great!

I did some QA and it looks like AlphaSynth gets a little confused with the grand staff. It sounds correct but the notes on the bass staff don't seem to be highlighted as it's played and the bar cursor often skips over notes or stops momentarily and then teleports to the correct position. I checked a guitar score and wasn't able to replicate the bug so it seems to be isolated to the grand staff. If you're unable to replicate on your end I can send over an example AlphaTex score or gif of what I'm seeing.

PS. I sent you an email

[Danielku15]

I did some QA and it looks like AlphaSynth gets a little confused with the grand staff.

Is this only happening with AlphaTex scores or also with Guitar Pro files. In general there are some known issues to me when it comes to multi -track/-staff/-voice cursor display and especially note highlighting. If you have some small alphaTex that reproduces the issue it would be great if you can sent it to me.

Depending on the findings it might be better to open a separate issue that covers the strange cursor display on those multi-* scenarios.

PS. I sent you an email

I saw the mail and answered you already 😉