Menu
▾
▴
2 Attachments
#3279 space consecutive tempo marks
Originally created by: *anonymous
Originally created by: k-ohara5...@oco.net
Originally owned by: k-ohara5...@oco.net
In parts, especially percussion parts, the music can consist mainly of tempo changes above multi-measure rests. By default the tempo marks overlap (image left) but with overrides we can now get proper spacing (image right).
\layout { \context { \Score
\override Clef #'break-align-anchor-alignment = #RIGHT
\override MetronomeMark #'extra-spacing-width = #'(-0.5 . 0.5)
\override MetronomeMark #'Y-offset = #3.0
\override MetronomeMark #'outside-staff-padding = #0.8
\override MetronomeMark #'non-break-align-symbols =
#'(paper-column-interface)
\override RehearsalMark #'break-align-symbols =
#'(staff-bar key-signature clef)
\override RehearsalMark #'extra-spacing-width = #'(-0.5 . 0.5)
\override RehearsalMark #'Y-offset = #3.0
\override RehearsalMark #'outside-staff-padding = #0.8
} }
These overrides also address issue 1263, issue 1150, and issue 712
I propose we update the defaults
https://codereview.appspot.com/8189043/
The regression test changes mostly show tempo markings moving to the right at begin-of-line (issue 1150) and the appearance of 0.8-staff-space padding (which was requested by the old defaults but ineffective).
Originally posted by: pkx1...@gmail.com
I am not sure what I am testing here.
https://codereview.appspot.com/8189043/
or the .ly file
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-new Patch-needs_work
Originally posted by: k-ohara5...@oco.net
https://codereview.appspot.com/8189043/
Labels: -Patch-needs_work Patch-new
Originally posted by: pkx1...@gmail.com
http://codereview.appspot.com/8189043/
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make test and a full make doc. Reg test diff output here https://www.yousendit.com/download/UVJqYURCSU8yWGU5TE1UQw
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Owner: k-ohara5...@oco.net
Originally posted by: k-ohara5...@oco.net
The patch makes regression test "input/regression/metronome-marking-break-align.ly" fail based on its description of \tempo over multi-measure rests. Based on the discussion on issue 712, it seems we did not want that behavior over multi-measure rests to be the default, so I changed the regression test description, and extended to check that we can still get the special placement over multi-measure rests with an override.
New patch set creates and documents a \markLengthOff command analogous to \textLengthOff just in case someone liked having tempo marks overlap.
http://codereview.appspot.com/8189043/
Originally posted by: pkx1...@gmail.com
passes Make and make check but fails make doc.
-snip--
jlowe@jlowe26vm /tmp/show-3279$ more ./out/lybook-db/snippet-names-1358427097.log
GNU LilyPond 2.17.16
Forking into jobs: (1066 1065 1064 1063 1062 1061 1060)
logfile lilypond-multi-run-1.log (exit 1):
/tmp/build-lilypond-autobuild/out/lybook-db/74/lily-94dcf58a-systems.count...
Processing `/tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks...
Drawing systems...
Writing /tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31-1.signature
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31.eps'...
Converting to `/tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31.pdf'...
Converting to PNG...
Layout output to `/tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31-1.eps'...
Converting to `/tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31-1.pdf'...
Writing /tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31-systems.texi...
Writing /tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31-systems.tex...
Writing /tmp/build-lilypond-autobuild/out/lybook-db/3f/lily-cdf02b31-systems.count...
fatal error: failed files: "0f/lily-834814e2.ly"
fatal error: Children (1) exited with errors.
--snip--
seems to be on this
--snip--
% ****************************************************************
% Start cut-&-pastable-section
% ****************************************************************
\paper {
indent = 0\mm
line-width = 160\mm
% offset the left padding, also add 1mm as lilypond creates cropped
% images with a little space on the right
line-width = #(- line-width (* mm 3.000000) (* mm 1))
line-width = 160\mm - 2.0 * 10.16\mm
% offset the left padding, also add 1mm as lilypond creates cropped
% images with a little space on the right
line-width = #(- line-width (* mm 3.000000) (* mm 1))
}
\layout {
}
% ****************************************************************
% ly snippet:
% ****************************************************************
\sourcefileline 1344
\compressFullBarRests
\tempo "Molto vivace"
[r1]*12
\tempo "Meno mosso"
[r1]*16
% ****************************************************************
% end ly snippet
% ****************************************************************
--snip--
James
Labels: -Patch-new Patch-needs_work
Originally posted by: x.sche...@gmail.com
Nice, alignment of tempo indications is difficult to get satisfactory
results using default LilyPond output.
This is an improvement AFAICS.
But this does not solve issue 1150.
Compare the following code with current LilyPond version, with your
patch and the desired output obtained using Neil's workaround
(issue 1150 comment 8):
\relative c' {
\key f \minor
\repeat unfold 4 c1 \break
\mark \default
\repeat unfold 4 c \break
\mark \default
\repeat volta 2 {
\repeat unfold 4 c
}
}
Originally posted by: k-ohara5...@oco.net
Regarding issue 1150, if we move the start-of-line rehearsal marks as far as issue 1150 requests, they overlap with tempo marks, worsening a complaint ("especially ugly") from issue 712 comment 10. We can put the rehearsal mark as far right as the key-signature (image) and still have separation to the tempo mark. (Or, someone else can program a step to separate two marks placed on the same item.)
Thanks for the pointer on the docs problem, James; I had to `make doc` overnight. Docs fixed now.
http://codereview.appspot.com/8189043/
Summary:
Labels: -Patch-needs_work Patch-new
Originally posted by: k-ohara5...@oco.net
(No comment was entered for this change.)
Summary: space consecutive tempo marks
Originally posted by: lemzw...@googlemail.com
Two comments regarding the image of #1 (which probably don't get addressed in the patch, but anyway)
. I consider the `Molto adagio' positioned too far to the right, especially in the first line. I don't get the feeling that it is `attached' to the beginning of the bar, so to say. It seems that your (good) workaround needs a better implementation some day in the future.
. As shown in an especially ugly way by the `Meno mosso' in the third line, the right edge of a tempo mark *must* stay within the bar which precedes a new tempo mark. IMHO, it's not sufficient that the tempo marks don't overlap horizontally. Again, I think this needs programming support eventually.
Originally posted by: k-ohara5...@oco.net
I expected someone would complain about the "Molto adagio" being so far right, over where the first note /would/ go. Possibly it would be best to adjust the default with
\override Score.KeySignature #'break-align-anchor-alignment = #RIGHT
\override Score.MetronomeMark #'break-align-symbols =
#'(time-signature key-signature)
Originally posted by: k-ohara5...@oco.net
http://codereview.appspot.com/8189043/
Originally posted by: pkx1...@gmail.com
Patchy the autobot says: passes make, make test and a full make doc. Reg Test Diffs here https://www.yousendit.com/download/UVJqTGszT2JCSWZsZThUQw
Labels: -Patch-new Patch-review
Originally posted by: lemzw...@googlemail.com
The image in #19 is much better, thanks!
Originally posted by: pkx1...@gmail.com
Patch on countdown for April 8th - 19:00 GMT
Labels: -Patch-review Patch-countdown
Originally posted by: k-ohara5...@oco.net
I am pondering whether to push this on schedule, since it is an enhancement and a stable release is due.
The patch only changes defaults that users can override. It fixes issue 1263 and issue 1865. It brings issue 1150 and issue 712 in compliance with the literature (though not precisely as requested by the but-reporters).
I think I'll push it as two commits,
1) alignment of marks, the break-align stuff, and
2) spacing of marks, the extra-spacing-height stuff.
Originally posted by: x.sche...@gmail.com
I do not agree with the output of this solution.
%%%%%%%%
Regarding comment 13:
Placement of RehearsalMark at begin of line should not be a COMPROMISE
to accommodate possible collision with tempo indication.
Placement should be correct for RehearsalMark alone (i.e. where a
barline *would be*) and if there is a possible collision, it should be
handled by "collision avoidance", like for any other grob!
Your "compromise solution" still collide if you increase the font-size
of RehearsalMark, and thus is not a sustainable/reliable solution.
%%%%%%%%
Regarding image in #19, why is the last "Larghissimo" left-aligned on the
right-hand side of the KeySignature and not left-aligned on the first
note (g''4)? That's where I would expect it.
IIRC there was an agreement that tempo indications should be
1. left-aligned on left-hand side of TimeSignature
2. left-aligned on (left-hand side of) the first note
3. (if MMR), left-aligned on (left-hand side of) **where the first note
would be**.
tacet = \repeat unfold 16 [r1]
music = \repeat unfold 16 c'1
marks = {
s1*4 | \break
\tempo "Andante"
s1*4 | \break
\tempo "Allegro"
s1*4 | \break
s1*4
}
\score {
<<
\new Staff {
<<
\tacet
\marks
>>
}
\new Staff \with {
\consists "Metronome_mark_engraver"
} {
<<
\music
\marks
>>
}
>>
}
%%%%%%%%
The fact that "the right edge of a tempo mark *must* stay within the
bar which precedes a new tempo mark" is another issue IMHO.
Originally posted by: k-ohara5...@oco.net
> Placement should be correct for RehearsalMark alone (i.e. where a
> barline *would be*) and if there is a possible collision, it should be
> handled by "collision avoidance", like for any other grob!
Collision avoidance for objects that align above fixed objects (that use the break-align interface) is purely vertical. The placement rules pick the first object from the givne list that is present, which is generally useful, so placing the rehearsal mark objects where something else /would be/ is tricky.
> IIRC there was an agreement that tempo indications should be
> 1. left-aligned on left-hand side of TimeSignature
> 2. left-aligned on (left-hand side of) the first note
> 3. (if MMR), left-aligned on (left-hand side of) **where the first note would be**.
Possibly. That is the set of rules I originally proposed; see image in comment #1
If a partial solution based on the existing system is not acceptable, this will wait until version 2.20.
Originally posted by: x.sche...@gmail.com
> Collision avoidance for objects that align above fixed objects (that
> use the break-align interface) is purely vertical.
That might be a limitation we could/want to get rid of.
But it is not only for tempo/marks indications, the same applies to
TextScript, Script, Dynamics etc. and any other outside-staff object
(inside-staff maybe as well).
> The placement rules pick the first object from the givne list that
> is present, which is generally useful, so placing the rehearsal mark
> objects where something else /would be/ is tricky.
I don't agree. RehearsalMark should align on barline.
There is no barline position at line break (begin of line), but one
could see where the barline /would be/ based on repeat volta
(see comments 12 & 13). Issue 1150 states that LilyPond does not
correctly align RehearsalMark on this position.
I don't understand why "begin-of-line barline position" is correct when
LilyPond print a begin-of-repeat-volta barline, but not when there is
no special barline at begin-of-line.
> Possibly. That is the set of rules I originally proposed; see image
> in comment #1
It's hard to tell where the first note (NoteColumn) would be for
more-than-one-measure MMR.
And I agree with Werner that it seems too far to the right.
BUT tempo indications always left-aligned on KeySignature (when there
is a MMR or not) is not the solution IMHO (for both situations).
> If a partial solution based on the existing system is not acceptable,
> this will wait until version 2.20.
I'm sorry, I do not mean to disagree just "for the pleasure", but I do
not think it does a service to implement half flawed solution.
Originally posted by: k-ohara5...@oco.net
We agree. I meant 'tricky' in the sense of 'complex to achieve', not in the sense of 'deceitful'.
The documentation <http://lilypond.org/doc/v2.16/Documentation/notation/aligning-objects#using-the-break_002dalignable_002dinterface> claims that we can set the options to place an object where the staff-bar /would/ be, but the code does not actually let us do that.
Most of the complexity is from the additions made in response to issue 684. I think the best way to proceed repairing the resulting problems (issue 1263, issue 1276) is to re-solve issue 684 by relying more on the break-alignment-interface, rather than making special cases for span-bars and multi-measure rests.
Meanwhile, the benefit of this patch is available since version 2.14, by using the overrides in comment 1, as amended in comment 16, or amended however else you like.
Originally posted by: k-ohara5...@oco.net
(No comment was entered for this change.)
Labels: -Patch-waiting Patch-abandoned
Owner: ---
Status: Accepted
Originally posted by: k-ohara5...@oco.net
Let's try this again.
Re: comment 25 on the RehearsalMark, the compromise (between satisfying issue 1150 and reducing the incidence of needing to raise mark above a tempo) is no longer a compromise. The output agrees with the evidence of common practice shown in issue 1150. Users wanting different from common practice can override.
Collisions are resolved horizontally when possible (in the image, [Mark] Più mosso) and vertically ([D] Meno Mosso) if that is the only way to honor the alignment specified according to the documented break-alignment-interface (link to manual above).
Re: comment 25 on the "Larghissimo", the current patch goes back to textbook rules. Users wanting different can override as in comment #16. The location where the first note 'would be' is the location where a note appears when another staff is added (image).
Re: implementing a half-flawed solution. The half-flawed solution is already implemented; this patch merely changes the defaults so that we can use the half (more like 80%) that works. Sophisticated users are resorting to fractional spacer rests <https://lists.gnu.org/archive/html/lilypond-devel/2013-02/msg00075.html> to solve the same issue.
http://codereview.appspot.com/8189043/
Labels: -Type-Enhancement -Patch-abandoned Type-Ugly Patch-new
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Owner: k-ohara5...@oco.net