Re: [Lilypond-auto] Issue 4076 in lilypond: allow bn for B-natural in English

[lilypond]

Comment #36 on issue 4076 by address@hidden: allow bn for B-natural in English
https://code.google.com/p/lilypond/issues/detail?id=4076

Personally, I think you did not pick the best example reply.

The main problem I see with this approach is that it introduces an "equal"  
representation for the same pitch.  We have a few notename aliases,  
like "aes" for "as", that are "secondary": if we use \displayLilyMusic on  
them, we expect to see "as" and will not be disturbed by the  
canonicalization.  In some manner, this is the case for English as well: we  
don't really expect to see the long note names with \displayLilyMusic  
though it would be conceivable to let some commands like \key prefer using  
them where available.

The b/bn choice however is different since it is key-dependent and possibly  
also context-dependent.  A bn would likely be used in a similar manner to  
b! for a forgetful accidental rule.  If you use
\displayLilyMusic \transpose cs cn { cs1 ds1 }
you'd expect to see cn/dn vs c/d depending on the key that the  
transposition ends up in.

LilyPond-aware editors offer functionality like transposing some sequence.   
They cannot really properly preserve the c/cn distinction in any manner  
since there also is no c sharp (part of key signature) and c sharp (out of  
key signature) distinction in the input language either.  Where this  
distinction is notationally important, one uses ! on the pitch.  But !  
actually is not part of the pitch but rather only of notes.  So one has to  
write, for example, cis'! rather than cis!'.  And its effect is on the  
typesetting, not on the actual pitch as played.

Now the main problem I see with bn is not that people need an error thrown  
in order to figure out that b and bn are actually the same: learning  
through error messages is not really all that good of an idea anyway, and  
there are lots of constructs that surprisingly end up being valid LilyPond  
code:

g♭ = ges = \relative {c = \g♭}

Guess what the diagnostic for this one will be.  I digress.

The main problem is that the whole _purpose_ of bn is to facilitate a  
writing style strictly distinguishing between b and bn.

People learn by example.  A lot.  If this writing style becomes common,  
we'll have a lot of people putting work into choosing the proper version of  
b and bn without understanding that there is no effect.  And music  
transformations will not preserve that difference.

Now to some degree the whole point of note languages other than nederlands  
is to let people enter stuff in a notename language they are comfortable  
with.  And if people are uncomfortable writing b for b-natural in some  
contexts, providing bn might help.  But they still won't be able to write b  
to mean b-flat in a context where they will they should write bn to mean  
b-natural.

I've looked through both patch series again: both API and documentation  
changes in the last one seem quite uncalled for to me (and I have no idea  
why you would want to hide a thing like renaming "Accidentals" chapter and  
terminology to "Alterations" as part of this issue: it is quite unrelated).

If there is a point to it, we'd rather want to stay with the first variant  
of the patch, but it would need to have additional notenames anatural  
bnatural cnatural ... gnatural as well.

Regarding the long note names, I'd lean towards a renaming spree in a  
separate issue, making for a-natural b-sharp, c-flatflat, d-sharpsharp.  I  
think that this syntax, unavailable before issue 2702, would better match  
the long names' intent, with

\key a-flat

or similar.  However, this is a separate issue.  Having a note name  
anatural makes it somewhat more desirable, but anatural definitely belongs  
here, as part of the _first_ proposed patch series.

--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings