"Trevor Daniels" <t.dani...@treda.co.uk> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
