Re[2]: Fis or not fis, that is the question.

[Jérémie Lumbroso]

Hello Ralph,

Tuesday, December 10, 2002, 4:48:57 PM, you wrote:

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

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

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

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

RL> Currently, we have:

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

RL> What's wrong with:

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

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

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

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

RL> The representation in the script should not affect the rendered
RL> representation in the output. Lilypond knows what the key is and can (and
RL> does) make decisions as to whether or not to render sharps/flats/naturals
RL> 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.

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

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

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

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


RL> To my mind (and it is just my opinion) catering for the common case rather
RL> than the rare case is better.

This isn't about making it simple or not. If you want simplicity, opt
for Finale 2003, Sibelius 2 or any other WYSIWYG notation program. Those
editors are focused on the notation, hence the designation, and
therefore do exactly what you've been describing.

Lilypond's aim is to focus on the music itself rather than just
deciding to be a simple markup language. It should be possible to take
any note fragment of Lilypond and know exactly what it's about. Using
your method how can you this:

  a8 g b d e c4 c2 ~ c16 d8. d4 d'4 e e8. b16 a'1

means this:

  aes8 g bes des ees c4 c2 ~ c16 des8. des4 des'4 ees ees8. bes16 aes'1

and furthermore, if you decide after input to omit the key for different
[editorial] reasons (like when deciding that the piece is actually not
really in that tone), how do you do?

The key doesn't really matter in fact: it's a very optional glyph, you
know. I have a lot of examples of [early] sheet music in which no key
accidentals where given... the point of which is that the input should
not be centred around it.

Of course, I'm sure the new Scheme macros accessible in Lilypond would
easily allow you to do something like this (really guessing, and
pseudo code):

  if note == f then transpose cis { note };

And I'll stop because you obviously have a strong will if you haven't
agreed, after what Rune said. It seem that those aforementioned
WYSIWYG solutions what agree with you better.


-- 
Best regards,
 Jérémie                            mailto:address@hidden