[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
> )
> 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?


\relative c' {
 e2\p\< d\> s1*0\!
} \addlyrics { Oh no }

\relative c' {
 e2\p\< d\> <>\!
} \addlyrics { Oh yes }

lilypond /tmp/
GNU LilyPond 2.15.38
Processing `/tmp/'
/tmp/ warning: no \version statement found, please add

\version "2.15.38"

for future compatibility
Interpreting music... 
/tmp/ warning: Two simultaneous lyric events, junking this one
} \addlyrics { Oh 
                  no }
/tmp/ 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 `'...
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

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

reply via email to

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