Overview of work this week
I’ve looked at the existing issues reported on the Musescore bug tracker this last week, looking specifically at the below issues. I’ll talk about each one in turn.
#21732 – Multiple tempo text not imported correctly
This bug report describes the current situation of importing tempo markings in Guitar Pro files. At this current time of writing, the master branch largely ignores tempo markings for Guitar Pro related files. In general, initial tempo markings are supported for the beginning of the music but any tempo changes which occur later are ignored. There are two components to this, the first is importing the text marking, and the second is configuring Musescore correctly so that when playback reaches a bar with a tempo change marked it changes the rate of playback to match.
In my local copy of the repository this issue has been fixed for files in the Guitar Pro 3 format. I still need to write a test for that and then verify that Guitar Pro 4 and 5 files operate the same way and apply the work I have completed already to that. Nevertheless, familiarizing myself with the necessary part of Musescore has been completed and I expect that I’ll make a pull request this week which fixes this bug in all available versions.
#22898 – Signs of first and second endings on repeats (voltas) are lost in Guitar Pro files
I had been working on this issue last week, just before the GSoC students were announced, so I have continued work on this feature. Last week, I made a pull request which has been merged into the master branch of the Musescore repository such that voltas are understood in Guitar Pro 5 files. This week I have continued to look at that, and added the work for Guitar Pro 4 and 3 formats.
Note that different versions of Guitar Pro process voltas differently. In Guitar Pro 5 files, the bit sequence present in the file represents which repeat numbers that volta applies to. In the 8-bit sequence of numbers, each 1 or 0 represents whether each digit (1 to 8, reading right to left) should be used as a repeat number in that volta. For example, for the bit sequence 10010, the created voltas should have repeat numbers 2 and 5.
This is not the case in previous versions of Guitar Pro. In previous versions, these are represented as binary numbers. As this is the case, it is not possible to create repeat numbers in voltas which are not sequential. For example, it is not possible to create a volta which has repeat numbers 1, 3, and 4 – it must also include 2. Also note that volta numbers must be remembered, for if say in the GP4 format we create a volta at bar 2 with repeat number 3, and then a volta at bar 3 with repeat number 4, then we should generate repeat numbers 1,2,3 for the volta at bar 2 but just repeat number 4 for bar 3 and we should not reset the counter. There are cases in the GP4 files where the volta counter can be reset. These aren’t immediately obvious, and I’ve described this below.
If an opening repeat sign is present in any given bar, the volta counter is reset on the bar *after* the one containing the opening repeat sign. If a closing repeat symbol is detected in any given bar, the volta counter is reset only if the bar after the closing repeat symbol does not contain a volta. Otherwise, the counter is not reset. In the case where opening and closing repeat symbols are both used in the same bar, then the volta counter is reset on the bar after the one containing the opening repeat sign. The way that voltas operate was discovered with a fair bit of fiddling around with Guitar Pro and exporting and then re-importing the result.
Without any repeat signs, voltas are always numbered consecutively, even if that is not what the user has input. For example if in the Guitar Pro software the user has a volta on bar 2 with repeat numbers 1,2,4, and a volta on bar 3 with repeat numbers 3 and 5, then after the file has been saved and reloaded (guitar pro doesn’t stop the user from creating voltas with these numbers), the volta on bar 2 with have repeat numbers 1,2,3,4 and the volta on bar 3 will have repeat number 5 only. If the user had specified repeat numbers 1,2,5 on the volta in bar 2, as voltas must be numbered consecutively, the volta on bar 3 will be ignored, as the volta in bar 2 has repeat numbers 1 to 5.
Note there are strange occurrences when voltas are ignored. Consider the case where we have a volta which is ignored on the bar after an ending repeat symbol as voltas must be consecutive. Is the volta counter reset or not? In this event, the following takes place in Guitar Pro 4. The volta is ignored, and the counter is not reset as there was a volta after the repeat symbol. However, when the file is next saved, it will no longer contain the volta, and so saving and re-opening the file will mean that the volta counter *will* be reset. This means that in Guitar Pro for some score on the screen A, saving and loading can produce a different score B (where a volta is ignored but the volta counter isn’t reset) and saving and loading a second time will create score C (as the previously ignored volta doesn’t exist any more, the counter is reset)! Naturally, such a property is not something we want in Musescore.
For Musescore, we should just display the same as Guitar Pro. As we don’t have to export guitar pro files, we won’t suffer from the problems with saving and loading the file and getting a different result. That said, we should simply not display voltas with numbers which have already been used in previous voltas where the volta counter has not been reset, but we should not reset the volta counter, as technically a volta still exists and it simply isn’t shown. This will allow us to replicate exactly what is shown in Guitar Pro.
I have added a pull request containing support for voltas for all available versions of Guitar Pro, I imagine that will probably get merged some time this week.
#23077 – Copyright text not imported
It looks like this bug has already been fixed earlier this month, so I have written some tests for that so that we can close the bug report. Should be straightforward, nothing complicated here, I would think that I’ll push the tests for this in the next day or two.
#22436 – Note not heard
This is flagged as a Guitar Pro bug but I think the problem may be in a different area of the code base – the note seems to be imported correctly so I think we don’t have a way of playing that note on that instrument. It’s possible that the problem could simply be that we don’t seem to assign instruments to parts while importing Guitar Pro files. Any note above C_4 don’t seem to play, whether this is something that is indeed due to a bug in the import process is something I I have to check out. I’ll look into this further this week.
Key tasks that stalled
For the work on voltas, volta numbers do not seem to appear when running Guitar Pro through Wine so I lost a little time there. I have instead installed Windows on Virtualbox and and running the Guitar Pro software directly through that, which makes things a little easier for me.
With respect to the different versions of Guitar Pro, I also spent a bit of time looking into supporting formats earlier than GP3, to see if that is possible. From the searching I have done, I think it’s best to stick to the original project specification and support GP3 upwards, as versions of Guitar Pro that can read that format are unavailable for purchase, and there is no formal description of that format. The GTP format (used in Guitar Pro 1 and Guitar Pro 2) seems also to be almost entirely unused, so I shall likely be working on Guitar Pro versions 3 upwords during this project.
Upcoming tasks this week
I’ll be adding the tests for the copyright bug, so that can be removed from the bug tracker. I also plan to push the changes for tempo markings so that bug can be dealt with as well. The bug about playback discussed previously is also something I’d like to look into. If there is time before the middle of the week, which I expect there will be, I should be able to take a look at another couple of bugs.
This week, I also intend to go back to the Guitar Pro 6 (GPX) format and continue work with that, which I haven’t looked at for about a month since I started looking at existing bugs. There is quite a lot of work to be done there, but I would like to see some notes starting to appear on the staff so I can start thinking about making a pull request. I’ll go more into detail on that in the blog next week, by which time I’ll have re-familiarized myself with precisely how GPX files are composed and how we want to handle them in Musescore.