|
From: | Phil Holmes |
Subject: | Re: [GLISS] differentiating pre/post/neutral commands |
Date: | Tue, 11 Sep 2012 13:18:20 +0100 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |