Re: Substitute for s1*0

[David Kastrup]

"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