Our Plans for Engraving Improvements
Over the last few weeks, our new engraving expert, Simon (@Oktophonie) has been proposing a list of improvements that we can make to the layout and engraving of MuseScore. Simon used to work for the publishers, Boosey and Hawkes, producing scores for some of the most important European composers working today. He also has a development background and has written multiple extensions for the engraving app SCORE (more about this later). He will be publishing a list of his findings over the next few days. In short, he has a list of suggested improvements that have been broken down into three types:
1: Things we can fix with minimal/no changes to our engraving code (templates, defaults, etc.)
2: Things that would require a partial / moderate rewrite of the code
3: Things that possibly require a code overhaul
Since the resources of the internal team are currently fully committed to refactoring the codebase, creating a new visual interface, adding multiple new features and also creating a new audio engine, we thought it would make sense in the meantime to see if there was enough interest in organising a community project to make significant changes to our engraving and layout - especially given the interest that has already been expressed on the Telegram Developer's chat. Assuming there will be enough general interest, there are coordination challenges that need to be addressed. I thought I would make a quick proposal for how I think this could work.
I'll start by describing something we are working on right now.
Simon's first observation was that a big improvement could cheaply be achieved by simply altering our font defaults (the music font for notation and the text font for titles, performance directions, etc.). Based on this recommendation, we have started working on a new music font (while searching for the right text font too). Our initial work on the music font looks very promising and we have already created 25 of the most important (and complex) symbols in the space of 3 days. We've already started testing it in MuseScore and it's looking very nice. This brings me to the process we are using, which I think would be applicable to a wider community effort.
As I mentioned before, Simon is an expert user of the (now abandoned) engraving app SCORE. Not only has he produced numerous professional scores with it, he has also spent years making subtle modifications to the program in order to alter its notation and engraving defaults. As a result, he has developed a comprehensive understanding of how every aspect of a score should be arranged. This is the kind of holistic understanding that I find invaluable. If you aren't familiar with SCORE, it is still used by many professional publishers today, who consider its engraving to be the best in the business. Along with Simon's numerous alterations, we want to bring that level of engraving finesse to MuseScore.
Regarding our workflow for the music font - Simon starts by sending me a few symbols outputted from SCORE every day (many of which he has made significant alterations to). Since these symbols aren't in a vector format, my role is to faithfully redraw them in Adobe Illustrator and place the results in a new font, (conforming with the SMuFL specification) and we then test them in MuseScore before making any necessary alterations. In addition, we are making tons of other alterations to note stems, hairpins, staff size, etc. As I am working, I'm realising that although I have a decent eye for certain details, Simon has a level of experience that goes beyond my attention to specific details and is able to make more informed decisions on details that feel slightly ambiguous to me. His no.1 priority is that our font should be as easy to read as possible. Consequently, we are putting together a system that is far more than the sum of its parts.
So with the above in mind, I propose the following:
1: Simon publishes his findings and recommendations here. We look over it and discuss.
2: We identify small tasks that are of high-value (for example, implementing our new font so we can begin altering its engraving defaults). These could potentially be part of a 3.5.1 release.
3: We identify larger engraving tasks that are more significant in nature. Simon will be able to write models for how these should work, and can collaborate closely with whose developers to test them and make suggestions for improvement. Many of these will be longer-term changes that we can prepare for 4.0.
4: Community members choose the areas they are interested in working on
5: I propose that we taking advantage of Simon's knowledge by relying on him as our 'arbiter of good taste', effectively becoming the source of creative 'sign off'. I know this sounds a little unusual but I think it's a necessary trust that we must place in him in order to arrive at a unified default engraving language. This is my own approach when designing our new music font, and it's already paying large dividends.
6: We agree on a place where we can reliably track related issues related to bugs and finesse. I'm not certain if our issue tracker is suitable for this task and I propose that we investigate the idea of setting up a Trello board for interested contributors. This is a system that we use internally that allows us to keep track of a large amount of information - and allows us to work quickly too. Obviously, this is a point that requires more detailed discussion.
One last thing: it's worth mentioning that we are designing our new interface to make it much easier for users to find and choose between different engraving setups in the future. In other words, this proposal is not to create one single system that we'll be 'stuck with' forever. It's to create our first of many properly unified systems. Our aim is to provide many more styles for our users to choose from in the future.