Update to status of Guitar Pro support

I submitted a pull request this week with the edits that I described in my entry here last week (and some additional edits), and most of my time has been spent resolving any outstanding issues that existed with that. That’s now been merged.

The master branch of Musescore should have support now for all Guitar Pro import features, so feel free to test it and report any bugs that are found. Officially the GSoC pencils down date is set for tomorrow, but don’t worry I’m not going anywhere; I’ll still be around to look at bugs and make additional fixes. The testing I have done has been primarily on smaller, toy scores rather than large complicated ones, but there shouldn’t be too many problems on larger scores and as I’m practicing on my own (larger) guitar scores I dare say I’ll spot any problems myself too during guitar practice. 🙂

I’m going to spend a little time this week running as many Guitar Pro scores I can find through Musescore and looking for any bugs that might exist. Any issues found I’ll tackle in order of severity. If anybody does happen to find an issue, please do report it here: http://musescore.org/en/project/issues. I’m automatically notified when bug reports are created with the words “Guitar Pro” inside so don’t worry, they shouldn’t slip past me. Feel free to talk to me about specific bugs too, I don’t bite – I’ve had people e-mail and tweet me about bugs/questions/comments in the past, so use whatever medium you prefer (for specific bugs though, the Musescore tracker is preferable as it leaves the information open to all developers on the project).

Current status of Guitar Pro import

Overview of work this week

This week has been focused on finishing unsupported features and generally tweaking different parts of the implementation. Here’s a brief overview:

• Copyright statement import modified to import text verbatim;
• Finished support for tremolo bars;
• Fixed centering of empty bars in Guitar Pro 5 which could in  some cases still contain rests which weren’t centered;
• Some imported values such as reverb and volume at set to a default value of 0 if not specified, and not 255 as specified by Guitar Pro which wasn’t compatible with Musescore (some 0-127 ranges);
• Slides modified so that the user can vary the length of the slide, and updated drawing mechanism so that the bounding box was computed correctly;
• Modified certain Guitar Pro articulations so that they will always appear above the staff and never below it (e.g. vibrato, fade symbols);
• Fixed arpeggio and brush confusion on import;
• Logic fix to drumsets so we always use the drumset we specify.

There is an edit to be made to drawing of “free time” time signatures and some other minor tweaks that will be made (see below) before I can send in a PR with all the latest changes, I expect to put that in either today or tomorrow.

Key tasks that stalled

None.

Overview of work for next week

There should now be machinery in place now for all features that can be specified in Guitar Pro (which will appear in the Musescore master once I’m finished editing the free time spacing). There are a couple of other things I’m still looking at also, so here’s what I’m planning to do:

• Fix free time spacing of parenthesis;
• Fix key signature warnings (they are correct but we still get warnings – they are specified multiple times in different places of the score file so I think they are being imported multiple times. We should just not import them again);
• Verify fingering layout. Fingering::layout() was removed recently and I need to check whether that affects my implementation. If so I’ll need to sort that out.
• Testing.

I’ll be using tomorrow and hopefully some of today to get through the first three points of the above list. At that point I’ll be just testing the implementation with large Guitar Pro files and checking the results (fixing problems as I go along) and documenting the implementation to a larger degree. I have a week to do this so there should be time to make additional fixes to various features. I know there are some people on the mailing list waiting for the latest features to go in, I’ll send a message on the mailing list when it’s available.

Further unsupported features

Overview of work this week

Spent most of my time this week adding support for any unsupported features I could find with respect to Guitar Pro import. There is support now in my local branch for the following new features:

• Directions.
• Vibrato. New symbols were needed for this and they will be found in the master palette. All symbols were defined in SMuFL so no big issues there.
• Volume swell. Just a single new symbol needed for this, defined in SMuFL so that’s now all fine. I’ve used the older version of FontForge to avoid breakage for Windows users this time.
• Free time. Parenthesis are added around time signatures, the current bar gets a double bar marking and some text appears above the bar indicating that it’s to be played in free time.
• Slurs. Solution tweaked and made the tests, so nothing more to do here.

I’ve also merged the slide branch with the GPX support branch, so that’s out of the way, and modified slightly the way that key signatures are handled during import as sometimes there were warnings about duplicate key signatures. I’ll continue to test that this week.

A bit of refactoring has been done also, I’ll be continuing that this week so that it’s cleaner and easier to document. I’m leaving most of the documentation work (though some has been done as I’ve been going along, but may need updated) until the last week of GSoC the next week, I want to focus right now on having all the features handled, but we’re almost there on that anyway.

Key tasks that stalled

None.

Overview of work for next week

This week, my main goal is to finish support for the only missing feature that I have on my list – tremolo bars. I have already started work on this so I’m going to finish that off. I’ll also take a look at key signatures again and check that there aren’t any more warnings generated there. There’s also a tweak to be made to the way slides that operate on a single note are drawn, as currently they look odd when placed in the master palette. I’m hoping I can take care of all of these. I’ll then look again at the original Guitar Pro software and check that there aren’t any features left that are unsupported, adding any I find.

I think it would be good to check also that any features that have been added are working in all versions that support them. Sometimes it’s not immediately obvious whether a feature is backward-compatible. I’ll take a look at this once tremolo bars are done. In any case that shouldn’t take too long, as once tremolo bars are completed then all the machinery should be there.

Some testing with larger test files would be good too – often with new features the scores are toy in size rather than something very large and rich with features. No doubt there will be at least one thing to find and fix there.

Ghost notes, ottava markings, and other unsupported Guitar Pro markings

Overview of work this week

I’ve completed about half of the features that I listed as incomplete last week. Ghost notes, ottava markings, natural harmonics, slides, fermatas and rasgueado markings have all now been supported. The most awkward of these to implement were fermatas, which were described in the MasterBars portion of the XML file and were notated by how many occurrences N of some time division T has occurred after the start of the described master bar which is somewhat awkward. In any case, that’s out of the way now.

I’ve also been working on several of the other features which are not yet supported. My aim is to complete support for these by the end of the week. That will leave a week to bug shoot and hunt out any features that have slipped through the net, and then a further week to test anything that isn’t tested and refactor/document the code, so things seem to be going right on schedule.

The following features are currently unsupported:

• Slurs (GP6 only – needs testing).
• Free time (almost complete & needs testing).
• Volume swell (symbol in SMuFL – should just be a case of adding the symbol and then annotating the necessary notes).
• Directions (in progress).
• Vibrato. This uses some special symbols, though they look standard enough to be in SMuFL (I’ve yet to verify that they are all specified).
• Tremolo bars.

Slurs and volume swell I will tidy up when I merge my current GPX features branch with the slides branch after it’s merged. I’m working on rebasing that branch and I still need to look at an issue there. These should not be complicated features.

Free time is a feature that I have been working on that’s almost complete, and I’ll be starting with that tomorrow after the rebase is all sorted. I’ll also try and complete support for vibrato.

Directions don’t seem to be too complicated, but tremolo bars are more so as they carry with them a high degree of user customization. I’ll be leaving these features until after the other four have been completed. I’ll see if I can finish these this week also.

Key tasks that stalled

None.

Overview of work for next week

To finish the remaining unsupported features in the bullet list above. When these are complete, if I have further time this week I’ll look at the GP5/GP6 software again and look for any features that may be missing. If I can’t find any, I’ll look at the way instruments are handled during playback, I did some work towards this but I don’t think all instruments are handled and so some don’t sound similar to Guitar Pro playback. There’s also testing to do, another refactor of the implementation would be a good idea afterwards, and hunting for any bugs in the implementation, along with testing the import of much larger scores and looking for any issues there. I would think I’ll be able to get on to some of that this week, and most of the bug shooting and other testing will likely be done the week after.

Further features, and updates to slides.

Overview of work this week

I’ve added further missing features to the GPX format, including palm mute, artificial harmonics, barre annotations, let ring annotation, tap, slap and pop markings, and text markings. I’ve also started support on a few others (see the bullet pointed section lower down).

I’ve also taken a look again at the representation for slides and moved the implementation for slides which operate on one note to use the ChordLine mechanism. I have just added a straight property to ChordLine values, which if set to true will create a straight line denoting some kind of slide (various kinds of available slides were discussed in a previous post).  Legato slides are also now working properly. The framework for legato slides also borrows from the slur machinery, and so there is now also partial support in the GPX format for slurs. Slurs are something that I will be implementing fully this week.

I’m preparing a pull request for the slides feature at the moment, and as this is branched from (an older version of) the GPX work branch, this pull request will also contain some new features relating to GPX that have been discussed previously, up to the point where I started working on slides. This will include the guitar pro implementation being split up into various separate files. When the slides PR is merged I’ll do the PR containing the rest of the work I have right now on the GP6 format so others can play with it as they wish.

The current list of features which are not supported in at least one version of Guitar Pro are:

• Slides (possibly complete, needs further testing).
• Free time (in progress).
• Ghost notes (needs testing).
• Fermatas.
• Ottava markings for individual notes.
• Directions.
• Natural harmonics.
• Rasgueado.
• Slurs (in progress).
• Tremolo bars.
• Vibrato.
• Volume swell.

The longest of these to implement will probably be natural harmonics (if I remember correctly new symbols are needed for that) and maybe also fermatas (due to the way they are represented in the files).

Key tasks that stalled

None this week.

Overview of work for next week

Again, I’m just to add support for as many of the missing features that I can, and finish of testing then push support for slides.  Free time and ghost notes I would like to finish, along with slurs. The rasgueado marking should be straight-forward to do, and the ottava markings I would hope wouldn’t take long either. After those I’ll likely target volume swell, directions, and vibrato if there’s time.

Further support of missing features

Overview of work for this week

An issue was detected with the TTF files that were regenerated to add in the fade symbol, turns out that the latest version of FontForge has some issues with generating TTF files. Regenerating with an older version fixed the problem. I believe there’s an issue related to this on the FontForge bugtracker so until it’s fixed we should avoid the latest version.

I’ve been focusing on features which are in Guitar Pro 6 which are not yet supported, and then supporting those in the previous versions where necessary. I’ve implemented the following features in Guitar Pro formats that handle them:

• Double bars.
• Trills.
• Crescendos.
• Dead notes. These are in previous versions of Guitar Pro too but support for those has already been completed.
• Wah open & Wah close.
• Mordent & Inverted mordent. Confusingly, an ‘inverted mordent’ in Guitar Pro is a ‘mordent’ in Musescore and vice versa. I’ve edited the previous implementations so that we show the same symbol that is present in the Guitar Pro software.
• Pick up & Pick down. These are represented using the up bow and down bow markings in Guitar Pro so thankfully we don’t need any new articulations for this.
• Legato notes. Legato notes is a concept in Guitar Pro 6 that just uses slurs, and I wouldn’t really call that a new “feature” as such.
• Dynamic markings (ppp, pp, … fff). I’ve also rewritten the way that we handle dynamics to clean that part of the implementation up.
• Left and right handed fingerings.
• Arpeggios. Note that I’ve modified the existing implementation and a test for this that confused an arpeggio with a brush stroke (understandably, the two are highly similar).
• Brush strokes.
• Diminuendos.
• Voltas. These are *much* better represented in Guitar Pro 6. What took me about a day for Guitar Pro 5 because of its gotchas took me 15 minutes with the Guitar Pro 6 representation. Hooray! \o/
• Repeat bar markings.
• Grace notes (on and before the beat). If I remember correctly a test was commented out on the latest master so I think the implementation has changed. I’ve yet to bring that up to date but I’ll be dealing with that soon.

I’ve also been looking at fermatas but those aren’t implemented yet. Fermata location is specified by how many divisions occur after the start of the bar it is, given some time division. For example, a bar in 4/4 time with two minimins in it with a fermata specification on the second minim is specified as 2/1, with the 2 indicating counting in minims and 1 indicates the second minim (counting from 0). This is going to be a bit clunky to parse given how it’s represented, but I’ll take a look at that this week.

There are a number of extra markings to support which are text-based in nature (let ring, pop, slap, tap, directions, ottava markings on specific notes, etc). I’ll try to get as many of those as possible sorted out this week.

I haven’t done any further work on the slides, I’m going to push the support I have in a branch for slurs and then after that I’ll merge that in to slides, edit the representation to be a variation on e.g. fall rather than existing in the glissando machinery, the I’ll make a PR for that. Once those PRs are in I’ll do a PR for this work on the GPX format that I’ve been working on in the last weeks so users can test it.

Key tasks that stalled

None this week.

Overview of work for next week

I’m going to take a look at the text-based annotations as that’s where the bulk of the work right now remains, at least one of the harmonic markings and fermatas. I’ll make the pull request for slurs, then merge that into the work for slides and edit that implementation so that we don’t require bigger edits to the implementation on glissandos and make a PR for that. When the PRs for existing bugs on the bugtracker are done I’ll push the current support I have for GP6.

Slurs, slides, tags in Guitar Pro 6, and empty segments

Overview of work this week

Last week I wrote a bit about the slur functionality I was working on, and had a solution which needed further testing. I’ve now done all that and edited the solution a little as appropriate, which handles the case that was highlighted in bug #22128 which caused that bug to be re-opened. We should now be able to close this bug. The issue here was that Guitar Pro has different ways of representing slurs/hammer-ons/pull-offs, and one of these cases was not handled correctly causing some cases to fail, but it’s fixed now.

Most of the time this week has been spent looking at bug #22604, which describes the situation we have where slides are not imported. Guitar Pro specifies six kinds of slide, and I’ll talk a bit how I’ve implemented support for these below:

• Shift slide. This is represented as a glissando with a straight line and no text, which works great.
• Legato slide. Displayed the same as a shift slide but with the addition of a slur. I have not implemented support for this kind of slide yet, as we do not currently have support for slurs in Guitar Pro 6. This will be one of the areas of work I will look at next week.
• Slide in from above. A line with a negative gradient placed to the left of a note. The way rendering is done for this and the following three kinds of slides above is a variation inside glissando.cpp, as it made sense to keep all the slide implementation together. To create the straight glissando in the previous cases, we take the start and finish notes, add rotations to the painter to take into account the difference in pitch, then draw a straight line equal to the length of the hypotenuse from the information of the difference in width and height of beginning and end notes on the score. With these slides, the gradient of the line is constant, and there is only one note which is affected, and so the only variable in the angle of straight gissando is what kind of slide we are drawing, rather than pitch information of the affected note. Rotation in the painter is only done after we have checked whether we are drawing these kinds of slide, otherwise we draw a straight line with a positive gradient, or negative gradient, beside whichever note is annotated with such a slide. This is all now implemented.
• Slide in from below. A line with a positive gradient placed to the left of a note. This has been implemented in a similar way as described above.
• Slide out upwards. A line with a positive gradient placed to the right of a note. This has been implemented.
• Slide out downwards. A line with a negative gradient placed to the right of a note. This has also now been implemented.

The vast majority of this is done now for all available formats including the GPX format, and I’ll be able to finish this off once I’ve added support for slurs in Guitar Pro 6.

In the GPX format I’ve also made some edits to reduce the number of warnings that I print to stdout when I encounter any nodes I don’t handle (by either handling them or ignoring them as necessary). I haven’t added any new functionality with the exception of slides to this format, and testing the grace note and slur implementations which are now complete (though recent changes to the master branch may mean that I need to look again at grace notes). I’ll be spending more time on adding new features to this format this week anyway when I add support for slurs.

I’ve also spent a bit of time hunting down empty segments that were being generated in the Guitar Pro 5 (and below) formats. It transpired that we are importing empty segments as that’s actually what’s specified in the file, as Guitar Pro 5 allows this. We don’t want these in Musescore, so I’ve added invisible rests to fill any segments which are empty in order to fix this problem. In cases where the bar is at the end of the score, there are some cases where empty segments are created outside of the score, in which case we simply ignore such segments and just remove them from the score.

Key tasks that stalled

None this week.

Overview of work for next week

I’ll take a look at slurs in the Guitar Pro 6 format and get them completed. From there, I’ll finish support for slides by adding in the legato slide, and that will fix bug #22604. After this, I’m going to look at the previous versions of the Guitar Pro and try to find other things to handle, as I’m sure there’s still a few features which aren’t implemented yet (slap & pop for example?). After building a full list of things still to be handled in those versions I’ll start working through that list, and adding further support to Guitar Pro 6 as normal. I’ll also take a look at grace notes and if the way that they should be implemented has now changed I’ll modify the Guitar Pro implementation appropriately.

Slur creation in GP5 and below, Centering of Empty Bars, and Further Development on GPX Support

Overview of work for this week

This week I’ve been doing my usual blend of fixing a few bugs which have been flagged against the previous versions of Guitar Pro and enhancing the support for the GPX format that I’ve been building. Last week I highlighted three issues that still remain with the older versions of Guitar Pro. One of these was a bug concerning the centering of empty bars, which looked somewhat awkward when some Guitar Pro files were loaded. This bug has now been fixed, it was a problem localized to one version of Guitar Pro, I’ll make a pull request for this.

A second bug involved slurs. This bug is triggered in older versions of Guitar Pro only, as Guitar Pro 6 does not make a distinction between a hammer-on and a pull-off and just represents this as a slur with no additional annotation. I’ve been looking at this bug and I think I’ve found the correct way to fix this, given the slight variation in how the format is composed – I still need to test more thoroughly the solution for this, as I’m not sure the current solution will work in all cases. I’ll be looking at this again this week and will see if I can finish that off.

The other bug that I mentioned last week described slides not being imported. I haven’t looked at this yet in all that much detail, but I expect that I’ll be looking at that this week and finding a solution for that.

Other than the above, I’ve been working on the Guitar Pro 6 format, where I’ve spent most of my time this week. I’ve added some support for certain articulations (marcato, fermata, and a few others), and been working on the drum set, which is now almost complete. Guitar Pro 6 will split certain percussive notes into their own parts and change the standard 5 line staff into a staff with an appropriate number of lines. I’m trying to replicate this behavior exactly, and there are a few more details still to work out. I’ll do that this week also. I’ve also added some support for some dynamic markings, which largely work but I still need to check that the implementation doesn’t ever repeat dynamic markings unnecessarily. Grace notes are something that I’ve also been implementing, in addition to ties. I’ll need to test these features further before submitting a pull request with these updates, which I’ll also do this week. There are some cases where grace notes are failing to be created, I’ll need to look at the score files to find this case and fix any issues up, that should be done this week. I’ve improved support too for the way that notes are created and moved them to a later point in the implementation when parsing score.gpif (the Guitar Pro 6 score file), the reason for this this is by doing it this way it makes it easier to add articulations and other information to notes (less flags need to be created so mark out certain properties on notes which need to be taken into account during note creation).

I’ve also split up the implementation for Guitar Pro support into a few different files, as having everything in one was becoming cumbersome.  Guitar Pro 4, 5 and 6 support is in importgtp-gp{4,5,6}.cpp and the rest remains in importgtp.cpp.

Key tasks that stalled

No development is stalling this week.

Overview of work for next week

I’ll look at finishing up support for the slur bug and see if I get the slide notation implemented. Once these are done I’ll spend some time looking at the older Guitar Pro 5 software and trying to find anything we don’t support yet but that isn’t listed in the bug tracker, as I imagine there will be some there but we certainly already handle the vast majority of features, so work on older formats should start focusing on testing rather than new development some time soon. I’ll also continue development of Guitar Pro 6 support. I expect the drum set support will be completed, and I’ll add support for more articulations, do some tweaks to the implementation for grace notes so that it’s correct for how Guitar Pro 6 represents them, do some further testing, then pick another unhandled feature and work on that.

Drumsets for Guitar Pro and Font issues

Overview of work this week

Last week, I wrote about doing the chord diagrams and improving the playback support in the GPX format, and remarked there was more to do on the percussion parts with respect to getting good playback. This is what I’ve been working on this week, including fixing the way that wrong notes can be mapped in the previous versions of Guitar Pro.

There are currently three bugs which exist related to percussion issues in Guitar Pro, bug #21899 which describes a problem where some of the notes in the drum parts differ from the notes which are specified in the full score, bug #22124 which describes the issue where drum notes can be placed on the staff at an incorrect location, and bug #21731, which states that some Guitar Pro drumset notes cannot be exported correctly to MusicXML format correctly.

The approach I have taken to this problem is to construct an entirely new drumset for Guitar Pro. It was decided at some point this week that separate drumsets should be built where necessary for different versions of Guitar Pro so that the user will not notice differences between the Guitar Pro software representation and the Musescore representation with respect to drum parts. This being the case, two drumsets will need to be created. One will be done for Guitar Pro versions 5 and below, but a new one will be needed for the Guitar Pro 6 format (which actually represents percussion parts a lot better than Guitar Pro 5 does).

Most of the work has been completed here, and is entirely complete for the Guitar Pro 5 format. This work fixes the three bugs mentioned earlier. I’ll put in a pull request for this probably towards the end of the week, I have other pull requests to submit first. I’ll do some work looking at doing this for the Guitar Pro 6 this week too. Now I know what I’m doing there it shouldn’t take too long.

The issue with the fade symbol has also been fixed, the issue was that different fonts are used for displaying the score and for displaying the master palette. I’ve added the symbol to the font we use  for displaying the score and to the other font we have in the repository (Gonville). I’ve put in a pull request for this and that symbol should start showing up soon in the Musescore repository soon.

A pull request from last week has yet to be submitted on the GPX format, that’s next on my list to put forward. I might just put the drumset changes for GP5 and below in first, then put more into the GPX branch for drumsets meanwhile. Either way this should get submitted this week, I don’t expect GPX drumset support will take the whole week at all.

Key tasks that stalled

None at this time.

Overview of work for next week

There are still six bugs open which flag problems against the older Guitar Pro formats:

• Bug #24216, where the symbol representing an empty bar is not centered.
• Bug #22604, where slides are not imported.
• Bug #22128, where hammer-ons, pull-offs are not imported.

The work I’ll be doing next week will include one from that list, hopefully I’ll fix #24216 and start #22128. I’ll be working on the Guitar Pro 6 drumset issue also. If I get through all that then I’ll start #22604 if there’s time remaining.

The three bugs which I’m not looking at yet are:

• Bugs #22041 and #22438, which discuss issues with lyrics displacing other elements on the score. These may not be Guitar Pro import issues, unless we decide to import the lyrics as staff text, in which case there will be something to be done here.
• Bug #23054 which shows that beaming is different in Guitar Pro to Musescore. I’m not sure whether this should be closed as ‘by design’ or not. I’ll talk to someone else in the project before looking at this or the previous bug.

After these six have been resolved one way or another, I’ll go hunting for other features we don’t import for older versions of Guitar Pro files as I’m sure there’s at least one or two, and shift focus to the GPX format as there’s lots still to do there (I don’t think I’ve added any articulations yet for example). I believe the mid-term reviews are also due this week, so I’ll get that out of the way when it comes out tomorrow.

Refactoring GPX, Playback on Guitar Pro files and Chord diagrams

Overview of work this week

The two main items that I’ve been working on this week are concerned with the playback that happens in Guitar Pro files, and dealing with chord diagrams as described in bug #21927.

Firstly, I re-factored the implementation concerning the GPX format. As implementation develops it’s always nice to do this so that things don’t get untidy. Things have been moved around a bit, and there’s likely further improvements to be made here, but as the GPX implementation is still undergoing quite a few changes I’ll likely be doing this again in a few weeks’ time.

After this, work on the playback was started (initially, this is for the GPX format only). I’m attempting to take the instruments that Guitar Pro uses, and find Musescore equivalents for playback. In order that something is working, I’ve focused on the test case I’ve been using (Black or White), which has 10 instruments in it. Now that I’ve worked out the best way to do that for the instruments in the part, applying that to the rest of the Guitar Pro instruments should not be difficult. I plan to implement some kind of complete mapping from Guitar Pro instruments to Musescore instruments, which can be done by creating a Guitar Pro file with one part per available instrument (there will likely be quite a number of these) and then finding equivalents for each. In most cases this is working well, but playback of percussion parts is quite poor, as several bugs are open which are flagged as Guitar Pro import issues. These are bugs that I will be taking a look at in the near future, likely next week. This is not the case for all percussive parts (for example, the Bell instrument works perfectly fine as written), but this issue likely pertains only to the drum kit instrument.

The other main part of the implementation that I’ve been looking at is chord diagrams, as there is currently no support for importing these as described in bug #21927. This has effectively been completed, and support has been done for all the previous versions of Guitar Pro, but also the Guitar Pro 6 format also. I have a pull request in for that at the moment, so I would imagine support for that will appear in the repository sometime in the next week or so. There is a possible area of improvement here so I may revisit this, and that’s to do with barre chords. These are represented in the Guitar Pro files with distinct string identifiers with common fret and fingering numbers. In its current state, we do not draw the horizontal line that is sometimes drawn in this case to indicate a barre chord. It would likely be a few minor edits in the way that we paint fret diagrams, so that’s something I can do at the start of next week if we want that drawn in Musescore. It’s largely a matter of taste, so whether or not we want to draw that yet I’m not sure, if any others want that then I’m happy to implement it.

I’ve also spent a few hours debugging the support for the fade symbol at the tail end of this week, which is progressing albeit slowly. The unicode codepoint for the fade in symbol was specified incorrectly which accounted for an absence of anything happening when the symbol was applied to the score, and now we hThe other main part of the implementation that I’ve been looking at is chord diagrams, as there is currently no support for importing these as described in bug #21927. This has effectively been completed, and support has been ave an empty box. The empty box does seem to indicate to me that the font used for drawing symbols in the score does not support that symbol, but certainly this does work in the palette, and I have toyed with the fonts used with no effect, so on reflection I don’t think that can be the source of the error here. On the upside the layout of the “symbol” look to be fine, perhaps there is another codepoint somewhere that needs to be updated. I’ll spend a bit more time on this next week and try to narrow that down.

All the changes that I’ve mentioned that have been done to the GPX format, both this week and I think last week also, are yet to be submitted as a pull request. I’ll do this once the pull request for chord diagrams has been resolved and merged, as there’s a growing number of changes there.

Key tasks that stalled

Support for the fade symbol is somewhat stalling, I’m not sure how long it will take to find the erroneous code point / font / internal representation that is being used. Perhaps the box I’m now seeing is a red herring, but I doubt that’s the case as I double checked the codepoint is now correct in the various places where it’s specified. I’ll spend another hour or two on this this week.

Overview of work for next week

If we choose to have the representation for barre diagrams with the line connecting the common frets/fingers across distinct strings, then that’s something I’ll get working. Another few hours debugging the font issues with fade symbols also has to be done, and then hopefully that will be the end of that. Those aside, I think the next thing to look at will be the issues with the drum kit in Guitar Pro files, both the notes that we use and the playback of those notes. Perhaps that would be a variation on libmscore/drumset.cpp, I’ll need to look into that. Such a change will affect all versions of Guitar Pro import, and it would be nice to have something working for that. It’s quite possible all that will be completed, in which case I’ll either continue on Guitar Pro instrument playback (though I may wait until all drum issues are fixed first), or continue adding support for GPX import in the form of importing dynamics and articulations on notes.