Switch to larger noteheads (ss05) in Bravura for 2.0 and 2.0.1 compatability

• Jul 10, 2015 - 16:02
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

Following up on a comment at https://musescore.org/en/node/68196#comment-312396, I contacted Daniel Spreadbury (Bravura's designer) to ask him about the smaller noteheads in the version of Bravura used in the 2.0.2 builds. He responded quickly, explaining that the change had been made to better comply with the SMuFL standards (which he also designed), which specified smaller noteheads.

However, he made it clear that not only are the original set of noteheads still available in Bravura, but that that Steinberg scorewriter (which, again, is Daniel Spreadbury's project, and the reason that Bravura was created in the first place) will not use the smaller noteheads, but will continue to use the larger ones, which he states are more legible.

The central portion of his email was as follows:

Perhaps the MuseScore developers will be able to sneak in a change to use the oversized noteheads in 2.0.2, or at least an option?

The glyphs in question are in a stylistic set, ss05, for noteheads that are larger relative to the space size, and can be found at these code points:

U+F4BA: noteheadDoubleWholeOversized
U+F4BB: noteheadDoubleWholeSquareOversized
U+F4BC: noteheadWholeOversized
U+F4BD: noteheadHalfOversized
U+F4BE: noteheadBlackOversized

Note that because these glyphs are in the optional glyphs range (U+F400–U+FFFF), their exact code point location is not guaranteed to be stable from one version of Bravura to the next, though I anticipate that they will remain where they are. Ideally, MuseScore should use the optionalGlyphs structure in the Bravura metadata JSON file to identify the code points for these glyphs in the corresponding version of Bravura, to be sure that they will always be located correctly.

If Nicolas, Werner or any of the other MuseScore developers need any further information from me about this, please invite them to get in touch with me.

Just to reiterate why this is important: not only are the larger noteheads obviously preferred, MuseScore 2.0 and 2.0.1 use the larger noteheads, causing scores using Bravura to look radically different in current 2.0.2 nightly builds. This change is essential for compatibility reasons, not just because the larger noteheads look better.

Comments

• Jul 10, 2015 - 17:08

In fact, I replied to him asking that same thing. ;-)

EDIT: … and received a response:

The problem with making the noteheads any larger than precisely 1 stave space tall is that whether or not the notehead will then poke through the stave lines above and below is a factor of the exact thickness of the stave lines. In Bravura's case, with the old, oversized noteheads, you need to have quite thick stave lines to avoid seeing the overshoot of the top and bottom of the notehead shape poking through into the next space. Since most programs allow the user to adjust things like stave line thickness, and some programs (e.g. Finale) typically use very thin stave lines (which is wrong, in my opinion at least), there is enough variability out there in the wild that, for a reference font, it was a bit too strong a design choice.

I certainly hope the MuseScore developers are able to take care of this issue without too much hassle.

All the best,

Daniel

Reply

• Jul 10, 2015 - 17:29

OK, that makes sense. I definitely figured it would have something to do with staff line thickness, since I saw that the new glyphs are exactly 1sp tall, and this creates exactly the effect we are seeing.

I wonder if an alternate approach might be to just scale the notehead glyphs on the fly according to the staff line tichkness? That is, by a factor of (staffSpace + staffLineThickness) / staffSpace. Perhaps that would come with too big a performance hit. If not, maybe that couuld even be made part of SMuFL - a flag somewhere to provide the hint that the default notehead glyphs should be scale according to staff line thickness.

Anyhow, for now, I definitely agree we should switch to the oversized glyphs. But it's kind of a shame that the the default glyphs treated in the default way currently fail to achieve to stated goals of Bravura.

Reply

• Jul 10, 2015 - 21:27

So now it occurs to me - we could potentially combine this with #60446: Add notehead size style setting for a more general solution. For each score font we support, we could have different notehead size defaults predefined, and these would be 100% for Emmentaler and Gonville (presumably) but 108% or whatever for Bravura. If there is a performance penalty to pay, it would be only for Bravura. Then we could re-evaluate alternate solutions for 2.1. I have to say I'm not really comfortable with the idea that we have to use stylistic alternates just to get what feels like it should be the default behavior. I understand the rationale, but I wish there were a better solution.

I'll try running some performance tests on my scaling idesa (108% makes sense as an initial guess, since the default staff line thickness is 0.08sp) to see how reasonable this might be.

Reply

• Jul 11, 2015 - 00:02

So far I'm not impressed with the benchmark results I have obtained from the first couple of ways I tried doing the scaling (in Note::draw() and Note::mag()). It could be a fluke - times are pretty variable.

But I think also, this might not be quite the right way to do it, because we actually use the width of the noteheadBlack glyph itself as a unit of measure from time to time. I suppose things should still work with scaling applied to the Note - if not, we're in trouble if people use the "small" setting on notes much - but better, perhaps, would be to scale the glyph itself right after we load it. I guess this would need to happen in ScoreFont::load() or ScoreFont::computeMetrics(), or something like that. This is now getting too low level for me to feel comfortable doing myself, though.

Looking at ScoreFont::load(), though, I see where stylistic alternates are handled, and it looks to be a very simple matter to just do the swap there. I just tried adding a few lines here:

https://github.com/musescore/MuseScore/blob/9e4f00207980e910297efc61b8c…

and presto, I got the oversized Bravura noteheads back, with no obvious negative effect on Emmentaler or Gonville, presumably because these fonts don't define oversized variants.

But I have to say, the oversized Bravura glyphs really are a little too big for the staff line thickness, and the scaling approach looked pretty sweet.

Reply

• Jul 11, 2015 - 19:04

And actually, I take back what I said about scaling the glyphs immediately on load - if we did that, we'd need to redo it every time someone changed the "notehead size" scaling option I was thinking we could tie into this.

So I definitely think the syltistic alternatives are the way to go for now. I am happy look at implementing notehead size scaling options for 2.1, and make sure we don't rely inappropriately on the glyph size directly when we should be using Score::noteHeadWidth(), and I would make sure we accounted for mag() correctly everywhere we need to.

Reply

• Jul 12, 2015 - 04:43

Oddly, it seems the oversized noteheads are actually slightly larger than the old default ones—but it's so close I'm prepared to say it doesn't matter. Thank you, Marc!

Reply