GSoC 2018: Score Comparison Tool — Week 5

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 within every Element in every voice except the first one. Usually a change in the voice was preceded by <move> tag which denoted a change in a current reading position. During the last week I, among other changes, made <move> tag able to denote change not only in position but also in voice, staff, note and other parameters making it possible to use this more universal <move> tag in various contexts. Voice changes could be then denoted by such a tag thus avoiding multiple track numbers within <track> tags in a score file. This week after the discussion with my mentor (shoogle) this idea was revised and voices were planned to be denoted more explicitly, by enclosing them in special <voice> tags. This was implemented this week. Here is a simple example:

<Measure>
  <voice>
    <Rest>
      <offset x="-6.77" y="0"/>
      <visible>0</visible>
      <durationType>whole</durationType>
      </Rest>
    </voice>
  <voice>
    <Chord>
      <dots>1</dots>
      <durationType>whole</durationType>
      <Note>
        <pitch>68</pitch>
        <tpc>22</tpc>
        </Note>
      </Chord>
    </voice>
  </Measure>

Preparations for merging
Various little technical improvements were made to prepare a code for merging. One of those should be converting the scores used in mtest to the new fileformat. Doing this revealed that I still had one important thing to change.

Linked elements IDs
This important thing is exactly those linked elements iDs. These IDs introduce absolute elements numbering and all the problems related to it back again to the scores which have several linked parts. Unfortunately, just removing the corresponding linked IDs (<lid>) could not be done: even if some staff is linked to another staff there are often some elements in it which is not linked to any element in other staves, and there are some elements that may be linked to the element from a staff which differs from the staff linked to the current one. That is, simply counting elements in the linked staves does not really work. But it still can be done if it is known that current element is linked to other staff's element, and that staff's number is known. This is what I used for avoiding writing linked IDs: I wrote a number of staff to which the current element is linked instead of that link's ID. Knowing the linked element's staff number and its position within a score (which should match the current element's position) and within another elements in a file it is possible to find the linked element. This simple mechanism will break in case elements from different positions are linked or the order of elements in the linked staves is not preserved but those cases don't seem to make much sense.

Plans for the next week
Hopefully, if no new problems are detected, I will finish my preparations for a pull request during the nearest days. After that I can start working on the second part of my project which concerns a creation of a tool for comparing scores within MuseScore. It is hard to predict though what will be done in that direction during the next week.

A note-question: incorrect barlines types defaults?
During my work with scores from a compatibility test for 2.x version of MSCX fileformat I found a problem which, in fact, leads to some incompatibility of the current code with that format. The problem concerns barlines types and is not related only to 2.x fileformat but to the barlines' reading process at all. The problem is described here and, basically, is in that BARLINE_TYPE property default differs a bit while reading and while writing a barline. So something should be changed to it but I wonder whether it should be a change in a default value or in a reading process. This question is not directly related to my project but as I work partially on maintaining a compatibility with older MSCX format versions I wanted to report the existing problems too.

Thank you for attention!
Dmitri Ovodok
Current branch: https://github.com/dmitrio95/MuseScore/tree/scorecmp1