Overview of work this week
The main feature that I’ve been playing with this week is support for percussive staffs in the GPX format. Previously, no notes were imported from the percussive staffs at all. This stopped me from determining whether the code to produce tuplets in the GPX format was correct, as segmentation faults occur when the implementation attempts to make tuplets from notes which are not parsed.
To the large extent this problem has now been resolved, and we handle percussive staffs. There are still a few outstanding issue there, and I’ll discuss them here. The state of play at the moment with percussive staffs can be seen below.
There are some differences here, as Guitar Pro uses some different note heads. Nevertheless, it’s certainly a start. What I have done for the moment is to keep the implementation as it is shown above, at least for the moment. When there’s a good working system in place then it’ll be time to inspect this further, creating new note heads if that becomes necessary. At any rate, this work has been applied to all the staffs that were unsupported in the larger test case that I’ve been working on (Black or White). With this work in place, it was possible to take the work that I had done to parse triplets in the GPX format, modify it to fix corrections that needed to be made, and then insert that into the implementation of GPX import.
The remaining issue that was noticed was where repeated bars (simile markings) were used. As these were present in my test case, the score was not complete. This is now also handled in the GPX format, and such markings are placed in the appropriate places in the score.
With the above changes in place, for the full score I’ve been working on everything looks great. There are no articulations, slurs, slides, bends etc. but are the information that is somehow “core” such as time signatures, modulation, dotted rhythms, tuplets, notes of various lengths from all staffs now seem to be working. One thing in addition that does not work fully correctly is playback. The instrument chosen for all parts is just the default (piano), so that needs to be looked at as well. I expect there are possibly some parts that are supported in Guitar Pro but not Musescore, it might just be best to take the closest matching instrument in this case, but I’ll deal with that problem if and when it arises. Nothing new has been pushed on the GPX format yet but it could use a few hours spent refactoring it, so I’ll do that first next week and then prepare and make a pull request for that.
Some work has also been done looking at the fade symbol again, which I’ve come back around to now the GPX work is settling down a little. I’ve managed to get that symbol to appear in the master palette, but the symbol still cannot be placed on a note. Clicking and dragging the symbol on to the note certainly causes some layout processing (which can be noticed as other articulations move), but the symbol itself is not displayed. I’ve been following this process through to the relevant calls to QPainter as I considered whether an error was being returned from a painting function (which it isn’t – the ones we use are of void type), but when setting the string to be painted on to the score to a constant value, while everything else changes, that constant value does not appear when the fade symbol is added (via a shortcut) to the selected note. It seems likely that somewhere between the function getting called by the shortcut and the QPainter call the request to draw that symbol is discarded. I’ll need to follow that through the Undo/Redo machinery again in order to try and locate where exactly the articulation is thrown away / fails to render, then modify things appropriately. I expect this will be more difficult to find than it will be to fix.
I’ve looked also at bugs #21928 and #21938 which describe issues with beaming and missing stems in Guitar Pro files. These bugs seem to be no longer valid (the bug was filed about a year ago so it’s been fixed inadvertently by somebody, possibly me), but they did highlight a bug to me in the Guitar Pro 5 software where changing the capo has no effect on the fret numbers specified for notes. I’ve added tests to verify this – we display something different from Guitar Pro in this case as we take capo information into account. I’ll be making a pull request for these tests sometime this week.
I’ve changed the details of bug #22436 (where a note in the part was not heard), as it is principally related to the sounds that the instrument used in that part (Baritone Sax) were defined on. As one of the notes in there (D5) seems to be out of the range for a Baritone Sax, that might be closed as ‘wontfix’, but I’ll leave that for one of the main developers to decide upon.
Key tasks that stalled
Support for the fade-in symbol is somewhat stalling, but I seem to be making some headway with it. I’ll look at this a little more next week, I’d quite like to get this feature fixed and out of the way.
Overview of work for next week
Getting the right instruments used for playback in the GPX format would be quite nice, so I’ll take a look at that. Before that though I would like to refactor the code a little and document it, so that is probably what I will start with. There’s the fade symbol which I need to look at a little more also. After I’ve done that I’ll go hunting in the bug tracker again, there’s actually a few existing bugs surrounding percussion import (bugs #21899 and #22124), so some work on something like that would be good also, I’m not sure what kind of documentation Google need from me for the mid-term evaluations yet, so perhaps it’s time to look at that also. I expect it’ll be a short report and some code fragments. If that’s the case then that can be done next week so it’s submitted for the week after.