lilypond-user
[Top][All Lists]
Advanced

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

RE: Fis or not fis, that is the question.


From: Ralph Little
Subject: RE: Fis or not fis, that is the question.
Date: Tue, 10 Dec 2002 15:48:57 -0000

HEEEYYY! COOL DOWN Mister!
Keep yer hair on!
I have not heard of anybody being annoyed at the way Lilypond works!??!?

Ok Ok,
First let me say that I am happy to carry on with what Lily currently does.
After using it for some months, I find it easy enough.
When designing software (and believe me I know what I am talking about,
being a C++ programmer, database designer and a project manager for a
bespoke software house) you need to make design decisions at the beginning
and stick to them.

I query only the particular reasoning behind the rationale currently
employed, especially since we occasionally get readers that pose this very
question from time to time and, thus far, I have not seen an answer to
convince me to the bottom of my heart of the fundamentals behind the method
chosen.

OK, well what am I on about? 
Since were kind enough to ask:

Currently, we have:

\score {
        \key g \major
        g2 a b c d e fis g
}

What's wrong with:

\score {
        \key g \major
        g2 a b c d e f g
}
...which generates o o o o o o #o o.

It is self-evident from the fact that the key is G, that all f's are
sharpened other than those altered by accidentals. It does not have to be
directly specified. 
Being a fundamentalist at heart, I hate to see apparent redundancy in
anything, and I have to say that my heart says that to have a key including
"fis", "fis" should not have to be specified in \notes {}.

For a natural we could have "fn" or \natural {f}.

 >> Would you like to be able to simply specify which accidentals lilypond
 >> was to write instead of which notes they were to represent?

The representation in the script should not affect the rendered
representation in the output. Lilypond knows what the key is and can (and
does) make decisions as to whether or not to render sharps/flats/naturals
etc dependant on the context regardless of which method is used.

>> Generally, this approach leads to a total overlap between notation and
>> music - actually your note entries even depend on the TIME SIGNATURE
>> (!!!) - if you for instance should feel like replacing 4/4 with 8/4,
>> then the 5th note should be g instead of gs.

No, that is incorrect. It would be correct it you had to handle accidental
policy in the notation specified, but you don't. All I am suggesting is that
where the key signature gives a default, that default should be applied
across the board apart from notes that you specify differently. As far as I
am concerned, there is no current relationship between baring and key. 

If you type something like as it stands:
\score {
        \time 4/4
        \key g \major
        \notes {g2 fis4 f f f f f }
}
...you get a second bar full of of naturals. Lilypond makes the assesment as
to whether or not to print naturals using the current natural regime.

Alternatively taking the key into account,
\score {
        \time 4/4
        \key g \major
        \notes {g2 fis4 fn fn fn fn fn}
}
....changing the timesig to 8/4 will have no affect on the notation
whatsoever. You will still get the right notation.

>> { gis g gis gis | gis gis ges g }
OK, this is a bit of an extreme example.

Let me give you one of my own:
\score {
        \key cis \major
        \notes {cis dis eis fis gis ais bis cis}
}
Que?

To my mind (and it is just my opinion) catering for the common case rather
than the rare case is better. Using either method, you cannot just change
the key sig and expect it to work, so that is a red-herring. The key and the
notes are linked forever, you can't change the key without changing the
notes, and transposition is best done using \transpose.

Therefore, my only conclusion is that the choice of what to go with is
entirely down to preference.

Which I am happy to go with, as I have for a number of months now...
My 3 pennyworth....

Ralphy

-----Original Message-----
From: Rune Zedeler [mailto:address@hidden
Sent: Tuesday, December 10, 2002 3:12 PM
To: Ralph Little
Cc: address@hidden
Subject: Re: Fis or not fis, that is the question.


Ralph Little wrote:

> Can anybody explain why, despite having a "fs" specified by the current
key
> (for G Major), "fs" or "fis" needs to be specified, rather than just
> assuming that the key fills in the gaps?

I don't really understnad what you expect/request.
Would you like to be able to simply specify which accidentals lilypond
was to write instead of which notes they were to represent?
This would be a hell to work with.
Think of this example:

{ gis g gis gis | gis gis ges g }

This gives output (n meaning natural):

 #O nO #O O | #O O nbO nO

Would you REALLY prefer to input it like

{ gs gn gs g | gs g gnf gn }

?!?!
This way you would need to explicitly think about all the sophisticated
rules about accidental typesetting - and if you should wish to alter an
accidental-rule you would have to change all your input by hand instead
of simply replacing the accidental macro with something else.

Generally, this approach leads to a total overlap between notation and
music - actually your note entries even depend on the TIME SIGNATURE
(!!!) - if you for instance should feel like replacing 4/4 with 8/4,
then the 5th note should be g instead of gs.
No, I really don't understand why people are so unhapppy about the lily
approach. Before finding Lily, I took a look at abc and Music-TeX, and i
thought "Yikes, this is far to notation-concrete. Surely not flexible
enough!". I found Lily - and I just thought "YES, THIS IS THE WAY TO DO
IT - THIS IS WHERE I WANNA BE!"
I REALLY, REALLY, don't understand why so many of you are annoyed with
the way that lilypond works.

Did I misunderstand your request?

-Rune

---------- 
Our communications with you matter to us. This e-mail and any attachments
are confidential and are sent on the basis of our copyright, e-mail and
security policy which can be inspected at our website at
http://www.tribaldata.co.uk/html/contact.html#6. If you are not the intended
recipient, please notify the sender and delete this message.  Thank you. 
---------- 




reply via email to

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