Score comparison tool: design and possibilities

• Jul 11, 2018 - 00:29

Since the previous topic on my GSoC project has grown a bit large I create this topic to discuss some questions related to the score comparison tool development. The previous topic will be left for discussions concerning MSCX fileformat changes.

The next stage of my GSoC project is a development of score comparison tool itself. In my recent blog post I told about some progress in development of score comparison engine which is currently built on top of textual diff library (I used diff_match_patch which was already found in thirdparty/ section of MuseScore sources but this can be changed). It is not yet finished but is already able to yield sane results for some simple changes between scores. So the work on the score comparison tool itself can be started so some more or less complete tool will be available which will then be improved.

We have some discussions on the score comparison tool design with my mentors (@shoogle, @anatoly-os), and @shoogle made a document containing some ideas on what this tool could look like. With his permission I'll publish here a link to it, and in this post will briefly describe my ideas on score comparison tool design and its possible features, partially based on those ideas described by @shoogle. Feell free to propose some other ideas and give any feedback on what I will describe.

Tool location

It seems to be a common conclusion that the best location for the tool is a bottom of the window. There is also an option to show the compared scores side-by-side: although the tool is planned to be mostly textual for now, possibility of visual assessment of differences can be more convenient. This can be combined with a feature of automatic scrolling of the shown scores to the relevant location when choosing some particular difference. To make it more convenient to see the compared scores side-by-side perhaps it worth to temporarily hide panels related to editing scores like it is shown below. This seems to make sense if editing scores while comparing them is not needed but I am not sure about this.
Screenshot_20180711_002913_1.png

Features

In general, the score comparison tool should have at least two or three modes:
1. Showing raw textual diff between MSCX code for the compared scores;
2. Showing a list of changes with some little context about them described;
3. Showing a full tree representation of score with certain branches expanded and differing elements specially marked.

I am not sure that the third mode is needed but it can be useful in that it gives more information about the changed elements' context than the second. The first mode would allow to quickly see raw textual diff of MSCX codes without any advanced (and potentially containing errors) processing being done on it.

Some examples on how the latest two types could look like are given in the diff_view.png attached to this post. Second mode from the list above is roughly corresponds to what is called Intelligent view on the picture, and the other two examples show two possible options to implement the third mode.

Some notable features:
- Click on a change item moves score views to the relevant locations.
- Differ between an element insert/removal and properties changes.
- Possibly some advanced recognition of changes (transposition of series of notes, moving or copying of some content to the other part of score). Would be nice to have but this will probably be developed not in the first version of the tool.

Design of the tool

Concerning the general design of the tool I'll include this screenshot from the mentioned above @shoogle's presentation:
scorecmp_tool.png

There you can see a file or version chooser widget, a radio button switching between modes of showing differences between scores, and on the right side there is a tree view showing the corresponding diff. If there are not too much place perhaps the left widget (file/version chooser) can be done not too wide or even replaced with a button launching a file choice dialog. Still if the score diff tool span for the full window width as suggested above there will probably not be such a problem.

So I hope I didn't miss too much in this brief description. I will be glad to hear any feedback or questions on that!

Attachment Size
Screenshot_20180711_002913_1.png 282.92 KB
diff_views.png 113.1 KB

Comments

• Jul 11, 2018 - 09:25

"The first mode would allow to quickly see raw textual diff of MSCX codes without any advanced (and potentially containing errors) processing being done on it."

Having used WinDiff a lot, I really like the raw view...

Reply

• Jul 15, 2018 - 23:31

I have started implementing the described design and met some new questions to be resolved. I'll try to formulate them in brief.

I. Files/versions list

It seems to be clear what should be contained in the list of versions of some file if the file has it (it doesn't currently). However it is not too clear what should we have in the list of files available for comparison: a list of recent files, a list of tabs or something else, and how it should be synchronized with those. To make it a bit clearer to users and to developers I suggest the following two options:
1. Remove file chooser widget, have two dropdown lists instead of it populated with a list of recent files (or tabs) and an option to browse a file in the filesystem. Something like:
Compare [dropdown list] with [another dropdown list]
2. Have different categories in the list shown in file chooser widget each of which could be collapsed or expanded. Now it will be clear how each category is populated:
Recent files
|--- file1.mscz
|--- file2.mscz
Opened in tabs
|--- file1.mscz
|--- file3.mscz
Custom [I mean those added via "Browse" button at the bottom of the widget]
|--- file123.mscz

Which one (of these or any other options) would you (and other users) prefer to see?

II. Viewing scores and tool(s)

It seems that it would be convenient to see the compared scores side-by-side or at least see some of them somehow. There are however questions which affect how they should be shown to the user:
1. Is it needed to edit scores during their comparison or it would be enough just to have a possibility to apply or undo the shown changes to the scores?
2. Is it needed to conduct several score comparisons at a time or there is almost always a need to compare only one pair of scores simultaneously?
3. Should the score comparison tool be bound to the tab(s) relevant to the current comparison or it makes sense to leave the tool visible when the user switches to other tabs?

These questions are partially interconnected but still they are actual.

Reply

• Jul 17, 2018 - 03:25

I. Files / versions list

  1. The "file chooser widget" in the diagram is just a placeholder; you can implement it however you like. If you think a drop-down works best here then go ahead and use one (but see my new suggestion below).

  2. I think categories is getting a bit over-complicated. The drop-down should just display scores already open in other tabs, and clicking "Open" in the comparison tool can simply load a score in a new tab as usual (but not switch to the new tab). If you want a list of recent scores, you could add it to the Open button as a ToolButtonMenu, but don't bother doing this now.

Suggestion: You could also consider dispensing with any kind of file chooser (drop-down or otherwise) and just using the View > Documents side-by-side feature. You simply compare the score on the left with the score on the right, and if the user wants to compare different scores then it's up to him/her to load a new one in each pane. This still requires a bit of thought though, because the side-by-side view might not be to everybody's liking.

II. Viewing scores and tool(s)

  1. No editing is required, unless this is easy to implement. (It is also acceptable to require the user to save the score before performing the comparison, if this makes things easier for you.) If you implement comparing previous versions of the same file (i.e. storing diffs inside the MSCZ), then editing would certainly need to be disabled for all except the current version. There should be an option to revert back to a previous version of the file, but this would be an irreversible action that would result in versions after the restored version being permanently deleted when the file is next saved.

  2. You only need to implement comparison for two scores at a time. I don't know of any diff program that can do more.

  3. Either is acceptable, but I think the ideal behaviour is determined by how users are supposed to interact with the tool:

    • If it's a case of "choose a score X to compare with the current score" (i.e. one choice) then the comparison tool should be hidden when the user changes tab (i.e. when the current score changes).

    • If it's a case of "choose a score X to compare with another score Y" (i.e. two choices) then it should remain visible when the user changes tab, and changing tab should change either score X or Y (or both in a side-by-side view).

Reply

• Aug 13, 2018 - 01:00

As I am about to submit my second large pull request with the implementation of the score comparison tool I would like to sum up what has been done during the recent time and how does the result look like. The following information have already been partially described in my weekly reports but this post should contain more full and actual description of my work results.

Tool Design

The score comparison tool is normally located at the bottom of MuseScore window and can be opened from a menu. The keyboard shortcut you see on the screenshot is my custom shortcut and is not included in the new pull request.
start.png
The tool is a Qt dock widget so it can be moved to any desirable side of main window and even be detached from the window and placed independently.
float.png
The tool itself has three areas: scores/versions choosing area, diff mode switch area and the diff view itself. These areas will be described below.

Scores and versions

Any score which is currently opened in MuseScore can be compared to other such scores. In addition to that up to three versions of each score is available for performing a comparison:
1. Current version;
2. Last saved version;
3. Session start version which represents the state of the score at the beginning of the current working session.
choose_scores_panel.png

Diff mode switch

This is simply a set of radio buttons allowing user to switch between "raw" and "intelligent" modes for viewing the currently performed comparison.

Diff view: raw diff mode

In a raw diff mode the tool shows differences between MSCX representations of the compared scores. Raw diff is currently shown without any context — perhaps some context should be added.
raw_diff.png

Diff view: intelligent diff mode

In the intelligent mode the tool tries to convert a raw MSCX diff to something more human-readable. Currently it only shows an information on added/removed elements, changed properties and some other simple differences between scores but some advanced analysis can potentially be added in future allowing, for example, detection of transposing of some score chunk or copying/moving some parts of a score. That analysis is not currently implemented though.
Clicking an item (or activating it from a keyboard) makes currently shown scores jump to the location which is relevant to the selected diff item and selects some relevant elements if they exist.
intelligent_diff.png

Conclusion

There are still some things to improve for this tool but it should be already in a mostly ready-to-use state. Hopefully it will be useful, and feel free to post any feedback!
Thank you for attention!

Attachment Size
start.png 192.71 KB
float.png 163.4 KB
choose_scores_panel.png 9.25 KB
raw_diff.png 16.23 KB
intelligent_diff.png 10.13 KB

Reply

• Aug 13, 2018 - 08:00

"Raw diff is currently shown without any context — perhaps some context should be added."

I have used raw diff output (in an IT environment) when the only meaningful context is "line number" - always provided. In a music environment I can imagine that users will need and expect the context of "measure number" in order for the diff to be in any way meaningful.

I can't wait to try out this tool, which will be a huge help to me, because I often deal with two versions of the same score (input and then edited by two different people).

Reply

Do you still have an unanswered question? Please log in first to post your question.