lilypond-devel
[Top][All Lists]
Advanced

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

Re: [GLISS] differentiating pre/post/neutral commands


From: Phil Holmes
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Date: Tue, 11 Sep 2012 13:18:20 +0100

----- Original Message ----- From: "David Kastrup" <address@hidden>
To: <address@hidden>
Sent: Tuesday, September 11, 2012 1:04 PM
Subject: Re: [GLISS] differentiating pre/post/neutral commands


Joseph Rushton Wakeling <address@hidden> writes:

On 01/09/12 17:25, Graham Percival wrote:
Continuing to brainstorm on the problem of it not being obvious to
which note a particular \command refers to, what if we used:

\postfix:      c2 d\p  is unchanged
/prefix: for music functions like   c2 /parenthesize d
.neutral: for commands which aren't attached to notes, such
   as .clef or .times.

Have to say that I think that there will be greater confusion down to
having 3 different ways to indicate a command, than there will be over
what entity the command applies to.

After all, the general form of

     \command x

is easy to understand -- \command applies to the entity x, or
alternatively to any group of entities contained in brackets { }.  I
don't think it's confusing in general that x could be a note or some
other entity.  (Are there good examples where it _is_ confusing?)

The tricky thing is when you have something like,

      c'4 \p c' c' c'

Ok, and now for something completely different.  I think there has been
one proposal to bring \[ \] in line with the post-event nature of [ ]
and ( ), but the one thing I have been thinking about recently is
whether we should not actually be going the other way round.


I've always thought that the post-event nature of lilypond is its own worst enemy. My particular pet peeve is that it means you can't terminate a piano pedal P with an asterisk * on the last note of a piece, since the \sustainOn occupies the post-event location and there's nowhere for the \sustainOff to go. I work round this with an extra voice and spacer rests, but it's not too clever.

As mentioned by me earlier in the week, it makes automatically generating code a bit odd, too, since you need to store the post events up until you've written the note.

--
Phil Holmes



reply via email to

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