Our Plans for Engraving Improvements

• Jul 1, 2020 - 09:41

Hi everyone,

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.

Comments

• Jul 1, 2020 - 09:59

Awesome project!
To 6.: Maybe consider using Github. With Github Projects for Open Source repositories this should be no problem. And Github has better support for mobile devices than trello. Just give it a try and evaluate it yourself. If you need assistance contact me.

Reply

• Jul 1, 2020 - 10:41

I'll probably need a quick walkthrough - but perhaps that might be our solution? I guess the first thing to do is state what things we'll need to be able to do on the creative side:

1: have a place where we can prioritise bugs and issues that need to be solved. Then have a traditional 'To do', 'Doing' ''In Review' 'Done' setup. Or something that similarly allows us to have a quick overview of what's going on at a project level.

2: Have an ability to post video links of us using screen capture to describe problems. Tricky thing about this is - it would be need to be private - with only people on the project being able to see it. Speaking for myself, I wouldn't want the general public scrutinising me sharing my desktop info. The value of using video to talk through visual problems is absolutely massive - on a different level to trying to write it out in with complex sentences and screenshots. If there was a way to keep certain things private on Github Projects, then that would be very very useful

3: Needs to be fast. Much faster than the MS issue tracker, which does not have the kinds of modern tools that help to speed up communication. I assume GitHub Projects is fairly impressive in this area.

Perhaps - if you're willing - we could set up a quick call, and you could show me why it's appropriate? If yes, email info.tantacrul@gmail.com

Thanks!
Martin

Reply

• Jul 1, 2020 - 10:54

I'm glad to see this coming and I'd very much like to contribute, probably not always by writing code, though.

And as I said for point 6th, I strongly recommend Atlassian. You can customize the workflow and prioritize tasks very effectively.

Reply

• Jul 1, 2020 - 12:24

I would like to have a visual test system that is based on mathematical constraints rather than comparing images.

Take an ottava (8va/8vb marking) for example, Gould's Behind Bars p.28 says:

> The numeral '8' is 1 1/2 stave-spaces high.

So we create the constraint:

assert ottava.numeral.height == 1.5
 
# Or perhaps this would be better:
assert abs(ottava.numeral.height - 1.5) < 0.1  # allow small margin of error


This would be run as part of MuseScore's automated CI tests to ensure that this rule is always obeyed regardless of other changes to MuseScore's engraving rules.

Eventually we could test all of Gould's rules this way!

Reply

• Jul 1, 2020 - 15:27

One thing I should point out - and this isn't really related to your specific suggestion but I thought I'd mention it - Simon IS our Gould.

Behind Bars is a fantastic reference and a much needed general resource but we've brought Simon on because it was obvious we needed more than that:

1: For his particular experience and knowledge, which often goes deeper than Gould's text could practically allow. For example: I'm sure he can add nuance to the definition of exactly how much distance should be between 8ve markings and the staff.

2: We need a dedicated resource who understands our particular problems and who can arbitrate when opinions on how to interpret engraving rules clash (which happens all the time).

3: Engraving rules sometimes clash with the necessities of building interactive scoring software. Since he has actively developed numerous extensions to SCORE, this is an area he understands very well.

Again, this isn't to try to contradict anything you've mentioned. I think automated engraving tests sound fascinating. I'm just pointing out that we now have something much more powerful than a text that can't adapt to our unique circumstances.

Reply

• Jul 1, 2020 - 15:29

Thanks for starting this discussion! I'll have much more to say over time, but I'll just make a few points for now:

1-2) Yes, there are doubtless many opportunities for easy wins. One issue with anything involving changing defaults, though, is figuring out how to handle older scores, which we would normally not want affected unless the user opts it. The way things are set up right now, doing that sort of switching is difficult to do for "minor" releases. A possibility is to leverage the existing dialog that comes up when importing pre-3.0 scores. Not that anyone is in love with that dialog, but anyhow, it could potentially be part of a solution

3) FWIW, as I see it these will probably end up falling into two broad areas: things where the defaults could be better (eg, the note spacing algorithm, beam angles), and things where we want it to be possible/easier to create certain layouts that are not practical right now (eg, force systems to a consistent height, change between pitched/unpitched instruments on a single staff, change page or style setting mid-score, etc). It will be important, I think, to keep both of these areas in mind when brainstorming.

4--5) Sounds good. So far, there really hasn't been such an arbiter, it just comes down to what the person implementing something feels like and whether they can "sell" it to whomever is charge of merging PR's. We all try our best to consult the literature for guidance, but it's definitely a "design by committee" here with no real expertise anywhere.

6) I'm not crazy about the idea of having a separate place just for this. If there are perceived to be deficiencies in the issue tracker, I'd rather see us just move the whole thing to a new system, rather than forcing developers to have to monitor two separate places, and confusing users who now have to decide between three different places when posting requests (feature request forum, issue tracker, or this new place). To me the issue tracker is "OK", it's gotten better over the years for sure and I do like it better than the ones I've used when submitting bug reports to other projects, but it's not hard to imagine what a better system might look like, and I have no doubt they exist.

Reply

• Jul 1, 2020 - 21:16

I suggest we keep point 6 as a topic that requires more discussion. When we have a better sense of how many people want to be involved, we can jump on a group chat to hammer that out. I have a few points about things myself and Simon would like but it feels like I should wait before bringing them up. Regardless, I'm sure we'll figure out something without too much trouble.

Reply

• Jul 3, 2020 - 00:26

I am so happy to see that you're on it!

Just four days ago, I received feedback on my first orchestral score, which I submitted to the annual Orchestration Online scoring challenge. I came over here to gently report that the feedback included some severe criticism of the engraving standards of the application I used.

You get it already, but I'll share what I intended, in case there's something there for you.

The criticism regarding the look of my score was delivered kindly, while giving the clear message that its overall appearance is entirely unsuitable for a professional setting. I made dozens of rookie scoring mistakes that are mine to own and rectify, but there was much said about the standards built into the tool that I think go beyond user error.

Simon's comments this week call out some of the same points, but if it will help, the review of my score is available to watch on youtube: https://youtu.be/TX-fcYLYKKE. Comments on the engraving are at 1:30-4:37 and at 48:30-50:07.

Reply

• Jul 3, 2020 - 06:40

Maybe I’m missing something, but I didn’t hear anything specific whatsoever in his comments at those point, beyond the “rookie error” of not having connected your barlines properly. As discussed here, that’s something being looked to see how it could be done automatically, but certainly MuseScore is capable of this already, you just need to do it, and it takes only a few seconds to set up. Was there was somewhere else in the video where he gave any other specifics about why he thought the app was “basic”?

Reply

• Jul 3, 2020 - 12:01

I agree that he did not enumerate many specifics, and he declined to do so when I followed up. Rather, he commented that he has seen quite a few scores done in musescore, and that mine might be one of the best looking. His impression is that I've run into hard limits of the app.

I'm not taking his advice to switch as my only solution--I love musescore and want to help it succeed. But that advice was too clear and strong to ignore!

I think that the sense of proportion that Simon's comments address goes more to the heart of the overall poor impression than the barline thing, about which he emphasizes, "it's not just that."

Two additional differences I spot in other participant's scores from Sibelius and Dorico:
1. Their whole rests are narrower. In a big score page with some sections playing and others resting, the sections at rest kind of recede into the background. In my score, they are more prominent (and distracting).
2. The slurs are thicker in the middle and tapered to the ends. Mine appear more like simple arcs.

For reference, the feedback on this entry begins with a shout-out on its beautiful engraving. https://youtu.be/A80S0Uc2F2s

Reply

• Jul 3, 2020 - 12:24

When I watched the video, I understood what he meant. I also agree with you that even though he wasn't specific, you could tell where some of the problems were. To name a few:

:: There is no bracketing or score indent
:: The default engraving settings are not all that nice (stroke widths, font, etc.)
:: There is no vertical layout justification

All of these things should have much better defaults.

All of those defaults WILL happen! (And much more too!)

Reply

• Jul 3, 2020 - 22:36

I agree it will be great to improve the defaults. But meanwhile, I'd also love to help you get more out of the app as it is by showing you how you are not stuck with whatever defaults are bothering you. So feel free to start a new thread where you explain something you don't like the look of, and we can show you how to customize or override the defaults. Hint: go to Format / Style / Score, change the font to Bravura, and instantly both the things you mention become much more Dorico-like.

There is much more possible as well depending on what specifically you want to change, but as I said, a separate thread is the better place for that. Here we can talk about what improvements to the defaults might be made. Elsewhere, I can show you how you can get take advantage of the features already provided to get your score looking every bit as good as everyone else's (well, maybe except Justin Tokke, he's kind of legendary!), without needing to wait for us to make changes :-)

Reply

• Jul 4, 2020 - 09:41

I would certainly hope you wouldn't switch away from MuseScore. Any notation software is really only as good as its user anyway, and it's obvious from your score that you know what you're doing with regard to notation and actually care about how things look, and have taken the time to make them look right - barlines notwithstanding.

Though as I keep saying, the point is that MuseScore should produce something that looks great even if someone doesn't know, or care. I think Dorico has done an impressive job of that already. But if we were to sum up my mission here it's that I want to make output at that level of quality available to everyone, for free. Nobody should have to shell out hundreds of £/$ for it, or have to spend ages tweaking everything to get it looking nice, or even need to read and digest huge notation tomes to know what they are meant to do in the first place (unless they want to - and I'd hope people will be curious enough to do it a little bit!)

And/or to put it another way, we're going to make it impossible for anyone to have this "well, this is just some free software so what can you expect" attitude. This video is a perfect illustration of the problem so it's actually really helpful and has come along at an ideal time.

(The monstrous bar rest, by the way, is one of my biggest Emmentaler gripes) :)

Reply

• Jul 4, 2020 - 12:36

In my day job, I coach product owners to define a clear and inspiring vision for what their team will build. That vision should convey empathy for problems the customer faces, and should project how using the product will change the customer's life for the better. I can point to your mission summary as an excellent example. And in this case, by "excellent," I mean, "you've read my mind." :-)

It would take a lot more than this reality check for me to switch away from MuseScore. I'm not using hyperbole when I say that I love it, and I am thrilled that my feedback might help you accomplish your mission.

Reply

• Aug 18, 2020 - 00:30

Tantacrul wrote >    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)

Hello to everyone! This is my first post.

I'm interested in assisting with the creation of vector glyphs for MuseScore's fonts.

Please send me an image. I'll create a vector rendering and return an Illustrator file, SVG or PDF of the symbol I've created. Then you can determine if my style meets the quality required.

Where possible I draw symbols in the orthographic approach recommended by Stepen Moye. While this was of historical importance—when rasterization speed was a significant concern—I also find that orthographically drawn symbols are far easier to edit, largely because they contain a minimum of anchor points.

Below are a couple of example character glyphs I've drawn orthographically, using minimal points.

Attachment Size
Serif Characters - Outlines.png 20.84 KB
Serif Characters - Rendered.png 27.75 KB

Reply

• Aug 22, 2020 - 18:57

Not to be a smart @$$, but it'll be implemented when it's done. Unless it's very close to being finished, a release shouldn't be delayed for it. It's being planned for 4.0, but if it's ready of an intermediate release (3.x) sometime before that, it'll likely be in that release.

Reply

• Sep 19, 2020 - 04:54

Update: Tantacrul said on Telegram that the new font will be included in 3.6 when that is released. 3.5.1 is planned for release probably around Oct 1 and work for 3.6 will be in full force. I'm not sure when 3.6 is planned but it will no doubt go through at least 1 beta version before its release. Tantacrul said there may be a few seldom used glyphs that will use Bravura (the current default) as a fallback so most people shouldn't notice. There are a lot of other goodies in store for 3.6 but I'll leave that for a more formal announcement when the time comes.

Reply

• Sep 19, 2020 - 04:43

I'm not at all active on the Musescore forums, but I will say that this plan is a great leap forward for the program. Hopefully it can really push the envelope for the other programs to up their game.

I'm an open book if anyone wants to ask about engraving as well and I will contribute where I can.

Reply

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