lilypond-user
[Top][All Lists]
Advanced

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

Re: Accidentals: Unwanted naturals


From: David Rogers
Subject: Re: Accidentals: Unwanted naturals
Date: Fri, 28 Aug 2009 12:30:16 -0700

On Fri, Aug 28, 2009 at 10:58, Kieren
MacMillan<address@hidden> wrote:
> Hi David (et al),
>
> Just to be absolutely clear, the fallacy in your argument lies in the
> following statement:
>
>> It's necessary to consider the sound of the music,
>> *and not the conventional rules of printed scores*
>> when doing Lilypond pitch input.
>
>
> Quite the contrary, the "conventional rules of printed scores" DO consider
> (incorporate) "the sound of the music" — that's why the Western notation
> system works as well as it does (despite some flaws/shortcomings, and
> countless attempts to replace it with a "superior" alternative).
>
> Let's start by considering the CRoPS with respect to a simple notation
> example. If the key signature is D major (i.e., two sharps), and the pitch
> class [!!] being displayed is the top line of the treble clef (i.e., F),
> then the CRoPS tells us that the actual pitch that should be performed is an
> F-sharp (i.e., fis'').
>
> Now, let's "do Lilypond pitch input" for this same example. You want
> Lilypond to output an F-sharp at the top of the treble clef, and display the
> result "in D major" (i.e., with a D major key signature).
>
> Step 1 is to define/list the pitch(es) you want engraved:
>   theMusic = { fis'' }
>
> Step 2 is to build the score, with clef and key signature:
>    \score { \new Staff << \key d \major \clef treble \theMusic >> }
>
> Doing the same thing *without* the pitch alteration (sharp) in theMusic
> definition exposes the fundamental problem with a "follow-the-key-signature"
> approach.


I know that. I think Lilypond is operating correctly here, that this
part of the code should be kept as is with nothing added, and that
those users who wish it operated differently are making a mistake, for
exactly the reasons you've just pointed out.

HOWEVER, I think it's necessary to explain this issue *in their terms*
in the documentation, so that they can stop being confused by a
perfectly good (but logically backwards *to them*) implementation,
letting them get on with their work.

-- 
David Rogers




reply via email to

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