|
These ranges are a very welcome addition, but I have difficulties in understanding the rationale(s) behind the specific selection of included symbols and behind their organisation.
_________________
The "Medieval and Renaissance individual notes" range (U+E890 – U+E8AF) appropriately and usefully distinguishes between black notation and white notation and even includes the black notes with coloration; however it lacks the white semibrevis and all the white notes with coloration.
It is true that a white semibrevis looks very similar to a black semibrevis with coloration and that a white with coloration looks in most cases similar to its black counterpart, however their semantic is very different and the standard already distinguishes between a black brevis with coloration (U+E896) and a white brevis (U+E89E), which also look rather similar (but have very different meaning).
Thus, I would like to understand if the principle behind this section is semantic or visual.
__________________
The "Medieval and Renaissance noteheads and stems" range (U+E870–U+E88F) lacks the distinction between black and white notation (and the concept of coloration) and seems to go only by the visible look of notation elements.
Is this an explicit decision? Is semantics consciously ignored in this section?
The modern restitution of black notation is of course (loosely) based in manuscript sources, while the white notation restitution is usually based in printed sources. This entails a clearly distinct visual aspect; so, even on a purely visual base, a differentiation could be useful, at least at the stylistic alternate level.
_________________
As a general (side) note, I understand that the SMuFL standard is primarily intended to address the needs of notation programmes with as little fuss as possible, but one of the great advantages of scoring programmes is the possibility to store (and later retrieve and manage) the semantics of music elements in addition to their look, a perspective which could make sense in a standard for music notation(s).
Thanks,
Maurizio M. Gavioli
|