[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sharping naturals

From: David Kastrup
Subject: Re: sharping naturals
Date: Sat, 25 Jul 2015 09:04:01 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Kieren MacMillan <address@hidden> writes:

> Hi David,
>> What _is_ the current key signature?
>> \key a \major \transpose c d { \key f \major \transpose d f { a b c
>> d e f g } }
>> What should the result be?
> Well, when I run that code in Lilypond, the visible key signature has
> three sharps.

[Slaps forehead] The visible one.  Because I have two key signatures at
the same time and the second one gets junked.  That's actually a
complication in the example I had not planned for.  Uhm, put a c before
the second \key f \major.  At any rate, it's rather essential for
figuring out the meaning of all that that the pitch names reliably spell
out a particular pitch and don't float meaning along with the "current
key".  The second key could be g \major, it could be gis \major or it
could be ges \major depending on whether its "f" means "f" or "fis" and
whether \transpose c d actually means \transpose cis d.  And then the
meaning of _that_ key is supposed to determine the meaning of anything
ambiguous that follows.

> Whether or not that is the key signature the OP wants to work in would
> be the OP’s problem.

If we wanted to support "natural English note entry", it would become
LilyPond's problem.  And that's a problem I prefer not having.  Our
current manual section explaining the Dutch notename philosophy is a bit
overbearing but reasonably clear.  I shudder at having to write a manual
entry explaining how to interpret the above passage in English notename
philosophy rather than Dutch one.

>> "You don't want to go there" is something nobody ever believes me, so
>> I have to settle for "if you want to go there, you'll need to learn
>> how to do it yourself, and by the time you know how to do it, you'll
>> understand why it's a bad idea”.
> OK.

In that case I think it's really better solved in the editor.  If the
editor automatically adds accidentals based on some current "input key"
which you change explicitly, the result is predictable and unambiguous
and you still save most of the key presses.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]