lilypond-user
[Top][All Lists]
Advanced

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

Re: Suggestion to make sharps and flats persistent


From: Carl Sorensen
Subject: Re: Suggestion to make sharps and flats persistent
Date: Tue, 19 May 2020 17:14:25 -0600



On Tue, May 19, 2020 at 4:13 PM David Kastrup <address@hidden> wrote:
Carl Sorensen <address@hidden> writes:

>> ---------- Forwarded message ----------
>> From: Kieren MacMillan <address@hidden>
>> To: David Nalesnik <address@hidden>
>> Cc: Lilypond-User Mailing List <address@hidden>
>> Bcc:
>> Date: Tue, 19 May 2020 10:22:15 -0400
>> Subject: Re: Suggestion to make sharps and flats persistent
>> Hi David,
>>
>> > But minor-mode music is often a conglomeration of the "forms" of the
>> > minor scale which makes them of limited separate utility.  Nothing is
>> > in "harmonic minor."  Notating something in minor by J. S. Bach could
>> > be terrifying.
>>
>> Oh, I totally agree with "terrifying" (and, in my opinion, unhelpful).  =)
>> I’m just pointing out that it’s not difficult to figure out how to make
> it work for people who don’t mind living in terror.
>>
>
> But if we support terrifying modes, then we have to deal with all of the
> issues that come fom people having difficulty with terrifying modes.
>
> I'm a firm believer in the simple statement that in LilyPond, you type the
> pitch you hear,

Well, no.  There are enharmonics.  The same pitch you hear has different
spellings for writing.

That's true.  I probably should have said "You type the desired spelling of the pitch you hear."
 

> and the software is responsible for getting the display correct
> (strictly speaking, this means that I should oppose relative mode,
> although I admit I'm inconsistent here).


> Supporting difficult syntax is harder stil -- it'a an ongoing expense.
>  That's why I'm so appreciative of David K's work to simplify and
> rationalize our syntax so it (almost) always works the way one thinks it
> should.

Anecdote: in January there was the note typesetting conference in
Salzburg and I typed up some example along the lines of

\override NoteHead.color = #red

and then Han-Wen interrupted (or took me aside afterwards or something,
I don't quite remember) and said that I needed to write

\override NoteHead color = #red

instead.  LilyPond actual still does accept that syntax for
compatibility reasons.  But since things like NoteHead.color have now
gained the Scheme representation of #'(NoteHead color) and a whole
number of user-level functions make use of that, it completely threw me
for a loop to get the suggestion of writing something that no longer
fits the way I have come to think about NoteHead.color : not as some
arbitrary syntax but something conveying a meaning also represented in
Scheme.

I wonder for how many other old users of LilyPond these changes in
meaning that have become the natural view for me (and hopefully new
users) just did not happen since a whole lot of the old syntax of
LilyPond continues to work well enough without viewing it in terms of
structuring concepts that came after the fact.

I'm an old user of LilyPond, and I don't really have the Scheme representation built into my understanding of the new syntax, but I love the new syntax because it makes it painless for me to burrow down into some complicated alist structure and just get the individual property I want.

I realize that this is due to the Scheme structure being what it is, but I don't think about the Scheme structure any more, most of the time.  I just think about the . operator being the equivalent to a member property (just as it is in Visual Basic).  Losing track of the Scheme representation means I have to remind myself of it when I want to write some Scheme, but when I just want to write LilyPond I can ignore the Scheme representation.  And that is convenient for me.

So thanks!

Carl
 

reply via email to

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