old style multimeasure rests

• Jan 19, 2015 - 21:59
Reported version
3.0
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Status
closed
Regression
No
Workaround
No
Project

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

http://upload.wikimedia.org/wikipedia/commons/thumb/c/c4/Old_multirests…


Comments

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

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.

Richard

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.

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

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.

In reply to by Isaac Weiss

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

In reply to by Jojo-Schmitz

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.

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

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.

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.