Bug report: repeatOffset of arpeggio wiggle

When creating a new project from Steinberg Hub, the connection of the down arpeggio is misaligned:

Re-selecting the font in Music Font dialog will fix this:

This may be a bug, as it occurs in all fonts, including Bravura.

What in your opinion is misaligned? And isn’t the second image identical to the first?

The only difference I can see is the shape of the wavy line

Look at this part:

The differences may be more obvious in Sebastian font:
selected in Steinber Hub and selected in Music Font dialog

I can confirm that the thickness of the lower end of the wavy line, just above where it contacts the arrow head, changes when the music font is re-selected.

Not only arpeggio down, but also general arpeggio (up) wiggle seems to be out of tune. No differences are observed in Bravura font, but differences are noticeable in Sebastian font.
When creating a new project from Steinberg Hub with Sebastian font:

And when re-selecting the same font, Sebastian, in Music Font dialog:

Thus, Dorico seems to have problems with loading the repeatOffset values of the arpeggio wiggle in the SMuFL metadata.
I found this phenomenon while working on designing a new commercial SMuFL font, and our font also encounter this issue.

The title of this thread was changed from Bug report: down arpeggio to Bug report: repeatOffset of arpeggio wiggle.

1 Like

I’ve been looking into this today, and it’s quite a subtle problem. The issue is to do with the order in which things happen. In general, we try not to load up the library in a project with loads of items that are not going to be used, so when you first create a project, the library items required to show arpeggio signs are not present: they are only added when you first add an actual arpeggio sign to the project.

As such, when Dorico updates the library with the appropriate values from the SMuFL metadata when setting up a new project via the Create New page of the Hub, it won’t apply the values from the metadata file to the arpeggio sign items, because they don’t yet exist in the project’s library. When you then add an arpeggio sign, Dorico pulls in the items from the factory library, but the values in the factory library all assume Bravura, and Dorico isn’t currently able to update those values from the metadata that corresponds to the music font currently in use. (Even the default values in the factory library and the values in the Bravura metadata file don’t match exactly in every case.)

So that is why the values are only updated after you use Library > Music Fonts to switch music font, even if you switch to the same music font that is currently in use. Dorico then applies the values from the metadata file to all of the relevant items in the project library, which now includes the items required to show arpeggio signs.

We’ll be able to improve this in future, I’m sure. The simplest approach will be simply to ensure that the relevant items for arpeggio signs are present in the project library when creating a new project.

There is a similar issue with note stems being mis-aligned in some fonts, under some circumstances, which can also be fixed by re-applying the Music Font.

In fairness, some of those Sebastian offsets probably need looking at…

Thank you for looking into the details and reporting back to us. I expect future improvements and will report a SMuFL-related case, on a different note.
Dorico uses mensuralNoteheadMinimaWhite (U+E93C) as White Diamond Noteheads for artificial harmonics.
Even if the music font is changed, the glyphsWithAnchors of Bravura are inherited; It would be nice if this is fixed as well.
our font
(Incidentally, why is mensuralNoteheadMinimaWhite used for White Diamond Noteheads? This glyph should be used for medieval mensural notation as its name implies. In our font, we will put noteheads for harmonics in U+E93C for the time being, though.)