Menu
▾
▴
2 Attachments
#1263 MetronomeMark can not be aligned on note if MMR in another voice
Originally created by: *anonymous
Originally created by: brownian.box@gmail.com
\version "2.13.33"
upper = \relative c'' {
% does not help:
\override Score.MetronomeMark #'break-align-symbols = #'()
c1
\tempo "Allegro"
c4 c c c
}
lower = {
[r1]*2
}
\score {
\new ChoirStaff <<
\new Staff <<
\new Voice {
\upper
}
>>
\new Staff <<
\new Voice {
\lower
}
>>
>>
}
Last working version is 2.13.31.
Originally posted by: brownian.box@gmail.com
Sorry, i probably should mention that if there is something another, not MMR, in another voice everything is fine.
Originally posted by: brownian.box@gmail.com
As a workaround, "Metronome_mark_engraver" may be moved from Score to Staff (don't know if this has any pitfalls).
Well... Of course i would like this to be "corrected" before 2.14 if it's easy enough to be real.
At least this should be documented. So, let it be "critical" for now.
Originally posted by: n.putt...@gmail.com
> As a workaround, "Metronome_mark_engraver" may be moved from Score to Staff (don't know if this has any pitfalls).
You'll get tempo marks on all staves, unless you bypass the \tempo command and set the context properties directly.
This should work:
\once \override Score.MetronomeMark #'non-break-align-symbols = #'()
Originally posted by: Carl.D.S...@gmail.com
I think this should not be a critical regression.
Critical regressions are things that used to *deliberately* work. We used to have no special alignment for multi-measure rests, as I understand it. Now that we have instituted proper alignment for multi-measure rests (see issue 684), when we have multi-measure rests in parallel with notes, it picks the multi-measure rest. This particular set of code never *deliberately* worked before (i.e., there was not a decision to choose the note-column instead of the bar); there was no option to use the bar (which is the desired performance for multi-measure rests).
The workaround is simple, using a \once \override.
I'd be fine with a High priority, but I think it's a mistake to label it Critical.
Originally posted by: percival.music.ca@gmail.com
Good reasoning, Carl. If it didn't work deliberately before, there's no reason to make this particular one High priority, either.
I'll have to change my .34 release announcement, but oh well. :)
Labels: -Priority-Critical -Regression Priority-Medium
Originally posted by: brownian.box@gmail.com
I'm quite fine with Medium, of course.
From user's perspective: if something (aligning MM over notehead) became impossible... .)
Neil, thank you for your workaround :-)
Yes, i knew that nothing is impossible with lilypond! I waited for some feedback actually (Carl, thank you).
I've just reported another one, issue 1269 and marked it as critical. Hope it'll be easy to fix.
I'm sorry, i'm far away from stable internet access these days.
Originally posted by: mts...@gmail.com
Issue 3042 has been merged into this issue.
Originally posted by: mts...@gmail.com
Better alignment of MetronomeMark to MultiMeasureRest
http://codereview.appspot.com/6972044
Labels: Patch-new
Originally posted by: dak@gnu.org
Patchy the autobot says: In key-clefs.ly, the tempo marks slide to the right of the key change and look out of place. In text-spanner-full-rest.ly, "tempo" mark slides to the right of clef, arguably a slight improvement. At any rate, it is not clear from the patch description that either effect is intentional, and the first mentioned one looks like a step back. Both situations should be checked back with literature.
Labels: -Patch-new Patch-needs_work
Originally posted by: k-ohara5...@oco.net
> In key-clefs.ly, the tempo marks slide to the right of the key change
Those tempo marks are not the point of that regression test, merely labels to describe how the key signature should look. They happen to be tempo changes with /only/ a multi-measure rest in the measure---no notes in any lower staves.
Where should the tempo go in that case? The books I have (Ross, Stone) do not specify.
In the patch for issue 684, Neil gave his thoughts
https://codereview.appspot.com/1579041#msg3
> -) A metronome mark at a full-bar rest should be aligned with the barline
> instead of the paper column to the left of the rest.
> -) If there's a tempo change at a key signature, the metronome mark
> shouldn't be aligned with the following note.
(Both differ with what I am used to seeing.)
If we want the tempo marks over the first note if there is one, but over the bar-line if there is /only/ a full-measure rest,
\override Score.MetronomeMark #'non-break-align-symbols = #'(
note-column-interface multi-measure-rest-interface)
Originally posted by: k-ohara5...@oco.net
I looked a bit at Breitkopf's edition of "Tristan und Isolde" (thinking that Wagner loves key changes, and that it is long enough for lots of examples). Placement of tempo changes at key change is not perfectly consistent.
In single-staff music (the parts) about 75% of the time this engraver places tempo marks the same way LilyPond does currently (including the first point I quoted, and doubted, from Neil). A sample from the flute part is attached (but the engraver slid "poco-più-animato" halfway over the key signature in the viola part).
In multi-staff music (the score) there are generally some staves with full-bar rests and some with notes. The tempo mark starts over time-signature, if there is one, otherwise over the first note, even if there are full-bar rests in the upper staves. (I saw just one exception, where the tempo overlapped a key change.)
Probably it would be wise to change the logic (as the override above does):
(if there is /any/ full-measure rest) -> (if there are /only/ full-measure rests)
then start the tempo mark over the bar-line
Originally posted by: x.sche...@gmail.com
I am also in favor of aligning the tempo indication on the
"equivalent" of the first note X-position, even if the upper Staff has
a MMR (and even if there is only one Staff if possible).
By doing this, this would solve also issue 712 (IIUC comment 5 by
Werner).
Originally posted by: k-ohara5...@oco.net
Let's go back to Mike's patch.
Cc: mts...@gmail.com
Originally posted by: k-ohara5...@oco.net
fixed with commit [r80c029b079858c3278f30f6ff268ba350bf74e48]
by making the override in comment 3 the default.
Labels: -Patch-needs_work Fixed_2_17_17
Status: Fixed
Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified