GSoC 2020: Albums, Week 12, Time well spent

Last weekly blog

Welcome to the last weekly GSoC Albums blog post. All good things come to an end, this summer included. But, I'll leave the real conclusion and roundup of this year's Google Summer of Code for the summary blog post. In this one, as always, I will update you with the latest improvements in the Albums feature.

Last week

Last week I continued my work on refining the UX and codebase. I rewrote a bunch of stuff, deleted unused code, improved (and streamlined) the tests, and added a few finishing touches (like the ability to export parts and unifying album-score playback). Rewriting code has some benefits and some drawbacks. The main drawback is that (especially when a project is in such a rapidly moving and volatile state) rewriting stuff will reintroduce old bugs. A couple of things were working because there was a weird inspector bug, so I was building on a buggy base. The great thing about rewriting code is that, if done properly, fixing those bugs is an order of magnitude easier, since now you know exactly what you are doing and things are more organized.

I am confident enough to say that Albums should work smoothly (a.k.a. not crash constantly) and that most bugs/crashes that will, inevitably, be discovered will be the result of small oversights (more on this later) rather than fundamental flaws in the implementation. Some might say that I said this last week too (on the Albums Livestream where MuseScore crashed a bunch of times) but rewriting and testing exposed various small flaws and oversights that have now been fixed. In other words, I believe that when this eventually gets merged and released to the general public fixing the various issues that will pop up will be a relatively painless procedure.

The main sources of bugs/crashes in the lifetime of this project have been:
- MuseScore or ScoreView using cs or score (respectively) instead of the active score or the main/drawing score. This type of issue is pretty much impossible to overcome all at once since these variables are used all over the place and interact with an incredible amount of code. Luckily these are some of the simplest issues to fix.
- Movement layout clashing with the MainScore layout (more on that in the Summary blogpost).
- Simple memory errors (double free, memory leaks). All of them should be gone with the introduction of smart pointers and proper destructors.
- Not checking if a pointer is null.

The one real and worrying bug that I have not managed to deal with is the infamous 25.016 bug. When creating Parts in Album-mode (which will probably be renamed to movements-view or something like it) the parts normally have a Spatium of 25 (on the default page size). Unfortunately, this value makes the ScoreView go crazy, for some reason that I don't know or understand and I don't have a lead to help me investigate. I've got an idea for an experiment but my hopes are no that high. At the same time, MuseScore is under pretty heavy development, so it might just disappear :-)

The other, not so worrying problem is that since text editing is completely busted on my PC I can't test text editing related functionality. I believe that any problems that arise with that will fall under one of the four main bug categories that I described above, so fixing them shouldn't be too hard. On the other hand, who knows, text editing might be the Achilles heel of this project (but I don't really believe that :-).

The Future

In a couple of days, I will upload a summary blog post, so you have that to look forward to ;-)
As far as development goes, I was planning to be done with pretty much everything today, but the inspector bug and the bugs that fixing it uncovered threw me off my schedule. Hopefully, I will be done tomorrow. I mainly want to rename variables and functions, and also see if there are any other small improvements to be made.

Sergios - Anestis Kefalidis
Signing out :^)