[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Substitute for s1*0
From: |
David Kastrup |
Subject: |
Re: Substitute for s1*0 |
Date: |
Mon, 07 May 2012 13:58:52 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) |
"Trevor Daniels" <address@hidden> writes:
[...]
> Let's forget the unrealistic convoluted examples and look
> at a real case where s1*0 is necessary and is used in the
> docs (taken from
> http://www.lilypond.org/doc/v2.14/Documentation/notation/common-notation-for-keyboards
> )
>
> It's needed when a crescendo ends on the final note in a
> music expression. The three ways of doing this are:
>
> \relative c' {
> e2\p\< d\> s1*0\!
> }
> \relative c' {
> e2\p\< d\> <>\!
> }
[...]
> Of the two remaining, I find s1*0 clearer than <> in this
> example, so I am not in favour of a blanket change to <>
> in the docs. But I am in favour of documenting the
> already-existing semantics of <>.
The advantage of any blanket change is that it promotes not having to
think before acting. Thinking has its place, but a musician thinking
about every note or a programmer thinking about every symbol are not
going to be effective. "x is clearer than y in this example" views this
example as independent from every other example. Would it help to write
\relative c' {
e2\p\< d\> < >\!
}
I actually don't think so. Keeping <> together makes it somewhat easier
to identify it as one logical block. Would it help to write
\relative c' {
e2\p\cr d\decr <>\!
}
Absolutely, yet nobody wants to argue that.
Are there situations where one would _not_ want to use or recommend
\relative c' {
e2\p\< d\> s1*0\!
}
as a building block?
Absolutely:
\relative c' {
e2\p\< d\> s1*0\!
} \addlyrics { Oh no }
\relative c' {
e2\p\< d\> <>\!
} \addlyrics { Oh yes }
delivers
lilypond /tmp/test.ly
GNU LilyPond 2.15.38
Processing `/tmp/test.ly'
Parsing...
/tmp/test.ly:0: warning: no \version statement found, please add
\version "2.15.38"
for future compatibility
Interpreting music...
/tmp/test.ly:3:18: warning: Two simultaneous lyric events, junking this one
} \addlyrics { Oh
no }
/tmp/test.ly:3:15: warning: Previous lyric event here
} \addlyrics {
Oh no }
Preprocessing graphical objects...
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `test.ps'...
Converting to `./test.pdf'...
Success: compilation successfully completed
And the lyrics of the first system are missing (in spite of what the
error message suggests, _both_ are missing, though for different reasons
both of which will be rather hard to understand) whereas the lyrics of
the second system are fine.
So from a purely technical point of view, a blanket change of s1*0 to <>
in the docs will leave the user with fewer concepts to learn, and with
fewer surprises to expect later on.
I am somewhat sympathetic to extend the parser in a manner where a music
command can take an arbitrary long list of post events and thus enable a
command that will do the equivalent of <>. However, there seems little
point in cooking up new event types for wrapping postevents when
EventChord already does exactly that, and it seems awkward to reuse the
existing structure < > when \displayLilyMusic <> and
\displayLilyMusic \null would be required to produce identical output.
I totally don't understand the rationale for keeping the users in the
dark about a technically superior (and easier to type and understand)
solution for a frequent problem that works with all relevant versions of
LilyPond.
And I don't have the personality required for dealing with a discussion
that leaves me flabbergasted at every turn.
So you all can consider myself silenced on that matter, and I won't
propose any patches or documentation changes regarding it.
Congratulations. Though I don't really understand what you gain.
--
David Kastrup
- Re: Substitute for s1*0, (continued)
- Re: Substitute for s1*0, James, 2012/05/07
- Re: Substitute for s1*0, Trevor Daniels, 2012/05/07
- Re: Substitute for s1*0, David Kastrup, 2012/05/07
- Re: Substitute for s1*0, Graham Percival, 2012/05/07
- Re: Substitute for s1*0, Ian Hulin, 2012/05/07
- Re: Substitute for s1*0, Graham Percival, 2012/05/07
- Re: Substitute for s1*0, David Kastrup, 2012/05/07
- Re: Substitute for s1*0, Carl Sorensen, 2012/05/07
- Re: Substitute for s1*0, David Kastrup, 2012/05/07
- Re: Substitute for s1*0, Trevor Daniels, 2012/05/07
- Re: Substitute for s1*0,
David Kastrup <=
- Re: Substitute for s1*0, Nicolas Sceaux, 2012/05/07
- Re: Substitute for s1*0, James, 2012/05/07
- Re: Substitute for s1*0, Graham Percival, 2012/05/07
- Re: Substitute for s1*0, Trevor Daniels, 2012/05/07
- Re: Substitute for s1*0, Keith OHara, 2012/05/07
- Re: Substitute for s1*0, David Kastrup, 2012/05/08
- Re: Substitute for s1*0, Trevor Daniels, 2012/05/08
- Re: Substitute for s1*0, David Kastrup, 2012/05/08
- Re: Substitute for s1*0, Trevor Daniels, 2012/05/08
- Re: Substitute for s1*0, David Kastrup, 2012/05/08