Re: Substitute for s1*0

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> Keith OHara wrote Tuesday, May 08, 2012 3:48 AM
>
>
>> Trevor Daniels <t.daniels <at> treda.co.uk> writes:
>>
>>> Yes, I now agree.  We can't continue to advocate s1*0
>>> in the docs now we are aware of these pitfalls.
>>
>> I suggest we mention that <> takes no time in NR 1.5.1 Chorded
>> Notes, but avoid it in the examples.
>>
>> Most of the visible uses of s1*0 in the docs were instigated by me,
>> so I see how to avoid them.
>
> This seems like a sensible way forward.  Let's take it a
> step at a time:
>
> 1. Raise a bug report to highlight the problems of s1*0,
> giving the <> workaround.  That seems standard procedure
> for the bug squad - a problem has been identified and a
> workaround suggested.  David - thanks for alerting us to this!

There is no bug with s1*0.  It has the completely expected and
consistent side effect of setting the current duration in the parser to
1*0.  This means that all following events with a default duration have
the same duration.  This includes, for example, a following Lyrics
context, and when you use s1*0 to place an event at the ultimate end of
a context, it is quite reasonable that a Lyrics context follows next.
People accustomed to using \addlyrics or \lyricsto will be surprised at
the information that it might be a good idea to give an explicit
duration to the first Lyrics syllable: isn't that what \lyricsto is for?

While \addlyrics rearranges the rhythm of the associated Lyrics context,
it does so in sequence.  Events happening at the same point of time are
simultaneous.  Since simultaneous music can be used for rearranging the
input (like adding marks to music), this is again functionality working
perfectly as intended.  Lyric elements take to the normal duration
algorithm, including using the default duration if none is specified
since it is perfectly feasible to specify lyrics timing manually instead
of using the resynchronization mechanisms.

Everything here works quite as intended, and there is no bug to fix.
Which is the reason s1*0 is an accident waiting to happen.  It takes a
programmer to understand its numerous implications.  The simple rule
"never forget an explicit duration for the next element or things will
blow up" is nice, but if s1*0 is used for the last element in a
sequence, it is not easy to do always.  Maybe append a
\void s4
afterwards?  This should get the parser back on track without causing an
event.

> 2. Document the semantics of <> in NR 1.5.1.  Does anyone
> dissent from this?  Ian has already provided a reasonable
> first draft.

It is not complete without including an explanation why that construct
is being avoided in the rest of the manual for the sake of more complex,
error-prone and cumbersome code.

And the onus of authoring this explanation lies on those who insist
keeping users from using the construct.

Even if I wanted to, there is no point in me writing up something which
does not make sense to me and which I consider an insult to the readers'
intelligence.  It would likely come across as not making sense and being
an insult to the reader.

> 3. Look at the individual uses of s1*0 and see first if its use can be
> avoided.  We can discuss each of these individually,
> considering the relative merits of using alternative approaches (if
> any) or using <>.

The goal being to avoid the impression that there is a working and
simple approach for letting postevents happen at some time without
requiring a note or rest, instead using parallel music and spacer rests,
or a number of other constructs more or less suited to different
situations, instead of a single, existing, simple tool.

Did I mention that using << and >> makes LilyPond look like C or C++ or
shell scripts?  Or Perl, but since Perl assigns meaning to almost any
character sequence, that's a bit of a cheap shot.

Let us just forget about this whole thing.  I am sorry I even mentioned
it.  Let us keep everyone stupid and happy, and that's it.  People are
used to LilyPond blowing up around their ears, so there is no point
investing energy on a minor point like this.

-- 
David Kastrup