Sequential Multimeasure rests in parts
The score I am working on has a G.P. in m. 4. In its "Measure Properties" the "Break Multi Measure Rest" is activated. (And, as a side note, MMR only show when there are 3, not 2, emtpy measures.)
The measure is indeed broken, but when there are further empty measures, a new MMR is shown, but not the one measure with its "G.P." instruction. So I set "Break Multi measure Rests" in bar 5, too. But that does not change anything in the behaviour of the Part. Just for testing purposes I also set "Break Multimeasure Rests" in bar 6, but no change.
Can anybody confirm this behaviour? I am on a Mac 10.11.1 with MuseScore 2.0.2.
As a related question: How do you solve the "G.P." problem?
Thank you!
| Attachment | Size |
|---|---|
| Bildschirmfoto 2015-11-19 um 09.43.47.png | 22.54 KB |
| Bildschirmfoto 2015-11-19 um 09.50.18.png | 14.22 KB |
Comments
Please post the score. The pictures merely back up what you have said in the text but seeing the actual score often helps others sort out your problem or allows a bug in MuseScore to be highlighted and corrected.
I added a short test score, where m. 3 and 4 are defined to break MMRs.
Thank you!
In reply to I added a short test score, by rowild
I don't see the break multimeasure rest option set for measure 3 in the scoire *or* in the parts. I guess maybe you are trying to set it in the score, but if you want it to take effect in the parts, you need to set it there - measure properties are not normally linked (although they perhaps should be - see #64636: "add to measure number" is not linked between score and parts after reload.
but under normal circumstances, this should almost never be necessary. Multimeasure rests are broken for specific reasons, and MuseScore already breaks for those reasons automatically - key or time signature changes, clef changes, tempo changes, double bars, rehearsal letters, other system text, etc. If you have a measure where it seems to make sense to break the multimeasure rest, chances are extremely good it is for pone of those reasons and will thus break automatically.
But indeed, in the rare cases where you need to break a multimeasure rest for some reason that is not handled automatically, you need to set the property in the parts - or set it in the score *before* generating the parts.
In reply to I don't see the break by Marc Sabatella
Indeed,using a system text instead of a staff test and eventually hiding it achieves the result. Thanks for that tip!
In reply to Indeed,using a system text by rowild
Why would you hide the text? Wouldn't the person reading the part want to know what is happening at that spot that caused the multimeasure rest to break? If it's because that measure marks the start of a new logical section of a piece, that's what double bars are used for. I get the sense there is something I am not understanding about what you are trying to do, and the sense that maybe there is something else that you should be considering, but I can't tell what.
In reply to Why would you hide the text? by Marc Sabatella
Thank you for your interest in my topic I hope it does not take away too much valuable time of yours, especially since it is not a problem any more, now, that I understood how it works.
Nevertheless I will try to explain myself better - let's see how successful I'll be. :-)
Let's start with the first included image, which shows the desired result:
It shows an instrument part that has no music over the first 5 or so measures. However, there is a G.P. in m. 3, which should be shown as a distinguished single measure. So the music should read 2 MMR, 1 bar with a rest and the G.P. text, and then again a 2 (or more) MMR.
If only m3 is defined as "Break Multimeasure Rest", this happens:
First a 2 MMR, the a 3 MMR, which, in this case, is not the desired result. Here I have to admit that I - being new to MuseScore - expected a Finale behaviour, where, once a G.P. instruction is inserted (which is a special instruction, I think...), this kind of break happens automatically. But of course this second image it a total correct behaviour, so there is nothing wrong with how MuseScore handles MMRs.
Nevertheless I needed a solution, and it is achievable via what is shown in the third image:
In the meantime I also realized that MMRs can be set individually in the parts, which is awesome. I didn't know that, when I startet this post - sorry!
So, bottomline: everything works just fine for me! Of course, if you have a better solution, I am all ears!!!
One comment, though: wouldn't it save some clicks, when - upon selecting a measure - those measure attributes, that only appear on right-click, would be shown in the inspector? Right above the "select notes / rest" buttons?
Thank you! I hope I could clarify my situation a bit better...
PS: I edited the third image and moved "TEST" above m. 4... just in case you are wondering...
PPS: added new test file
PPPS: It is actually something that a fermata does in Finale and Sibelius, e.g.
In reply to Thank you for your interest by rowild
OK, thanks, that helps a lot. I was thinking you were trying to hide the G.P. text, which is why I was confused. You were actually trying to set the *next* measure to also break. The G.P. should be system text since it applies to all parts, so MuseScore *does* break rests there automatically. But it doesn't also break at the *next* measure by default. Perhaps it should. And good point about fermata as well. For now, though, you do have to do this manually.
FWIW, setting the explicit break in measure properties *before* generating the parts would have worked. But of course, you're unlikely to realize you need it until after. I do think we should look at changing the behavior with respect to what happens when setting measure properties in a score - I think properties like that probably should autoamtically be linked. or at least, we should consider adding an "Apply to Parts" button to the measure properties dialog. But that's only one piece of a bigger question we are still trying to sort through regarding which changes should be linked and which shouldn't and how to override this.
As for the Inspector, yes, it's certainly possible that more settings currently in dialog could be moved to the Inspector. It's a buit tricky, though, because the Inspector works on individual elements, and the measure properties dialog is meant to be available with pretty much anything selected.
In reply to OK, thanks, that helps a lot. by Marc Sabatella
Thanks for your time, ideas and thoughts! All very interesting to me!!! :-)
Looking forward to your next achievements!