[Top][All Lists]

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

Re: Key and accidentals in Lilypond

From: Simon Bailey
Subject: Re: Key and accidentals in Lilypond
Date: 06 Dec 2002 20:28:39 +0100

On Fri, 2002-12-06 at 18:26, s.abeccara wrote:
> yes, I downloaded the entire archive, but the answer has been far from
> helpful.

just to put the record straight, this was something that bothered me a
little bit when i first started using lilypond. but after the
explanations offered in the last discussions, i understand why lilypond
uses this approach and agree with it. it makes more sense to me.
especially if you look at the arguments rune and david posted this

> just putting a symbol telling Lilypond the "f" has to be scaled down
> half a tone, like in normal, human music. 

if you really want this approach, you could try abc. in abc if you put a
piece in a key-signature, then you have to explicitly state the

i do however think that lilypond is way more powerful, and produces
better looking music. this is my personal opinion.
> |i think the approach han-wen
> | et al have chosen for writing the notes of a piece of music follow all
> | musical rules in the book. 
> which book?

this is an idiom meaning that which is generally seen as correct. if i
may quote rune: "Lilypond DOES follow common notational behaviour." this
is what i meant by "all the rules in the book". :) i am also sure that
if you look at any book or tractate on musical theory, then you will see
that a key signature only changes what is printed. a written f in our
much maltreated g major is an f sharp. therefore it makes sense [to me,
and to many others, i assume] to explicitly state it is an f sharp.

> if i'm reading a piece in g major, then i
> | will read any note in the bottom space of the treble staff as an
> | f-sharp, not as an f. so i write "fis" for this note... :o)
> i don't agree. it is really not an f sharp, it is a natural f in the
> key of G, so nothing has to be added to it. if you are singing a piece
> and you aren't told which key it is in (unless you have an absolute
> ear) you will sing "sharp" notes completely automatically, like
> natural ones. :o)

the key of g tells us that this note is an f-sharp, even if it is the
"natural" f in this context (from a certain point of view. it makes a
large difference on the trombone -- f is played in 1st position, f# in
5th or 3rd, depending on the octave). my understanding is that a key
signature just tells us, starting from a given note, which notes are to
be augmented from their natural state to make the
tone-tone-semitone-tone-tone-semitone pattern for a major scale (or any
other patterns for the other scales). in this case, i think that the
lilypond approach is the syntactically more correct approach.

> for people really playing and singing music, and not simply
> typesetting it, this is ridiculous.

these are two different kettles of fish. players and singers will never
(almost never) see your lilypond code used to typeset a piece of music
for them. they couldn't care less if you have to write fis or f, they
just sing or play whats on the sheet of music. lilypond is a tool for
typesetting music, which is the precursor to playing or singing it. 

i recently typeset a march for our concert band. we have instruments in
F, E-flat, B-flat, C and one crazy guy who plays a D trumpet, but cannot
transpose. using lilypond, i could write all parts of the march for c
instruments and just transpose the parts to the correct keys for the
relative instruments. including a part for the d-trumpet which was a
matter of changing one line of code... as rune and david stated earlier
today, this would be difficult, if not impossible, to implement if
lilypond were to automatically assume an f in g major is really an

most of this is my personal opinion. feel free to flame me if you wish,
but i think that the approach lilypond uses is the most logical way to
typesetting music without using a mouse.

Don't be irreplaceable, if you can't be replaced, you can't be promoted.

reply via email to

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