Re: Same symbol, different SMuFL semantics

On 2/2/2017 7:01 PM, Michael Good wrote:
> Hi Jeremy and Glenn,
>
> Thank you for your thoughts here.
>
> Jeremy, what you propose about adding a SMuFL glyph attribute is similar
> to one proposed solution for the coda and segno alternates (issue
> 84: https://github.com/w3c/musicxml/issues/84). If we go in this
> direction, I would like to go with the existing smufl attribute group -
> a smufl attribute where the content is the SMuFL canonical glyph name,
> not the code point.
>
> I don't think we will be able to do a "complete" version where every
> possible MusicXML element with alternate SMuFL glyphs will be covered,
> but I think it's a simpler approach than adding lots of additional
> elements throughout the format. The one place we have been doing that is
> in the percussion element.
>
> Glenn, you raise some very interesting questions. An overall issue with
> music from notation applications is that the emphasis at publishers has
> usually been to make it look good in print. We are starting to see that
> change to print and digital, but there's a large repertoire of existing
> music files where semantic entry is an issue. Older files tend to have
> more problems, as notation software does an even-better job over time of
> guiding users to better semantics. However people under time pressure
> may still enter things "wrong" if it is faster and looks good (e.g. the
> first category your software suggests that has the symbol you are
> looking for).

Yep, the first music typesetting program I wrote, I definitely did some 
things for a while that looked OK, but were semantically wrong.  After 
the program became more polished and complete, I fixed those things in 
the data files, mostly, I hope :) So I understand what you are saying 
there, about looking good in print.

As a semantic categorization may or may not be able to be automated for 
all such symbols (but maybe it can for some, in some cases), it might 
well be possible for software to be enhanced to point out the ambiguous 
symbols for clarification. My comments about asking the human operator 
were envisioning some such scheme, perhaps a "pre-flight check" before 
saving as the new version of MusicXML.  If the new version would come 
with lists of the ambiguous symbols (homoglyphs), and their possible 
semantic categorizations, perhaps software would be encouraged to code 
such pre-flight checks, making it easy for human operators to make the 
decision (hopefully correctly, but as you point out, you get what you 
get when people are in a hurry). Making it clear that there are 
ambiguous symbols, and that there are alternate semantics for them in 
the spec, rather than conflating them to a single (wrong) symbol, would 
help encourage people to choose the correct semantics, and would also 
relieve the spec of choosing to do it the ambiguous (semantically 
incorrect) way, rather than making the semantically correct choice. If 
applications do it incorrectly or ambiguously, and if old data files get 
converted incorrectly or ambiguously, at least it wouldn't be the spec's 
fault, and if/when people care, it could be corrected.



An interesting thing that I only recently discovered is the term "volta 
brackets" for 1st & 2nd ending boxes... the word "volta" doesn't appear 
in the SMuFL spec, and it took some looking to find the metadata for 
"repeatEndingLineThickness" which appears to be the only mention of the 
concept in the whole SMuFL spec. I'd always called them repeat boxes, 
and 1st and 2nd endings, but ran across what seems to be their proper 
name, and was then surprised that that name wasn't mentioned in SMuFL. 
On reflection, I shouldn't be surprised, since I had read the whole 
SMuFL document when it first came out, and hadn't learned the term then! 
It might be nice to add a reference to "volta brackets" in the SMuFL 
spec, connected with the "repeatEndingLineThickness" metadata.

I mention this, partly because in rewriting my program to support I18N, 
scalable fonts and SMuFL, I've been needing to cross-reference my 
terminology (I'm more a programmer than musician, but I've had input and 
feedback from musicians during the process over the last 30 years) with 
the SMuFL terminology. And, my software has general line drawing 
features, which were used for volta bracket creation, but no specific 
feature for drawing the concept, which I will likely add in this 
rewrite. Happily, for the type of traditional music my users deal with, 
I need only a small fraction of the SMuFL concepts and Bravura glyphs, 
but it is amusing to discover a "proper term" and then discover it 
missing in the spec!

Glenn

Received on Friday, 3 February 2017 04:38:25 UTC