Daniel,
The MOLA demonstration of Write Mode in Dorico showed the available note values in the UI ranging all the way from maxima to 1024th notes.
SMuFLs principal Noteheads range, the Individual Notes range and the Metronome Marks range only account for note values from double whole note to 1024 note, while the maxima and longa are only available in the more specialized Medieval and Renaissance ranges.
This makes me wonder how the UI and other parts of the program deals with third party music fonts which support SMuFL, but does not contain any glyphs for medieval or renaissance notation. Will the UI still display the entire range of note values, and if so, how will the program respond when maxima or longa is selected in write mode?
Can you speak a bit more generally to the relationship between Dorico and third party music fonts?
Each project has its own data store called a “library” (probably not a name we will use when talking about this in our documentation etc.) that contains all of the entities that the project depends upon to draw itself, so that includes things like every notehead, every accidental, every clef, and so on. Each semantic entity refers to a “composite” (again, probably not a name you’ll see in the program itself), which is the thing that is actually drawn, and can consist of any combination of one or more glyphs from a font, a string of text in a particular font, and one or more graphics files.
So all of the note durations that you can write in Dorico have entities for their noteheads and their flags, each of which have their own composites defined.
If you switch from one SMuFL font to another (we’ve tested only with November and Bravura at the moment), then we assume that all of the necessary code points are mapped. It’s non-trivial to determine whether or not a given code point is mapped in a specific font, because the OS and/or the application framework you’re using tries its best to produce a character for you (e.g. by substituting another font, or by showing a special “empty” character), so in general we can’t know up-front whether or not e.g. the maxima notehead is going to be available in a given font. So you could end up with a substituted character if you subsequently try to type a maxima and the font doesn’t specify it.
For things where we are using optional glyphs as defined in SMuFL, e.g. for short flags, or for oversized noteheads (Dorico uses oversized noteheads by default), we do not assume that these will be present (and even if they are present, there’s of course no guarantee they will be at the same code point as they are in Bravura), so we don’t try to update these.
If you find, after switching font, that one or more items in the score doesn’t draw as you would expect, you will have to fix up the composite used for that item, which will then save that change into the library saved within a project. The idea is that you will be able to import and export that library into other projects, and even specify that a particular change should be considered your default for new projects created from that point onwards.
Thank you for the explanation, Daniel.
I take it this means that the actual icons in the note value pallet will not reflect any limitations in the character set of the selected music font?
Also, regarding stylistic alternates: If the selected music font actually does contain oversized notheads (or any other variant set up in the default library), but have these encoded differently from Bravura, will the font’s OpenType features make sure the correct character is displayed, or will these have to be updated in the library as well?
The icons shown in the note input panel don’t reflect the music font currently in use; they are taken from a completely different font, and you can always input a maxima, even if you end up with a weird symbol, i.e. the program doesn’t disallow you from writing a note value that ends up with a peculiar symbol because of the capabilities of a specific font.
As yet, the substitution of things like stylistic alternates is handled manually rather than through any direct support for OpenType features, so there are separate composites for oversized and non-oversized noteheads, for example. We hope to be able to expand on this in future, but since there is very little direct support for advanced OpenType features in the Qt application framework, a lot of this will need to be written by us directly, and all of that takes time.