GSoC 2020: Albums, Week 1, Boarding :-)

Decisions, decisions.

Hello again, it's time for our weekly blog-meeting. This was an interesting week. I continued working on the Album-mode (if you don't remember, this is the mode where the user sees and edits the entire album as a single score), mainly on laying out the movements correctly and drawing them. I also spent a considerable amount of time trying to understand the relationships between the various Score classes in the MuseScore database and thinking of possible ways to streamline those relationships.

Album mode

A few minutes after publishing the last blog-post I found a major bug that causes all movements/scores to disappear except for one. This was caused by the way that MuseScore renders the Score View (the pages). I managed to fix that problem by introducing a second variable to separate between the Score/Movement being drawn and the one being edited.
Unfortunately, my work here is not done, since there is a new bug where editing a movement repositions it to the beginning of the file. I've found the source of the issue (editing a movement, for example dragging a note, reruns the layout function for that movement but not for the entire score/album, this leads to it being placed as if it was alone). I haven't found a way to solve this issue yet, but I won't lose hope :-)
In addition to that, I improved the synchronization between the album-mode score and the individual scores (if you remember from last week, the first movement wasn't updated when it was modified separately).

MasterScores-Scores-Movements

There are 3 classes that are of great importance to both this project and MuseScore in general. MasterScore, Score and Movements (which is a container of MasterScores and was actually made for the Albums feature). Unfortunately, there are some deficiencies in their relationships (which is not too surprising since MuseScore is a pretty big project and is also one of the reasons why I am using a lot of dual/double names to describe things). I discussed with the community and mentors one possible course of action in relation to them and I did some preliminary work on refactoring them.
Unsurprisingly those classes see widespread use throughout the codebase which makes big changes to them unfeasible for this project (and the 3 months that accompany it). What I will do is continue to make small improvements where possible and add documentation (since I am rapidly learning a lot about them) so that future development can proceed smoothly.

Other improvements

In other news, I worked on rebasing a couple of old Pull Requests (one of which is PR #5922 which is a very nice improvement if I may say so myself :^)
I also formatted and reinstalled my development environment to have exactly what I need to develop MuseScore and to minimize the chances of nasty surprises in the future.

The next order(s) of business

In the next couple of days, I will hopefully fix the "editing a movement causes it to reposition itself" bug and I will work on polishing the experience in general. After that, I will solve all my linker/compiler errors and clean up my code. Since I am a month ahead of schedule I want to focus on creating a very solid foundation so that future features can be developed rapidly in the coming months.

This week has no video, but I will cook something up next week :-)