Overview of work this week
As last week, almost all of my time has been spent on the GPX format. Last week I wrote about the structure of score.gpif in little more detail, and described how parsing of that had been started, and measures had been created, albeit with no contents.
I decided at the start of the week to first sort out the information that was being parsed. I had some structure already to iterate through all nodes right down to the note/rhythm level, but this was not yet done in a place where notes could be added to the score, without storing this information in some way and then recalling it later. This was sorted out by splitting the parsing of score.gpif among different functions, each of which was called in the right place with respect to the initialization of other Musescore elements such as the creation of measures.
This being done, I proceeded to display the first note that was present in each bar. In the event that the bar started with e.g. a quaver rest, it would simply be ignored and whatever note came next was put in its place, but the length of that note was always created as a minim (as rhythm information was not yet available). If the bar was entirely empty the measure contained no information. This allowed me to check whether note creation was occurring correctly, and exposed a number of different issues. The main issue that it exposed was the tuning of the guitar strings.
The way that the tuning of the strings is represented in Guitar Pro 6 is in score.gpif as a list of pitches. A good few hours were spent playing with this, and it didn’t work right away, and if it was incorrect usually segmentation faults would occur. This transpired to be because the tuning that was parsed and set in one function had been somehow reset before I got to the part of my implementation that handled note insertion. After some bug hunting, the first note that occurred in a bar was placed at the beginning of a bar for every part, with the correct tuning in the tab part.
The next issue was sorting out parts which did not in fact contain any tuning information. As these parts are automatically created with tab staffs due to the pre-existing implementation, this caused segmentation faults when adding notes to those parts as they contained no tuning information (dummy tuning information had be used up to this point). The implementation was then modified to not create a link tab staff where it was unnecessary (e.g. for vocals parts).
With this in place, Musescore was then stable again and segmentation faults didn’t occur. My next avenue of work was with the rhythm information. This information was parsed correctly, and then the first note displayed in the bars discussed earlier were created with the correct duration. From here, I added support for rests, which in score.gpif are defined as beats with no note information. After that came handling multiple note specifiers, and then multiple beat specifiers. This created problems with the time signature, as time signature changes were not yet detected in the music.
After multiple beat and notes were supported and the time signature change issue was corrected, there were issues with tick to deal with. Playback was not happening correctly, and this was found to be an issue with (a) tick increment and (b) the time signature changes being used for playback. Both of these were corrected and now playback is fixed.
This means that in its current state, GPX files can be opened and notes from most parts (see below) are now displayed. This implementation needs a little polishing, which I’ll do next week, and then I’ll put in a pull request. The most important things that still don’t yet work are:
- Clefs. The clef of each part is currently set to the G clef. It it slightly concerning that no clef information appears to be present in score.gpif, and I think this might be computed from the Guitar Pro instrument database it has. If this is the case, I’ll need to check for each individual instrument reference in order to create the right clef. This is yet to be confirmed.
- Key signatures. This is currently set to C major and still needs to be imported correctly.
- Tuplets and dotted notes. No support for these musical features means that it is possible to have more beats in a bar than should be allowed (as a triplet of crotchets is simply imported as three crotchet notes).
- Percussive parts. This is related to the clefs issue, as it’s important to know what the clef is of each part. Some information from percussive parts has been imported, as is represented in the standard staff notation for now.
These are the more important issues. Importing features such as dynamics and slur information is for now considered less important as it doesn’t create “invalid” scores like the above too (such as creating 5 crotchet beats in a 4/4 bar). I intend to tackle the above issues first.
Some work has also been spent attempting to deal with the bends test issue that I discussed a bit last week. It looks like the issue is something related to the layout of bend information, as that’s what the stack track from GDB seems to indicate. I had hoped isolating that test from the others would allow me to locate the error, in the event that bad cleanup from previous tests was affecting the bend test, but this is not the case. I’ll be looking at that more this week, it may be the kind of task that is going to eat my time. If I can find the error behind that this week I’ll add a pull request in for it so that it’s out of the way.
Key tasks that stalled
Bends support is still on hold, I managed to get a little time to look into that at the end of last week but it’s something that I’ll be spending a good bit of time on this week if necessary.
Upcoming tasks this week
Cleaning up the implementation surrounding GPX support is something that I’ll be doing this week, as I wan to add a pull request for that and start getting things into the code base. I also intend to spend some time on the bends test bug, which I have the suspicion will take up time. I haven’t yet decided whether additional time this week will be spent implementing the GPX issues that I listed above, or whether I’ll go back and look at previous versions. A little of both might be nice – I’ll start with key signatures for GPX files and then perhaps do tuplets. For older versions of Guitar Pro, getting the fade-in effect supported might be a nice idea, as that symbol is currently not supported, so I’ll take a look at that too.