#4633 MMR wrong glyph

[Palmer Ralph]

Simon Albrecht wrote :

in the following snippet the MMR should be displayed with the "rests.M1" glyph (vertical bar between two staff lines). But with Timing_translator moved to staff level, this works only if the staff is not explicitly instantiated (uncomment \new Staff to test), else the whole rest glyphs are used.

\version "2.19.27"

voiceOne = \relative {
  \time 4/2
  R\breve
}

\score {
  % comment to trigger bug
  \new Staff
  \voiceOne
}

\layout {
  \context {
    \Score
    \remove "Timing_translator"
  }
  \context {
    \Staff
    \consists "Timing_translator"
  }
}

[David Kastrup]

I lean towards closing this as invalid. The actual problem is that without instantiating \Staff, there is no Timing_translator establishing a "Timing" alias for Staff. So \time 4/2 changes the timing parameters of Score before a Staff is established, but those parameters don't carry any meaning.

Consequently, the timing for the Staff-level Timing_translator remains unchanged, meaning that a measure has 4/4 of length in the Staff. So a rest with a \breve length takes up two measures, and that's what the chosen multi-measure rest glyph reflects.

When telling LilyPond that Timing should occur at Staff level, it does not make sense to call \time (or other Timing-related commands like \partial) without having created a Staff first.

[Simon Albrecht]

IIUC, you mean that \time (by default) pertains to the entire score and thus doesn’t trigger the creation of a staff, which is logical. I think you mistook my comment in the code example, which wasn’t clear enough: The problem shows only if the staff is not explicitly created.
Normally, explicitly instantiating a staff is the more robust way than leaving it implicitly. It’s odd that in this case having the staff created implicitly works, and creating it explicitly causes a problem.

Unfortunately, I don’t know a way of working around this: I need staff-wise timing, and I need to create Staff contexts explicitly (in order to use a \with {} block and have the Volta_engraver in the topmost staff only; but it would be absurd to require implicit staff creation anyway). And I need correct R\breve output.

[David Kastrup]

No, \time by default pertains to the current Timing context. When every Staff is its own Timing context (which is the whole point of moving the Timing_translator), \time outside of any Staff does not make sense.

At any rate, you need to decide whether you complain about the behavior with explicit Staff creation (which looks ok to me) or implicit Staff creation (which doesn't). In this case, the behavior will likely go more towards what you want if you move the Default_barline_engraver as well...

[Simon Albrecht]

Sorry, but I don’t quite get your point here.
If I write \new Staff \voiceOne, then the \time command is inside a Staff context, explicitly created. But just then the wrong glyph is chosen.

[Trevor Daniels]

I am marking this Invalid, as it appears to me to be a user error or maybe misunderstanding. If the R\breve is replaced with r\breve the correct breve glyph (which is the one expected by the user) is produced. But when R\breve is coded the correct glyph for any single full-bar rest whatever the time signature, namely a whole rest, is produced.

If the staff is not explicitly instantiated the default time of 4/4 is in force (as the \time command is ignored outside a staff after the Timing_translator has been moved), and hence R\breve covers two bars and the breve glyph appears, correctly, to indicate a 2-bar multi-measure rest in 4/4 time.

Trevor

[Simon Albrecht]

r\breve produces the right glyph, but a Rest (flush-left in the measure) instead of a MultiMeasureRest (centered in the measure), so this is not an appropriate solution.
And contrary to your statement the glyph chosen for a MMR is not independent of the time signature:

:::TeX
%%% long-mmrs.ly
\version "2.19.28"
\paper { #(set-paper-size "a7landscape") indent = 0 }
\header { tagline = ##f }
{
  \time 5/4
  R1*5/4
  \time 6/4
  R1.
  \time 7/4
  R1*7/4
  \time 4/2
  R\breve
  \time 9/4
  R\breve*9/8
  \time 12/4
  R\breve.
  \time 8/2
  R\longa
  R1*4
  \time 6/1
  R\longa.
  R1*6
}

[Simon Albrecht]

Sorry for the mess in the notifications.

[Trevor Daniels]

Elaine Gould is not entirely clear on this point. On page 160 she says:
"The semibreve rest acts as a whole-bar rest in any time signature. For all time signatures of 4/2 or 8/4 and over, the breve rest represents a whole-bar rest." which seems slightly contradictory. But the example she shows clearly agrees with the LP output shown in the previous comment, in as far as they overlap.

So I've been converted; this is a bug: LP produces output which is at best inconsistent and at worst wrong when the Timing_engraver and Default_bar_line_engraver are moved to the Staff context for a 4/2 time signature, in that a whole bar rest is then shown as a semibreve rather than as a breve, whereas it is correctly shown as a breve if those engravers are not moved.

[Simon Albrecht]

Thomas Morley came up with a workaround by overriding MultiMeasureRest.usable-duration-logs:

:::TeX
\version "2.19.28"

voiceI = \relative {
  \time 4/2
  \override MultiMeasureRest.usable-duration-logs = #'(-1)
  R\breve
  r\breve
}

\score {
  \new Staff \voiceI
}

\layout {
  \context {
    \Score
    \remove "Timing_translator"
  }
  \context {
    \Staff
    \consists "Timing_translator"
  }
}

If necessary, \once\override or a \revert may be used.

[Trevor Daniels]

It seems this fault was introduced early in the 2.15 development cycle. The correct glyph is used in 2.14.2 but the incorrect one is used in 2.15.8. I don't have the intermediate versions to hand to narrow it down further ATM.

[Trevor Daniels]

... and there are no 2.15 mingw binaries available on the website earlier than 2.15.30, so I can't narrow it down any further by simply testing existing binaries.

[Trevor Daniels]

This commitish, 104f80daf1dab11ef5b598006e3d4be8dfbe1926, the result of Issue 1655 and https://codereview.appspot.com/4536068 introduced a major change to multi-measure rest processing, adding the usable-duration-logs property. It first appeared in 2.15.2, so seems a likely culprit.

[Malte Meyn]

I would like to try to fix this if I understood what was going on here. I’ll try to sum up what I’ve understood so far:

A MMR grob reads the grob property measure-length instead of the context property measureLength (as it was done before the commit trevor refers to). The property measure-length is set depending on measureLength in Paper_column_engraver::process_music().

This works fine when the Timing_translator is moved to the Staff contexts and Staff contexts aren’t explicitely created by the user. It doesn’t work if a Staff context is explicitely created (even when the Timing_translator isn’t only moved in a \layout block but also in a \with block for that same Staff).

Looking at some debug output I added, I saw that measure-length is always 1 if the Timing_translator is moved, so probably Paper_column_engraver::process_music() is called too late? (it’s not called less times)

Edit: When process_music is called, the context property measureLength isn’t set (l. 864 in context.cc isn’t reached). So „too late“ isn’t correct, it should be „too early“.