dmitrio95's blog

This post is a summary of the work that was done on my GSoC 2018 project. Here I’ll try to explain briefly which goals were set for this project, what was accomplished and which tasks are still left for the future work.

Project description

The problem this project is devoted to is a musical score comparison. Comparison of scores (most often different versions of the same score) is needed for a number of applications both in personal and collaborative work

Hello!

In my last blog post I wrote about things that need to be finished to consider the score comparison tool in its basic version be complete. In general, those points I mentioned in that post were accomplished during this week. So the key changes are:
1. Read-only mode for scores
This was implemented for the purpose of being used for the versions comparison feature. The implemented read-only mode is far from being perfect and certainly lacks any user-visible signal

Hello!

As there are only two weeks left for this GSoC I think it would be better to discuss some plans for the rest of that time in this post. Still I'll begin with those changes that were done during this week.

Recent changes

I. Improvements in a comparison readability
1. A consistent way of adding a human-readable representation of various properties was added to MuseScore code. Note pitches and barlines types are not shown as just numbers anymore but

Hello!

During this week the score comparison tool got a small redesign and an ability to show score chunks that are relevant to the displayed changes. The current look of the tool is shown below (or here in better resolution).
[inline:Screenshot_20180723_033120.png]
User can choose for comparison any scores that are opened in tabs at the moment. The choice can be done either using drop-down lists inside the tool area itself or just by opening the needed scores in two tabs

Hello!

This week after fixing some issues of the developed score comparison engine (mostly concerning spanners handling) I have started a work on a graphical interface for the score comparison tool. Currently its look is far from perfect but to some extent it works. Below is the screenshot of MuseScore with the new tool launched, as it looks at the moment (full resolution):
[inline:Screenshot_20180716_023050.png]

During the next week I will improve the interface of the tool — hopefully

Hello!

This week I worked mostly on the score comparison engine which I have started to develop during the last week. Last week ended for my work on the project with a problem of getting a semantically correct diff between MSCX (or, more generally, XML) documents. This week I finished a work on correcting a usual textual diff to be more correct from XML point of view (mostly to contain a whole number of full XML tags, if possible),

Hello!

This weekly report will probably be not the longest one :)
This week after submitting the pull request on the first part of my work (which I mentioned in my last blog post) I worked on a new textual score comparison tool built in MuseScore. In fact, the only thing I have built into MuseScore to this date is just a console diff-like tool which is (usually) able to map the found differences to actual objects in the

Hello!

I seem to be a bit late with my post (well, I am definitely late) but I have a good news for now. After six weeks of work I could finally post a pull request with the proposed changes to MSCX fileformat. The list of changes itself can be found here. I am not sure whether this work was done fast enough or not, and I am sure that the issued pull request will require some more adjustments

The fifth week of GSoC was devoted to making final edits to my changes to MSCX format and preparing my code to be merged to the main branch. At least it was planned so but things went a bit longer than I expected :) So let me describe what I have worked on this week.

Rework voices storage
Before the start of my GSoC project change of voice within the staff was represented in the file by <track> properties

Hello again!

This week, not too straight, but moved my work close to the end of the first part of my project. I finished my work on tuplets storage without IDs but after some discussions with Peter Jonas (shoogle) we concluded that it is better to store beams and tuplets in another way. In brief, beams and tuplets are always contained within one measure and within one voice and do not overlap (though tuplets can be nested). Even if beam