RE: [smufl] Add new 'Fingering' range

Daniel, 

 

I get it that you can represent it using text. However, there are reasons to cover it as fingerings. 

 

·         Formatting: as you indicated, formatting text is typically done differently than fingerings. Not only the font, but also the placement & centering is typically done differently

·         As a big proponent of semantic annotations, we should find a way to indicate fingerings, and then let the (musician) chose a “font” to render those. This allows to distribute and transform fingerings between musicians even if they have different habits of notating them (some trombone use arabic, others roman numerals for slide positions)

 

A real case in point for the semantic annotations are the harp pedals. I’m sure this cannot be covered by SMUFL, but it’s a valid point nevertheless: pedal positions are fixed, but are represented very differently between musicians (talk to orchestra librarians about their frustrations with harp players). 

 

So indeed, maybe this is better handled outside of SMUFL, and directly in the rendering engine. Which would mean that we need another standard to cover (semantic) annotations. Which reminds me of the Tanenbaum quote “The nice thing about standards is that you have so many to choose from”

 

 

JanR

 

 

From: Daniel Spreadbury [mailto:D.Spreadbury@steinberg.de] 
Sent: dinsdag 19 april 2016 17:36
To: public-music-notation-contrib@w3.org
Subject: Fw: [smufl] Add new 'Fingering' range

 

Sorry – forgot to send this reply to the mailing list.

----- Forwarded by Daniel Spreadbury/SMTG on 19/04/2016 16:36 -----

From:        Daniel Spreadbury/SMTG
To:        "Jan Rosseel" <jan@scora.net>
Date:        19/04/2016 16:35
Subject:        RE: [smufl] Add new 'Fingering' range

  _____  



"Jan Rosseel" <jan@scora.net> wrote on 19/04/2016 16:25:14:

> As someone said: zero is used in strings (not only guitars) for an 
> open string. 

Yes, fair enough.

> And 6&7? Talk to a trombone player. 7 slide positions. Not exactly 
> "fingerings" but numbers are numbers, right? 

Given that Arabic numerals are exceptionally well handled by just about any text font you can name, the only reason to encode these digits for fingering at all is if they have a special appearance specific to music that cannot be easily obtained using just about any text font you can name. The intention is to encode the slightly squat, bold "didone" digits that you typically see in published music, which are similar in style (though not identical to) those found in the bold weight of a typeface like Modern.

If brass players, with their multifarious ways of describing slide positions, valves, attachments, and so on, tend to use a variety of standard Arabic numerals with enclosures, then I would propose that we do not need to encode these in SMuFL, as these characters are well represented by existing text fonts.

In general, our rule with characters that are well represented by text fonts is not to encode them in SMuFL: only if they have an appearance that is specific to music should they be included. We have ranges of digits for time signatures, tuplets, octave markings, figured bass, and we have some (but not all) of the alphabetic characters for function theory symbols. I am not opposed to including another range of digits for fingering, but I do not want to end up encoding e.g. ranges of boxed and circled digits as well, as these kinds of enclosures are easy for consuming applications to create themselves, and failing that there are many fonts available that include support for enclosures around digits of various kinds as well.

Daniel



- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Steinberg Media Technologies GmbH, Frankenstrasse 18b, D-20097 Hamburg, Germany

Phone: +49 (40) 21035-0 | Fax: +49 (40) 21035-300 | www.steinberg.net

President: Andreas Stelling | Managing Director: Hiroshi Sasaki, Hirofumi Osawa

Registration Court: Hamburg HRB 86534

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Received on Tuesday, 19 April 2016 17:40:08 UTC