old style multimeasure rests

• Jan 19, 2015 - 21:59
Reported version
S5 - Suggestion

It would be nice to have the option to use old style multimeasure rests as shown in this image:



I think it is more than nice - it's essential in order to be able to type-set using the highest industry standards. Where it really matters is in placing the the courtesy 1 over a single bar rest without have to go the trouble of using the symbol pallet to drop a 1 in then manually space it. Setting the multi-bar minimum to 1 doesn't help as this generates the h-bar syle of rest for a single bar.

If this feature were to be added I'd hope that one could individually select h-bar or the older style combinations of mixed breve and long rests. In addition one would need this feature to work for up to 9 bars rest as per other well-known music type-setting programs.


All the time. Check out any classical music publications from quality publishers. It is the preferred way with Bärentreiter, Henle, Breitkopt etc. When I say classical I include serious music from the 20th and 21st centuries, not just 18th and 19th century.

As an orchestral player I would prefer on every occasion to see the multi-measure rests specified as combinations of semibreve, breve and longa rests for anything up to 9 bars. It helps with the counting without having to use ones fingers overtly. It also helps clarify 8 vs 3 and 1 vs 4 when the music is worn and the numbers ambiguous.

I feel strongly enough about this that I am prepared to insert these manually into a piece I am currently editing, which will entail having to hide the h-bar rest and manually drop in and position the block rests and numbers from the symbol pallet. Painful and time-consuming, but doable.

I'm aware that it was common as recently as the 1950s, but I'm wondering whether it's dropped out of usage in, say, the last ten years. (Not counting re-issues of previously typeset music.) I'm not against the idea of adding this as an option just to imitate a historical style, but it would move up the priority ladder if it could be demonstrated that, yes, some brand new music written today uses that old style.

I used a time signature of 8:2 in the second movement a neo-Baroque concerto grosso I wrote last spring. As a result, the program generated longa rests (as whole-measure rests) for empty measures in the score, and for single empty measures in the parts. For consistency, it would be better to use the old-style rests throughout all the parts, but only longas are available as active elements. I can get a graphic for maximas by dragging them from the Master Palette, but the larger value rest symbols aren't available anywhere in the program that I can find. Besides, it is a major pain to have to drag inactive graphic-only elements onto a score which must also contain the active elements those graphics are intended to replace visually. Sometimes this requires moving things to a second voice; others it simply requires making things invisible, but it's extra work either way.

I would really like those rests to be an option.

I would like to see this feature, too. Not only are the old style rests more elegant looking (in my opinion), they are generally more space efficient.

In my personal experience, "most" publishers used these say 100 years ago, "many" used them say 50 years ago, "a small number of" publishers still use them today. Primarily I see them in instrumental classical music - not so much in choral music, jazz, show music, marching band, etc. And they tend to not be seen very often in music published for schools from what I have seen, so I suspect current / future generations will be increasingly unfamiliar with them. Musicians who came up 50 years ago or who play in professional orchestras are probably more familar with them than the population at large. That's my sense, anyhow, although everyone's opinion is colored by the their particular slice of life experiences.

Anyhow, I do think they are common enough to be worth some motivated person spending some time implementing this option.

I can confirm this as far as musicians being familiar with it goes. I had my music lessons fifty years ago and I remember seeing these rests in orchestral parts. I never figured out the system before reading your post where it is neatly represented. (It reminds me of nothing more than of Roman numerals). Nobody ever explained it to me, even back then. It was not necessary since the Arabic numeral was alway printed above and gave all the info I needed. So even I, schooled fifty years ago, wasn't properly familiar with it.

As to counting covertly: I don't quite understand how this different notation (prettier than the Musescore pattern though redundant) helps in that. I hold the neck of my fiddle in my left hand and the bow in my right hand. I lift the fingers slightly as they become "due", one at a time in each hand. Is this covert or overt? We all hold instruments in at least one hand and can't count the way children do when they make their first attempts at arithmetic.

"I never figured out the system before reading your post where it is neatly represented."

Indeed, I forgot to mention that myself. ;-)

Hello, I'd love to see those kinds of rests as well, in particular since I'm digitalizing a bunch of my scores and want them to look as authentic as possible. And personally, I do find those multi-measure rests easier to count and keep track of. I use and encounter those daily.

I add them manually. They are a bit of a pain to do that way, but in my opinion worth doing.
I don't use them beyond 9 bars rest.

Example attached.

I generally find Gonville more elegant than other fonts, but not when it comes to the multi-measure rest symbols. For those I drag and drop them from the Bravua symbol pallet, then hide the original rest notation. Without having support for these in musescore one has to adjust them whenever the layout changes, so I make sure that they are the last thing I do after I've don't with bar spacing and inserting courtesy and cautionary accidentals.


Attachment Size
bass.pdf 187.55 KB

Is there any chance we can get some support for this in the product? It is a pain having to do this manually, especially as any change in bar length will necessitate the component parts of a multi-bar rest to be manipulated manually.


In principle it wouldn't be that hard to add this support. If you're sufficiently motivated, this could make a pretty good first project (after maybe dipping your toes in the water with some bug fixes etc).

Ok, that, in theory is a deal. As a professional developer I need to get formal approval from my company to contribute to an opensource project, otherwise this will need to wait a couple of years. More mundanely I need to get the build environment installed, which I tried earlier but found some dependency issues that I need to work through. It may be easier to set up a clean environment on virtual machine. We will see.


Unfortunately my spare programming time is "owned". That doesn't necessarily preclude participation in personal oss projects. Just requires protocols to be followed.

I am tentatively looking into how this could be implemented. Big learning curve for me, particularly as I normally code in assembler or lower level - I can deal with that. But suggestions and pointers as to where the relevant code parts are would be gratefully accepted. In particular I'd like to know where in the code we implement the layout of a mm rest - ie pick the graphics to draw such a beast.

Very cool! Although this is indeed a somewhat ambitious first project, it is at least pretty self-contained. The basic creation of the mmrest is in layout.cpp, Score::createMMRest(). Ideally, this function wouldn't change, only the layout, which is in Rest::layoutMMRest(). But really, that function does very little, most of it is done during the "drawing" stage: Rest::draw(). It's likely you'd also want to fiddle with the width calculations, such as in Measure::setStretchedWidth(), to keep these from being too wide.

As a first step to understanding the code, an excellent way to get started would be to see if you can fix the glitch where the number above the mmrest bar does not appear if you scroll up so it is off-screen then back down. I can't find an actual open issue for this, but I guess you probably know what I mean? I suspect the issue is not setting the bbox() well enough during layout, so that we aren't realizing we need to redraw the number, but it's actually but mysterious to me. You'll sure learn a lot trying to figure it out, though!

In reply to by mike320

Yes, I see it, as soon as the h-bar is scrolled out of the window, the number goes as well. So it looks as if the part og the code responsible is only accounting for the H-bar symbol and not the attached number. If you move the H-bar up or down the stave the issue recreates at the moment the H goes off screen.