Initial GPX support, Tuples, Fades and Dotted notes

Overview of work this week

A number of things worked on this week, and tweaking of the GPX format.

Key signatures are now imported correctly into a Guitar Pro 6 (GPX) file. Modulation that occurs anywhere in the piece should also be detected and displayed correctly, so that should be all completed. There is still an outstanding bug related to key signatures on a different version of Guitar Pro (http://musescore.org/en/node/23519), and that’s something that I would like to clean up next week if possible. The Guitar Pro file submitted with that bug report is pretty large in size, I’ll try to narrow that down a bit if possible before attempting to fix that bug. I certainly prefer the structure of the new Guitar Pro format (GPX) than that of the previous versions, having the score.gpif XML file means that we can see exactly what we’re dealing with when developing.

Dotted rhythms are also supported, for all notes, in the GPX format. I wanted to fix this as it corrected the wrong number of beats in the bar issue that I get on the test case that I’m using during development, though it’s certainly still possible to get that issue due to the lack of support for tuplets. Tuplet support has been started but there’s something that needs to be done before it’s completed. In its current state, ChordRests are initialised when we encounter a new Beat description. Unfortunately, it cannot be done this way in order to support tuples, as each beat specifies some notes and a rhythm, and whenever a tuplet is present in the rhythm, only one note out of that tuplet is specified in the beat. I’m not sure why they have chose to do it this way rather than specifying all the notes in the tuplet, perhaps that adds for greater flexibility in the specification of other information such as dynamics within each note of the tuplet. In any case, I see what they’re doing for this now, I need to make an edit to the way that we handle beats in order to handle this correctly.

I’ve also looked at work on how the clef is specified, and we should see the correct clef now appearing in GPX files for each instrument/part. This includes the percussive staff, which I have also added some support for. I have added back in support for MIDI note specifications that are present in score.gpif now that this is the case. There is still a little work to be done here, as drum notes specified in the Guitar Pro file are not parsed correctly yet.

I have looked at support for bends in the other Guitar Pro formats. There are all kinds of bends that users can specify in their scores and we should have support now for the majority of these. The feature we don’t have support for w.r.t. bends is the “Hold” feature, Musescore doesn’t have a good way to represent this yet so that’s something that I’ll need to add in later. Probably this will be denoted via a dotted line over the held section (likely using a spanner in Musescore terminology). Bends can of course be held on to the next line of the score, so however spanners work when they are spanned on to a new line of the score is something that I’ll have to investigate later. I’m not going to continue further work on bends likely until later in this project, as it’s a relatively minor feature compared with the rest of the things that I need to implement support for.

The issue that I talked about last week with respect to bends has been fixed. For some odd reason, it was possible for a call to Ms::Bend:layout to exist where a score did not exist. This call was present only during execution of mtest (the test framework) and not when run by the user. Once the issue was located it was fixed with a simple conditional statement to check the existence of the score. Support for bends (minor support for holds) is now present in the Musescore repository.

The fade-in issue is something that I’ve also been working on. There’s a slot for this in the articulation & ornaments portion of the side palette, and I’ve implemented a shortcut for that for reasons of faster development, which is something that may or may not stay when I’ve finished doing that, I would think some kind of shortcut will stay. I seem to have hooked up everything that I can see by following the implementation of other articulations, such as marcato, though I’m not seeing the fade in symbol for this yet from the font. There’s likely a line missing somewhere that I’ll need to find. Representing a font symbol for fades is something that Guitar Pro does, but it’s conceivable that one day we might want to draw this with a bezier curve and represent it as a spanner so that it can span across multiple bars.

All of the work on GPX support has been cleaned up a little and merged with the current master, so now I’ve added a pull request for the GPX support this morning so that everything can get merged together and then I can add pull requests on top of that, this support will likely appear in the Musescore repository some time this week.

Key tasks that stalled

Nothing in particular, the primary thing I wanted to hunt down was the bend bug that’s was stalling the last few weeks and this has now been located and fixed.

Overview of work for next week

I’ll make any changes to the GPX pull request that need to be made before it’s merged into the master branch, it’s a fairly large chunk of code so perhaps some of the devs would like edits. Getting the fade symbol displayed in the palette is something that I would like to see done, as well as attempting to locate the source of error in the bug report concerning key signatures in key signatures in previous Guitar Pro versions that I mentioned. Tuplet support in GPX files would also be a good thing to look at, and then perhaps the bugs at http://musescore.org/en/node/22888 , http://musescore.org/en/node/23074 , and http://musescore.org/en/node/22110 too, which is also related to tuplets (in a previous version of Guitar Pro). It occurs to me that these issues with bugs in tuplets might be due to the same reason that my tuplets aren’t working in the GPX format – if ChordRest values are instantiated to rests they can be redefined, losing tuplet information (a possibility, but I’m not certain on that yet, will need some testing). If I get through all of that then I’ll spend the rest of the time adding more support for GPX files.

Continued work on the GPX format, and debugging bends

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.

Implementing initial support for the GPX format

Overview of work this week

Everything I have done this week has been focused on adding support for the GPX format, the format used by Guitar Pro 6. I wrote a little last time about the “score.gpif” file, and part of the time was spent determining precisely how the structure of the file is represented, and how we can extract the information we need into Musescore. I’ll give a discussion on this below.

The top level node of score.gpif is <GPIF> which has several children, namely <GPRevision>, <Score>, <MasterTrack>, <Tracks>, <MasterBars>, <Bars>, <Voices>, <Beats>, <Notes> and <Rhythms>.

• <GPRevision> simply contains a number which represents version information.
• <Score> contains meta-information about the score that has been created. Such information in here includes Title, Artist, and Copyright information.
• <MasterTrack> contains some information that apply to parts. This includes listing unique identifiers that are assigned to parts, the initial tempo, and other miscellaneous information.
• <Tracks> describes information about a given track with one of the unique identiiers described in <MasterTrack>. Information such as the instrument reference string that is used by Guitar Pro in order to initialise the correct instrument for playback.
• <MasterBars> lists information about bars, and this information exists in a specific ordering. Each child of <MasterBars> contains three nodes – <Key>, <Time>, and <Bars>. The <Key> node contains information such as a count of the number of accidentals (it is suspected this can be used to detect changes in key signature). <Time> gives the time signature for the bars listed in <Bars>, and can be used to determine changes in time signature. <Bars> gives a list of bar identifiers, all of which apply to a different part in the order they were defined in the <Tracks> node. This means that the number of identifiers specified in <Bars>, should be the number of bars in the music multiplied by the number of parts.
• <Bars> contains descriptions of individual bars, each of which have unique identifiers. Descriptions include the clef for that bar, and a list of voice identifiers.
• <Voices> contains a list of the unique <Beat> identifiers for each unique identifier for a voice. The beat identifiers that are listed will be all the beats that will apply to this voice, in the bar that this voice identifier was specified in.
• <Beats> describes a list of each <Beat>, each of which has a unique identifier, and details information such as the dynamic of that beat (as a string, P for piano, MF for mezzo forte etc.), a <Rhythm> unique identifier, a <Note> unique identifier and some other miscellaneous properties for that note. Note that the <Note> identifier may not be present – if it is not, then that indicates that a rest should take place for the duration described in <Rhythm>.
• <Rhythms> lists individual <Rhythm> values, each with its own unique identifier. Each contains a description <NoteValue> containing the duration of this <Rhythm> as a string, examples include “Quarter”, “Eighth” etc. In the test case I have, anything subdivided more that “Eighth” is then represented as e.g. “16th”, “32nd”, In addition to this, the tag <AugmentationDot> describes whether this rhythm is dotted, and if so the duration of the note should be multiplied by 1.5. A count of the dots is also present here, so notes can be “double-dotted”.
• <Notes> gives a list of individual <Note> values, each again with a unique identifier. Descriptions can be given here about whether a note is tied, whether a note should have a bend to apply to it, whether the note is muted etc. String and fret numbers are specified here among various other note-specific properties.

I am not considering absolutely all of the information specified in the file at the same time. My current goals with respect to support of this format is to get something stable and working, such as displaying all the notes in the parts with no additional (e.g. articulation) information and then add a pull request, and build on top of that. At the start of the week my goal was to create the correct number of parts, which some basic meta-information, as they were described in the file, and this was finished. I wrote a little last week about the problems I was encountering at the time with that, where clicking on any given measure would result in a segmentation fault, and I made the hypothesis that this was because there was no information in the measures, and this has indeed turned out to be the case. I verified this initially by creating rests in every measure of every part, and then starting playing around with the parts by adding notes etc. and things seem stable now.

After the issue with measures had been sorted out, I then started to look at the “score.gpif” file and determine how that information was all put together. The connection of bars to parts was a connection that was a little awkward to make, I had expected something perhaps a little more rigorous that simply depending on the order that the parts were defined in. Once this was correctly determined, I implemented functions to complete the parsing of the “score.gpif” file such that:

• The link from parts, to individual bars, to voices, to beats, and then to rhythms and notes was followed, so information exists in my local copy of the implementation about everything needed to add notes to parts;
• Warnings were generated for any XML tags that I simply skip right over for the moment (such as information about bends – now is not the right time to consider that level of detail);
• Information that was parsed was available in the right place in the implementation. This is still a source of work, as I gather up information about individual notes and rhythms at a point before they can be used. I do not wish to parse the file in any way a second time and I don’t want to hold the necessary information in an intermediate data structure, as I believe if things are structured correctly then neither of these will be required. This is going to be my starting point of work for next week.

In addition to this, I have spent some time familiarizing myself with how to add notes to specified measures, and give information such as duration etc, in the implementation. Given that this has been done, and information right down to the rhythm level has already been parsed as described above, after fixing the structure issues and getting the necessary information all in the right place with some kind of efficiency, there should not be much work left remaining before everything can be looped over correctly such that all notes are added to all parts, which is my current goal.

I haven’t spent any time this week on other Guitar Pro formats, such as fixing the issue with the test file for bends as described in my last entry.It might be the case that I’ll do that this week, it will depend on how progress is on the GPX format. It’s likely I’ll prioritize GPX support for the time being as I feel I’m making headway on that task and there is still more to be done.

Key tasks that stalled

The task which took longer than I expected to was understanding entirely the structure of the score.gpif file. Although most connections were immediately clear, such as the connection between bars and notes and rhythms, the connection between parts and bars was not so. Aside from this, nothing took particularly longer than expected. Adding support for other formats, such as fixing up the bends test so that it can be committed into the repository is something that I haven’t looked at this week. It’s possible I’ll get to that this week, if not, then certainly by the week after after some initial GPX support has been completed.

Upcoming tasks this week

As I’ve mentioned, I am going to likely be focusing on the GPX format. I would very much like all the notes in all of the parts to be displayed by the end of the week, and then the most difficult part of the work that’s associated with supporting the GPX format will all be done and out of the way. At that point I’ll be able to clean up and document the implementation so that others can get access to it, and then that will allow me to just focus on individual features, such as ties, bends, voltas, and other information.

Bends and GPX support

Overview of work this week

In the last post I talked about tempos and how the support for those were progressing. I have written tests to verify this feature is working as intended, and submitted a pull request for this feature which has now been merged into the Musescore master branch, so that bug is now closed as fixed. The support for voltas, which I mentioned last time I had made a pull request for, has now also been merged so that’s out of the way.

For the bug concerning the incorrect import of copyright text, tests have been created to verify this is done correctly and they are now also in the master branch of the Musescore repository, so the bug has been closed as fixed.

One of the areas I’ve been looking at this last week is support for importing bends. Bends are a common feature in Guitar Pro files, so support for this is important. There are various different kinds of bends that can be created in Guitar Pro (e.g. Bend/Release, Prebend, etc), all of which are now supported in the version I currently have on my local machine, including arbitrarily complicated bends. There is currently an outstanding issue with this work, and that is to do with the test framework. For some reason, the test files I have created are not processed correctly and the test framework fails – as there is nothing fundamentally different about these tests I presume that the reason for the problem is something specifically related to bends. I need to set aside some time to look into this error further, I expect I’ll do that this week. After I have managed to fix this issue with the test framework, I’ll push that to my fork on Github and add a pull request.

The other main task which I have spent time on is supporting the GPX format. GPX files are files which are compressed with a proprietary compression algorithm, and within that is a file system I have already decompressed the compressed GPX file, and extracted the files in the file system and dumped them to disk so that I can get an idea of what I’m working with. Most of the meta information is now handled (title, artist, etc), though there are some tags which aren’t supported yet as I need to figure out the right place to put them. My goal for the moment is to focus on just the notes themselves – details such as voltas and slurs etc. can be completed afterwards. This will allow me to get something that works to some extent, and is stable, into the master branch of the Musescore repository as early as possible. One of the files in the file system is an XML file named “score.gpif”, and contains the vast majority of the important information that needs to be processed. I have extended the implementation this past week to read instrument descriptions and create parts for them. Measure information is also handled, so we know how many measures there are in the score, and characteristics of those measures (such as clef and key signature), which is also extracted from the score.gpif file. There still is much work to do on the GPX format, and that’s what I’ll continue to look at this week.

I’ve also taken a look at the issue where fade-ins are not supported. I need to create an additional symbol in Musescore in order to do this. I think the best way to go about that is to make some kind of variation on hairpin.cpp, which describes how e.g. crecendos are drawn. Perhaps instead I want to use a bezier curve to describe the fade symbol. I intend to find time to get that issue sorted out this week too.

Key tasks that stalled

The bends feature is taking a little longer than I would like, that’s down to the problems in running the bends tests described earlier. I expect to work on that more this week so that this can get out the way.

There are a few issues also with creating measures in GPX files that’s taking longer than expected. Currently, clicking on measures which have been created makes a segmentation fault in Musescore. I’ve played about with this a fair bit, and I’m starting to think that’s because the measures have been created with no notes or rests, as that information hasn’t been parsed yet so I can’t fill the measures with the right information. If that’s the case, this should just clear up this week as I make progress with the implementation of support for GPX files.

Upcoming tasks this week

This week I primarily intend to continue working on the support for the GPX file format. My hope is that I can parse all the notes, rhythm descriptions etc. in the score.gpif files and display them on the score. I’ll look also at the issue with guitar fade-ins described previously, after the symbol is ready to use it shouldn’t be too complicated to finish off importing the Guitar Pro file correctly. The bends issue I also would like to get out of the way, as the support for that has been completed and I should just need to find a way around this problem that’s currently appearing with the test framework. I’d like to spend some time looking at some of the existing other issues too however, just so I know what’s around the corner…