old style multimeasure rests

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.

Richard

Does any currently published music use that style? I'm genuinely asking.

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.

Looks great. I've never used these before but they could be very useful.

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.

Richard

Thanks.

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.

Richard

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.

Richard

You can do it in your spare time, like me ;-)

If it takes you a couple of years, then I'll beat you to it in a year or so. ;-)

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

Came up again in https://musescore.org/de/node/266665

came up again in https://musescore.org/en/node/281302

Came ujp again in https://musescore.org/en/node/17047#comment-908967 ff.

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!

Thanks Marc, I need to take my time over this - lots to learn. I will look at the scrolling issue start with.

I sure thought I had submitted a bug report for the disappearing multi-measure rest numbers. So here it is. #290968: Multi-measure rest numbers disappear during scrolling

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.

https://github.com/musescore/MuseScore/pull/6211

Hi Isaac, thank you so much for doing this. I had started to look at it months ago, but got into a fix trying to install a development set up for musecore on my home/work system - too many incompatible dependencies, which needed me to set up a fresh linux system for the purpose of musescore development. Now the work's done, I'd like to test it. Is it included in the nightly build?

Richard

No, so far it ia just a pull request

OK, thanks. I assume that means pulling source from the git hub. I'll have to wait for the nightly build if that's the case.

One question I have regarding implementation: how are traditional MB rests handled when the time signature is 4/2 or 6/2 or bigger? With these time signature, 1 bar rest is signified by a breve and because of the ambiguity with the same symbol meaning 2 bars rest for higher numbered denominators then it's usual to place the number 1 above the 1 bar in multi-measure mode. What I'm suggesting is that when traditional multi-measure mode is selected then the arabic numbers should aprear above all full bar rests from 1 onwards.

Second less obscure question, is the limit on use of the traditional MB rest symbols, customizable? For example is it hard-coded to switch from traditional to the H-bar symbol say at 10 bars or above or can that be customized?

Richard

If you happen to work on Linux or macOS, I can make the PR "collect_artifacts" to generate a build immediately. Great point about numbering 1-bar rests, I'll be sure to add that as an option. And yes, the limit is customizable.

FYI, the artifacts get generated for Windows too - actually that was implemented before Linux or macOS.

For those not familiar:

What happens Is that builds get generated and tested each time you create or update a PR, but normally they are automatically deleted. collect_artifacts just saves the build before it is deleted, so you can retrieve it by clicking the PR link then a few more steps from there. End result is similar to a nightly build.

I didn't know about the Windows builds, where can those be found?

Also, is there any reason (such as hosting limits) to use collect_artifacts sparingly?

Windows builds are found within the artifacts section of the AppVeyor build within the PR.

I assume the reason they aren’t always kept by default is storage, so yeah, I’d do it only when you have something you specifically want people to help test.

This promises to be a really nicely done enhancement. I really appreciate it. As I only have access to Linux, if a build could be generated easily, i'd certainly test it out.

Download Linux build for testing here: https://github.com/musescore/MuseScore/suites/795851796/artifacts/85326…

I was able to test the code thus far. Noticed one small glitch: if you number multi-imeasure bars from 1 and select old-stype, then no rest symbol appears in the 1-bar rest. Related to this. There is a needed to be able to make the numeric invisible when the numbers clutter the bar. Generally speaking when numbering single rest bars, if another mark such as G.P. is applied then the number is omitted. If the symbols and the numbers can be separately marked hidden/visible then that issues is easily dealt with.

Richard

Interestingly, according to the experts at https://www.facebook.com/groups/musicengravingtips/permalink/2395316834…, in such a case (with such time signatures and with old-style rests enabled), the one measure rest is not a breve but a whole rest, centered within the measure, and with the number "1" above it.

Maybe I am misunderstanding your comment. If you look at page 160 in Gould you'll see 1-bar examples for 4/2 and 5/2 which show a breve. Because the reader can't know which convention the setter is using, then using 1 above the bar disambiguates this situation.

You mean the last of these bars?

If I understand you well, in such a situation you would show the 1 above the bar?

yes those last two bars. It's a house style preference. I would certainly show a 1 above a one-bar rest whether it were using the breve or semibreve rest symbol. I can do this manually, but then I need to hide the 1 in a score as that generally doesn't use MB rests. That's a common house style with traditional publishers of classical music such as Bärenreiter or Breitkopf & Härtel. Bärenreiter in particular his highly regarded.

I've been shown these, from a 1927 Breitkopf and Härtel edition of Ein Deutsches Requiem (time signature 3/2):

Please try https://github.com/musescore/MuseScore/suites/800425465/artifacts/86289….

Fixed in branch master, commit 92102737fa

Fix #44846: Add old-style multimeasure rests

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

To allow multimeasure rests, I have devised a workaround.
First, create a regular H-bar multimeasure rest by pressing M.
Next, make the multimeasure rest invisible by pressing V.
To make it easier to see the old-style multimeasure rest, go to View, then untick the "Show Invisible" checkbox if it isn't unticked already.
Next, go to the Master Palette (Shift + F9) and type "rest" in the search bar. You should find a collection of rests. (see rest.PNG)
Drag whichever rest you wish to insert into the bar with the invisible H-bar multimeasure rest.
Repeat this process until you have the rests you need.
Lastly, type the number of bars the rests takes up by inserting text (Ctrl/Command + T)
(see old-style-multimeasure-rest.PNG)

That would certainly be a neat feature to have

Actually I could go beyond 9 bars for an interesting look

Then try MuseScore 4 Beta

I have MuseScore 4.0.1 which has the Old Style Multi-Measure rests

I wanted to extend the Number of Old Style Multi-Measure rests above 99 to like Infinity cause these have the advantage of being more compact

You'd need to enable them.

I've enabled the old style Multi-Measure Rests mode but the highest amount I can have is 99 currently & there's really no way I could expand the number of old style multi-measure rests to have more than 99 Measures.

Open a new issue for that, best directly on GitHub

Alright

I've wanted to update it to make it work w/ the Time Signatures 4/2 & bigger.

Please let this issue RIP