Bars with text shouldn't be part of multi bar rests

As you can see if you follow the steps, rehearsal marks do cut the multi bar rests. Chord names and system/staff texts don't.
It would probably good to do it for chordnames as well but I'm not sure for system/staff text. If someone wants to break the rest, he can use the Measure Properties -> Break multimeasure rests.

My initial gut feeling is, anything I actually enter into a bar notes, explicit rests, text, fermatas, etc - should probably break a rest by default. But items that only happen to be attached to measures because they are applied to all staves in a system should not necessarily break rests, unless indicate "significant" events. Rehearsal marks and tempo texts strike me as significant; other system text not. Hmm, I guess repeat texts and voltas too. Really, everything *except* ordinary system text. And even then, I'm not so sure I wouldn't at least some times want system text to break rests.

However, the flip side of such an approach would be making sure there was a way to override, if for some reason you *did* want the measure included in a mutlimeasure rest despite containing some sort of marking. I guess that's the advantage of the current approach, where you have to manually ask that the rest be broken.

Definitely would like an override. I have entered a load of invisible tempo markings in order that my midi representation of the work would show a correct changes of tempo, as the system cannot respond to the written markings such as accelerando. Sadly, these invisible markings have led to the mult-bar rests being broken in every part, and since they were invisible it's a right job to take them all out again, and of course then the midi will not play properly, so I need two versions, one from which to play the midi and one from which to create the parts. An override would be marvellous.

For what it is worth, Finale only breaks multimeasure rests for "significant text" such as rehearsal marks or tempo text.

chen lung, can you give an example of when you do what regular system text or staff text to break a multi-measure rest?

If I'm not wrong #6 and the first post are contradictory and we should close this bug right?

There is a double bar here between the two measures. So if you enter this and create mutli measure rests, nothing will happen.

chen lung, the example in #10 actually isn't a rest (it is some kind of swish to indicate that the instrument is playing. In the notation I'm more familiar with it would be a slashes ). For the odd exceptions MuseScore has a checkmark option in Measure Properties that allows you to "break [a] multimeasure rest" for a particular measure.

One reason would be as a cue.

(I am resurrecting this because this will probably need to be revisited in fixing #23028: Rehearsal marks not displayed in parts with multimeasure rests, which is definitely a bug and a regression against 1.3.

My take remains as expressed ion #3: anything a user explicitly enters into a measure on a given staff makes that measure non-empty for that staff. Meaning even though it may not contain notes, it should not be considered part of a multimeasure rest at all. It should display as a normal measure with a normal full measure rest regardless of whether it is preceeded or followed by truly empty measures.

Explicitly setting the "break multimeasure rest" flag isn't the same thing, because while of course it breaks the rest, it immediately starts a new one. The measure containing the text won't be displayed as an ordinary non-empty measure. The workaround for this currently is to enter an invisible non-playing note into the measure.

A possible alternate solution would be to add a new measure property to force the measure to not just break a multi-measure rest but to be considered non-empty. Then you could set that property manually independent of whether you've entered text.

Hello,

For me i think

text on rest measure is
- displayed if "break multi bar" rest is selected and then start a new multibar rest if needed. If i want display this measure, i put a "break multi bar" in next measure.
- text do not break multimeasure rest and in this case it is not displayed too

For now, no text and no mark is displayed even if "break multi bar" rest is selected. I lost information in score. For now the score cannot be used.

I hope you understand what i mean.

Robert

Should be fixed aa616648b8

Hello,

I think's that this issue don't be solved as this.

Text must break multibar rest, but the bar containing text must be in a new multibar rest if needed.

Look at images.
.
Actual :

Expected:

If i want to have actual type of break (view the measure containing text). it possible to add a explicit break multibar rest on next measure. But not by default view that measure with rest.

I hope my post is clear.

MuseScore 1.3 work fine with that.

Robert

I would agree in this particular example, this seems the expected behavior. But other cases would come up where the implemented behavior is the preferred one. I think the distinction as I describe it above would cover this perfectly. If the text is actually system text (including tempo text & rehearsal marks) and thus attached to all staves, it should break the mm rest but still be part of the new one. But if the text is explicitly added to this staff and this staff alone, then it should not be part of any mm rest at all. Your example is one that would pretty clearly be a tempo text, which is system text. And indeed, you'd expect it to display as you have shown. So if the algorithm differentiated staff from system text in this manner, I think that would cover it nicely.

No doubt, there could possibly be exceptions here - cases where something makes sense to add as system text that should nonetheless not be made part of any mm rest, or cases where something makes sense to add as staff text that should nonetheless be incorporated into a mm rest. So a way to explicitly override these defaults would be nice. But I think these defaults should cover the majority of use cases very nicely.

if i understand what you say (i'm not shure, my english is very poor). it seem to me more complicated to consider multiple default beahavior : "if one staff, if it's a staff text that override, etc..." This can be already done, at measure level (better than staff or part) with "break multi bar rest" in bar propertie (Musescore 1.3 work fine for that).

Example:

Here you have text who break mmRest. It's normal behaviour in 2.0

If you want to view Measure # Add a "break multi bar rest" in mesure 6

An other way to explore is to have an option in the preference that inhibits break on text or mark and leave user make manual choice on where break mmRest (default mode in MuseScore 13).

Here there is a text in Measure 5 but not visible because text and mark don't break mmRest

Here i have checked "break multi bar rest" in measure #5

In all cases, a text it's visible only if it be part of the first measure of the mmRest.

Robert

You are correct that if all text - staff and system - were to break a mm rest, then you could get the desired behavior for staff text using the workaround of also setting the *next* measure to break mm rests. But that seems like an unnecessary extra step. I'd guess 90% of the time that people go to the trouble of attaching staff text to a specific measure on a specific staff, they intend for that measure to display normally.

So I'm suggesting that making staff text work differently than system will make it easier for the user - they won't have to think of the non-obvious solution of changing the properties in the *next* measure (my guess is most people will never think of that). But it is true that this introduces the need for an extra option of some kind to override this behavior. So you may be right that it isn't worth it.

Still, I think it worth thinking about whether there is a better way.

In any case, you are definitely correct that the current behavior for system text (including rehearsal marks and tempo) is incorrect - it has to go back to how it was in 1.X, where it breaks
a mm rest but is still included in the rest.

A build from the latest sources seems to show things *almost* working as I expected. Rehearsal marks and tempo text break rests but are now included within the new rests - good. Staff text and chordnames break the rest *and* exclude the measure from the rest - this is what the initial report implied was the desired behavior and what I have been agreeing is probably the expected behavior most of the time.

HOWEVER, right now there is no distinction between staff and system text in this regard, and I think there needs to be. That is, it's OK that staff text excludes a measure from multimeasure rests completely, but system text should merely break the rest, not exclude the measure. In other words, system text should behave just like rehearsal marks and tempo text. This much I think all might agree on?

Furthermore, though, I do think Robert is making a good case that maybe staff text should *not* automatically exclude measures from multimeasure rests. Right now, there is no way to defeat that exclusion, but if staff text merely broke the rest, it *would* be possible to force it to be excluded (by setting the break property on the next measure, or by adding an invisible/silent note - or I might suggest an explicit "exclude from multimeasure rests" attribute could be added in measure properties.

I still think excluding is probably the desired behavior most of the time, and it's probably not a common enough case to worry about whether it can be overridden. But the same issue comes up for other items besides staff text that might be attached to otherwise empty measures. For instance, what about attaching a fermata to a full measure rest? What about a grand pause?

Also, I notice that any rehearsal marks or tempo text that do break a multimeasure rest in parts with this latest build actually create infinite (?) copies. I tried dragging a tempo text to the left, and it unveiled a second copy underneath. I was able to uncover dozens of such copies before tiring of this. Since this issue wasn't marked fixed, maybe this code wasn't intended to be final, so I'll refrain from submitting a separate bug report for now.

No significant change for me. Some of my score are in wrong format when mmbrest exist.

Robert

Behavior is changing daily, it seems, but it seems inconsistent. Currently I am getting rehearsal marks to break rests correctly. But tempo text is now *not* breaking rests, and furthermore, it isn't displaying *at all* in parts at all for me in scores created from scratch, rests or no rests. Staff and system text continue to exclude the measure from being included in a multimeasure rest in all cases. As discussed, that *might* be OK for staff text, but not for system text.

Also, see #23380: Manual position of rehearsal marks & tempo text in parts not preserved on save/load, #23381: tempo text not displayed in parts, and #23382: Rehearsal marks display as empty boxes in parts until reload.

There is also #23028: Rehearsal marks not displayed in parts with multimeasure rests. I think that one is actually fixed now, but I'm hesitant to mark it as such yet.

Hello,

For me seems to work like a charm in e03ddb3

Text break mmRest (stave or system)
Tempo Break mmRest
rehearsal marks break mmRest

Robert

Are you sure? I just rebuilt and still what i reported above - staff and system text breaking mm rests all right, but both exclude the measure completely from the mm rest. Which as you were arguing before is not good. And tempo text works fine if created in the score *before* parts are generated, but not if added to the score after parts are generated.

Yes you are right, it worked for me on a previous version, but not with last.
measure are exclude from the mmrest.

issue not solved for me too

Edit :
seem to work with
Reharshal mark
Tempo text

No work with (exclude measure)
staff text
stave texte

Fixed in 73954dfc1a

Rehearsal mark, tempo text, staff and system text should now work the same. Meaning they break the mmRest but they are part of the mmRest measure. Tests are very welcome!

Works great, thanks! I'm OK with needing to explicitly set the *next* measure to break mm rest if one wants the staff text to actually appear in a measure by itself. Some day I still wouldn't mind seeing an "exclude from mm rest" option.

As for tests, I'm trying to think how these should go. As far as I know, the only difference in the score file would be the setting of the style option itself - the measures are represented the same either way. So the test would have to be something that checks something internally via QVERIFY. Any recommendations on how that check should go?

I was meaning manual tests. For 'automatic' tests, the only thing I can think of is a visual test.

Hello,

it's seem to work as expected. Than'k.

There is a bug with text, i create a new issue

Robert

FWIW, the texts works great with multimeasure rests in a single score, but not so well in linked parts. I get different results depending on if the text existed before the part was generated or not and also on whether the part has a mm rest at that position. This will take a little while to sort out, but I'll try to submit an issue with an overall summary.

Automatically closed -- issue fixed for 2 weeks with no activity.

Quick question on this issue. In v2.0 beta, when I place chord symbols every 4 bars on a staff filled with rests, each chord gets placed over a bar with a whole rest, followed by a 3-bar multi-measure rest (see attached screenshot). The output I would expect to see is the chord symbol over top of each 4-bar multi-measure rest. The way it is now is confusing to a musician. Is there a way to change what's generated? Should I file this as a separate bug?

Thanks!

I think seeing a chord symbol over a rest is going to be confusing whether it looks as in the above *or* as one four bar rest. I want to see slashes or something else indicating I am supposed to actually *play* for those four measures.

But in any case, I would agree chord symbols should work like staff text in this context - they should break the mmrest but still be part of it. So it *is* worth filing a new issue.