Google Summer of Code 2020, Albums, Summary

Albums Pull Request
All my Pull Requests during GSoC

Project Description

The goal of this project was to bring back MuseScore 2's Albums feature and improve on it so that it satisfies the needs of the huge MuseScore community. Albums allow users to create large works that consist of smaller ones. Things like songbooks/symphonies/studies can be represented as an Album. By using an Album for such a collection of pieces the user can enjoy increased productivity (since working on multiple works simultaneously becomes easier) and a variety of smaller, desirable organizational functions. Albums interact with a plethora of MuseScore's systems, from layout to painting and from editing to playback. This is why great care was taken to match the high quality of the existing MuseScore codebase. I believe that this project has succeeded in both of these challenges.

First of all, I will present briefly the improvements that the users will enjoy. This new implementation of Albums gives the user a variety of layout options and the ability view/edit/playback scores either individually (like one would normally do) or as movements of a single Score. The biggest addition is the option to have Scores with different instrumentations and different Styles in the same Album and in the same ScoreView. In addition, there is the option to generate (without any user input required) a Front Cover and Contents pages (which is pretty much required to navigate a large collection of Scores). I will talk more about all this later on (better yet, I will show you), but another notable feature is the ability to import MuseScore 2 album files and to export an Album and all its Scores in one file (which is very convenient and much-needed feature).

As far as the technical side of things goes, this project has dealt with a lot of the hardships that multi-movement layout, editing, and playback entails. With small changes (most of which are described in the code) it is possible to completely decouple Albums from multi-movement Scores. Most new code (and a lot of old code) has been documented in detail, so that feature development proceeds smoothly and as headache-free as possible. I also simplified the problematic Score-MasterScore-Movements class relationship and extensively documented it for future reference.
The use of smart pointers (and clear ownership), references instead of pointers, const-correctness and automated tests, help ensure the correctness of the code.
There will be of course bugs that will be discovered but solving them should be relatively simple (as described in my previous blog and extensively in the code). At this point, I want to thank everybody who helped me navigate the codebase and solve issues. MuseScore is under heavy development (in preparation for version 4) so all help has been incredibly useful. So, thank you to my mentors James and Joachim, but also
to everybody who was there to review code, answer questions and watch my videos and Livestream :^D

Here is a quick trailer that demonstrates the most important features of this project:

Features

The following is a list of the most important features/achievements:

• Create Albums from existing Scores.
• Two modes of operation. Album-Mode where every score is presented as a movement of a bigger Combined Score.
  Score-Mode where editing (and playback, although it has been disabled to make the UI design simpler) happens individually.
• Add/Remove/Reorder/Enable/Disable Scores in Album-mode with immediate updates in the ScoreView.
• Support for Parts, the above features also work for Parts. Albums Parts do not interfere with normal Parts.
• Scores with different instrumentations are supported (although this disables the Parts functionality).
• Scores with different styles are supported.
• Multi-movement score playback with customizable pause duration between movements.
• Able to import MuseScore 2 albums.
• Able to export an Album and all its Scores as one file.
• Automatically generated contents pages. (updated in realtime when something related changes)
• Automatically generated front cover. (updated in realtime when something related changes)
• Total Album duration and Score durations are displayed and updated in realtime. This can help organize a recital/show/performance that has to satisfy time constraints.
• Created a tour that explains how Albums work.
• Album files can contain both absolute and relative paths to Scores. This allows either enhanced privacy (by only using relative paths) or the ability to move the Album file
  without losing the connection to the Scores of the Album.
• Album-mode/multi-movement layout options to allow for either optimal placement or more beautiful/appropriate placement of movements.
• Albums works with most of MuseScore's systems like Palettes, Navigator, Session restore, Recent Files, Timeline (basic support), Mixer (basic support).
• In Album-mode undoing works on a per movement/score basis. This gives the user more versatility when editing.
• Single Page View is supported (Continuous View is not).

Lessons learned and challenges encountered

I have to say that I was very well prepared for this project. Since March (when I first started contributing to MuseScore) I've made around 40 Pull Requests some of which were pretty significant and allowed me to gain insight and knowledge about MuseScore's codebase. Naturally, there were a bunch of times when I was stuck for some time (after all getting to modify some of the biggest classes in such a big application is not trivial) but while preparing for Google Summer of Code I learned to now get discouraged if I get stuck, the solution will eventually appear. The biggest challenge was having to described what gets implemented and what gets cut/left for future development and of course having to deal with the various weird bugs that exist in master (thanks to the previously mentioned quick development speed).

The most important organizational lesson that I learned this summer is balancing exciting new, shiny features with slow and methodical rewrites and tests. The most important C++ lesson is never to ignore compiler warnings. Last but not least, the most important and life-changing lesson is how contributing to Open Source Software works and this is in my opinion what Google Summer of Code is all about.
It gives you the slight nudge that breaks the ice, so to say. After this summer, I can't see myself ever stopping contributing to the Open Source community.

Future development

Naturally when people start using this a lot of bugs will be uncovered, so fixing them is THE FUTURE. But other than that, on a brighter note these are my notes on possible improvements and additions:

Mass changes:
- Mass changes, Actions menu, used by both albums and groups of normal scores (multiple tabs selected or opened scores)
- Easy way to select multiple scores.
- Actions:
- Add - Replace instruments.
- Change style.
- Change footers/headers.
Mixer (improved support)
Parts for Albums with different instrumentation.
Timeline for the entire combined score..
Albums inside an Album.
Tools to split a score into multiple scores (an album).
Improved composer/lyricist handling. Give the user an option in the inspector to include (or not) that string in the front cover.
Add new movement with the same instrumentation as the last one in the album

The end

My future plans is to focus on fixing the bugs that I introduced on 3.5.0 :^D
See ya around,

Sergios - Anestis Kefalidis, student at National and Kapodistrian University of Athens