----- Original Message -----
From: "David Kastrup" <[email protected]>
To: <[email protected]>
Sent: Tuesday, September 11, 2012 1:04 PM
Subject: Re: [GLISS] differentiating pre/post/neutral commands
Joseph Rushton Wakeling <[email protected]> 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
_______________________________________________
lilypond-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
