[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Incomplete processing of line breaks.

From: Amreg
Subject: Incomplete processing of line breaks.
Date: Sun, 22 Sep 2013 17:17:26 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8


(Sorry, this mail is long because I try to explain as clearly as possible an issue that shows up in several ways, but still keeping the examples minimal - the length of the mail is simply related to the explanations. This volume is because solving this issue could bring noticeable changes to LilyPond syntax, that's why I try to express the issue clearly).

LilyPond versions involved: all (at least up to 2.16.2, not tested above).

Description of the issue:
LilyPond considers a bar as having the same shape and properties with respect to both of its sides (e.g. with respect to both surrounding measures). Unfortunately, this is not always true, but LilyPond does not provide a real way to address such a situation.

The problem shows up especially when a line break occurs precisely at that bar, but exists anyway even without a line break.

It seems that LilyPond considers breaks (either manual or automatic) only for the sake of closing the current score line and starting a new line, but does not take into account all the consequences of such a break. I give below two examples to illustrate this incomplete (and thus incorrect) processing, but there are also other situations where this issues shows.

1) Consider the (very common) situation of a contemporary song, starting with some intro measures followed by the first verse (and as such, this verse is included in a global repeat that encompasses both the verses and the chorus, but does *not* encompass the intro). Usually, the end of the intro is marked with a double-bar (this is logical, because the intro and the verse are different "sections" of the piece, and that's precisely just *why* double-bars exist). And, except for very short intros, the intro takes the first line of the score, and the verse starts the second line.

Logically, such a situation should be coded as follows:
  % Intro (some measures)
  c1 c c c | \bar "||" % double-bar to mark intro end
  \break % to enforce a break between intro and verse
  % Song beginning (verse, ...), starting with a repeat
  \repeat volta 2 { e e e e }
(Note: I used a manual break above to keep this example minimal, but the same happens with an automatic break when the intro measures are populated enough to spread over the whole score line.)

Unfortunately, the double-bar closing the measure 4 hides the repeat bar opening the measure 5, *despite they are on separate score lines* (if the closing bar of measure 4 is a "normal single bar", the repeat bar at start of measure 5 shows correctly). So a reader of the score would be fooled to believe that the repeat restarts with the intro (measure 1) instead of with the measure 5 (the real repeat start point).

In other words, the break dissociates the "left" and "right" side of the 4th "logical" bar, but LilyPond implicitly (and incorrectly) assumes that bar is *always and in any case* the same "from both sides".

Obviously a workaround is to *manually* force a repeat bar at the beginning of measure 5 (with a '\bar "|:"' instruction), but this is a workaround and not the logical solution: the problem is the combination of: - the implicit assumption that any bar plays "always the same role" from both of its "sides"; - the insufficient processing of the break, that simply starts a new line but does not take into account that it also "dissociates" both "sides" of the bar. If repeat bars should be added manually anywhere there're needed, then there is no longer need to have a "\repeat volta" instruction in the LilyPond syntax, and all repeats should be processed manually...

Additionally, the situation is similar (and maybe even worse) when there is no line break. Just suppressing the manual break in the snippet above will emphasize that the "double-bar" takes precedence over the repeat bar (which is not a correct precedence order, a repeat bar has a "stronger" consequence on the music flow than a double-bar). Obviously you could think that defining the two sides of the bar when there is no line break is useless, but just think that changing later the layout of the intro measures (e.g. adding spacing for clarity purposes) could result in triggering an automatic break at that point (and you're back to the first case above, with the manual break).

2) Indications referring to rehearsal marks

By "indications referring to rehearsal marks", I mean indications such as "To Coda", or "D.S. to Coda"; in other words, I'm not referring to the rehearsal mark (such as segno or coda) by itself, but on the indications that defer to it.

Usually, those indications occur at the end of a measure, and are right-aligned with that end (they logically belong to the measure preceding the bar, in other words to the "left side" of the bar that ends the measure), whereas the "real" rehearsal marks, from which the music flow resumes, mark the beginning of their measure and, as such, logically belong to the "right side" of their corresponding bar.

The default behavior of a rehearsal mark is to be aligned with the opening bar of the measure, which is perfectly normal for a rehearsal start point. Unfortunately, using the same syntax ("\mark \markup") for the indications deferring to it enforces the same "reference point", which is not appropriate for them: they are thus anchored to the measure *following the bar*, and not to the measure *preceding* it. Yes, I know that I can manually override the alignment of such an indication (right-aligning it for instance instead of the default alignment), but this does not change the "reference point": the indication is still attached to the following measure, not the previous one.

This incorrect anchoring is emphasized when a line break occurs at that bar: the indication (even right-aligned) is moved along to the beginning of the new line (where it has nothing to do), instead of being stuck with the end of the previous one.

Yes, I know that I can sometimes tweak the "anchoring point" of that indication, overriding its break-visibility property, but this *does not always work*, contrary to what the manual ans snippets suggest.

Consider for instance again the common situation of a song: usually, there is a coda. The repeat used for verses/chorus does not always takes the form of a "\repeat volta", because that form is not always appropriate (especially when there is a "bridge"), and the repeated section is then indicated with segno signs.

The structure of such a song is usually as follows:
A- a first section (optionally comprising somewhere a "segno" sign),
B- a "To Coda" indication at the end of that first section,
C- a second section, ending with a "D.C. to Coda" (or "D.S. to Coda" if there is a segno),
D- the coda itself, that lays just below the end of the second section.

Consider how the limit between C and D above should appear in LilyPond:

 % ... second section ...
 c4 c c c |  % ending measure of 2nd section
 \mark \markup { "To Coda" \musicglyph { #"scripts.coda" } }
 % end of second section
 \break  % to separate 2nd section and Coda
 % start of Coda
 \mark \markup { "Coda" \musicglyph { #"scripts.coda" } }
 % ... coda continues here ...

Again, as LilyPond does not makes the difference between both sides of the bar, it considers that both marks are related to the same bar, so there is one in excess, they conflict to one another, and it rejects the second. Such a discard can sometimes make sense when there is no line break (the collision can nevertheless be avoided with correct manual alignment of each mark), but *definitely makes no sense at all* when an intermediate break put them wide apart on the score, avoiding any collision risk.

Concerning this second example, I admit it is a kind of a "twilight zone". It is related to the fact that LilyPond apparently refuses to separate the "left" and "right" side of a bar (that's why I mentioned it here), but it can also be considered as related to using the same syntax for things that are of a different nature: using software terminology, a "To Coda" indication is similar to a "Jump To" *instruction*, whereas a real rehearsal mark is similar to the *label* which is the target of the jump. A label and an instruction are completely different things for a compiler (and LilyPond can be viewed as a compiler, processing "source text" to produce outputs).

Think of this difference if you were to enhance LilyPond to provide an MIDI output for such a song (this is a missing feature at the moment of LilyPond, which only address the "\repeat volta" and "\repeat unfold" forms of the repeats, but not the "segno-to-segno-to-coda" form). I'm not sure this common syntax would help implementing such a feature, which is


reply via email to

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