Menu
▾
▴
#2522 duration*0 considered harmful
Originally created by: *anonymous
Originally created by: k-ohara5...@oco.net
Originally owned by: k-ohara5...@oco.net
The documentation sometimes uses zero-time spacer rests s1*0 as an attachment point for markup or articulations, when there is no note available for the attachment.
Setting the current duration to 1*0, however, can cause surprise if a user fails to reset the duration.
{ b'1\> s1*0\! }
\addlyrics { la. } % Should be "la.1"
In this case, no lyric is printed. The behavior with current duration set to zero is unfamiliar, so it might confuse people. Maybe it is wiser to avoid durations of zero in examples in the documentation.
Workarounds
0) use explicit durations as required
1) use empty chord <>, which has zero duration but does not change the current duration, in place of s1*0.
2) use alternate solutions instead of zero durations
\new Staff { << { b'1 } { s2\> s4 s8 s\! } >> }
\addlyrics { la. }
Originally posted by: k-ohara5...@oco.net
Workarounds
3) use \times 0/1 s
Originally posted by: dak@gnu.org
Given the controversial nature of the discussion on the developer list, I consider it reasonable to postpone any changes to existing uses of s1*0 until Graham is back from his vacation at least. There is also no point in prolonging the rather unproductive discussion based on the current level of information.
There has been harsh criticism of the mailing list discussion on option 1 as being based on its technical merits without taking into account opinions and interests of non-programmers with the implied accusation of using technobabble in order to confine participation in the decision finding process to an inner circle.
In order to alleviate that impression, I will try to come up in the next days with an explanation of empty chords as a patch to the documentation where chords are introduced. This should provide a basis for decision making and discussion written at a level accessible to people starting out with LilyPond rather than seasoned programmers.
s1*0 appeared first in LilyPond sources in 2003, and so far, there has not exactly been a stream of problem reports surrounding its use. So there is no urgency for reaching consensus on the best way to deal with this issue. I apologize for the significant part I so far had in making the discussion seem disruptive and disrespectful and would ask everyone, for the benefit of the project, to postpone further action to the time when everybody is back and had leasure to consider the writeup aimed at introductory level. Of course, there is nothing wrong with suggesting improvements to the text as such once it is written, but let us please postpone any decisions on consequences on s1*0 usage until a time where everybody can be considered reasonably calm, relaxed, informed, and available.
Thanks for caring. It is good to see that people can still feel passionate about LilyPond.
Originally posted by: k-ohara5...@oco.net
Going slow is good for this.
I wrote first suggestions for doc examples that avoid zero-length spacer-rests (an oxymoronic name for a sometimes-useful thing, but which Xavier once called 'tricky'). Main docs only, not yet snippets.
I'll link to it here but say needs_work because it will certainly change.
<http://codereview.appspot.com/6197068/>
I did include a description of empty chords for the section on chords. I understand your motivation to provide that doc patch. You can comment on, or adopt some or all of the patch. Your choice.
Labels: Patch-needs_work
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Owner: k-ohara5...@oco.net
Status: Started
Originally posted by: dak@gnu.org
Ok, in the \footnote issue 2505 there is an example with a breath mark. That looks something like
\breath c4\footnote #'BreathMark ...
for getting a footnote to the breathmark. Ugh. This could be done with
\breath <>\footnote #'BreathMark ...
but it would also be feasible to make a function taking _one_ postevent like
post = #(define-music-function (parser location ev) (post-event?) #{ <>$ev #})
and say \breath \post\footnote #'...
In contrast to <>, it would only accept a single postevent. And I can't think of a really good macro name. \now\footnote does not convey the problem that there is only one postevent acceptable.
Originally posted by: dak@gnu.org
As a point of reference for syntactically valid symbol combinations with semi-graphical character:
<URL:https://github.com/mirrors/perl/blob/book/perlsecret/pod/perlsecret.pod>
While "better than awful" should not really be governing our decisions, it is still nice to be able to see what others have to contend with.
I still need to pick up my promise writing about chords. Doing that now.
Originally posted by: dak@gnu.org
Document <> and improve other simultanous music documentation.
This is a side issue of 2522: it improves the documentation dealing
with various ways of entering parallel music and gives the necessary
information to understand <> as a special case of chords.
http://codereview.appspot.com/6248080
Labels: -Patch-needs_work Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Document <> and improve other simultanous music documentation.
This is a side issue of 2522: it improves the documentation dealing
with various ways of entering parallel music and gives the necessary
information to understand <> as a special case of chords.
http://codereview.appspot.com/6248080
Labels: -Patch-review Patch-new
Originally posted by: ColinPKC...@gmail.com
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Document <> and improve other simultanous music documentation.
This is a side issue of 2522: it improves the documentation dealing
with various ways of entering parallel music and gives the necessary
information to understand <> as a special case of chords.
http://codereview.appspot.com/6248080
Labels: -Patch-review Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: dak@gnu.org
Putting aside the discussions about the "side issue" and corresponding patch: I find it acutely embarrassing that we have _no_ documentation whatsoever regarding what s1*0 does and why one would use it. The only _somewhat_ relevant information is in the wrong manual, namely EG, and if you look at <URL:http://lilypond.org/doc/v2.15/Documentation/extending/adding-articulation-to-notes-_0028example_0029> it turns out that
We could avoid this problem by attaching the articulation to a fake note,
{ << \music s1*0-.-> }
but for the sake of this example, we will learn how to do this in Scheme.
contains more errors than information. It is not clear whether or not this is supposed to use simultaneous music since we have << without corresponding >>, and the note in question is not a "fake note" but a spacer rest, and, if you were to use s1*0 at all here, you would do this without simultaneous music, as { s1*0-.-> \music } and hope that the next note is entered with explicit duration.
So it is rather obvious that the idiom s1*0 has not as much established because it would be documented anywhere, but rather because of being visible.
If you take a look at <URL:http://lilypond.org/doc/v2.15/Documentation/notation/writing-rhythms#scaling-durations>, you'll find that the possibility of scaling by 0 is not even mentioned. Neither is this mentioned in <URL:http://lilypond.org/doc/v2.15/Documentation/notation/writing-rests#invisible-rests>. While the chapter mentions that spacer rests will, as opposed to \skip, create a Staff implicitly, it does not even mention that spacer rests can also take articulations/post-events. And <URL:http://lilypond.org/doc/v2.15/Documentation/notation/expressive-marks-attached-to-notes#articulations-and-ornamentations> mentions the possibility of adding articulations to rests but does not explicitly mention spacer rests.
So while the currently downcounting patch is supposed to bring the documentation regarding <> and <<...>> to a less shameful state to make it feasible thinking about the degree to which mentioning/using <> might be a good idea, the fact is that the current documentation available for deducing the function/mechanism of s1*0 is totally abysmal. If it disappeared from code and examples, it is probably less likely that someone would spontaneously think of s1*0 rather than of <>.
Originally posted by: dak@gnu.org
Anecdotal evidence regarding the potential of the "considered harmful" issue:
<http://permalink.gmane.org/gmane.comp.gnu.lilypond.general/72701>
Quote:
That was it. After working on the score full-time for three days I
couldn't see that {s1*3 s\p} is very different from {s1*3 s1\p}
despite checking and correcting the dynamics block several
times. After working in my garden for a few hours I spotted my error
almost immediately.
Not every LilyPond user has a garden readily available. Or a few hours.
Originally posted by: ColinPKC...@gmail.com
Counted down to 20120605, please push
Labels: -Patch-countdown Patch-push
Originally posted by: dak@gnu.org
Pushed as [re765ccfb78a8fd117c55773b4cfb8606484bcab9] to staging. This was just a side documentation issue documenting aspects of parallel music and chords.
The basic issue remains open. As pointed out in comment 14, the documentation state for s1*0 is actually even more pitiful and would warrant improvement if the user is supposed to be able to make an educated choice. And it will not suffice to put a "<> will do this, s1*0 will do that" somewhere if that's the only place where we talk about <> and s1*0: in that case the user can't actually make his own reasoning but just pick a champion based on that particular passage.
That's just "teaching the controversy" <URL:http://www.smbc-comics.com/index.php?db=comics&id=2627#comic>, so we should get useful information surrounding the concepts of s1*0 also into place.
And then we still need to decide what to pick when we need a non-time-advancing post-event holder in our independent code examples.
Labels: -Patch-push
Originally posted by: k-ohara5...@oco.net
Doc: avoid using zero-duration spacers in examples
<http://codereview.appspot.com/6197068/>
Labels: Patch-new
Originally posted by: ColinPKC...@gmail.com
Patchy the autobot says: LGTM.
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: ColinPKC...@gmail.com
Set to needs-work, as the line breaks Graham was requesting don't seem to have been inserted: I don't see a delta from patchset 1.
Labels: -Patch-countdown Patch-needs_work
Originally posted by: gra...@percival-music.ca
I'm overriding this because Keith sometimes don't re-upload a patch which only has trivial changes (and I fully support this behaviour). If it was somebody we don't know then it would be useful to have the extra check of requiring that we saw the updated patch, but Keith is awesome so that's not necessary here.
Please push to staging.
Labels: -Patch-needs_work Patch-push
Originally posted by: k-ohara5...@oco.net
commit [r4ab6e4df934e57c51dbbdbf2c209273c6cb5b888]
Labels: -Patch-push fixed_2_15_41
Status: Fixed
Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified
Originally posted by: dak@gnu.org
See also followup issue 2695 for an unnoticed problem with this patch.