Allow modification of default for filling measures with rests

• Sep 12, 2019 - 12:54
Reported version
3.2
Type
Functional
Frequency
Few
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
MuseScore

There are a number of situations currently where the default behaviour to fill a measure with rests after adding a note leads to non-standard notation. For example, after adding a dotted crotchet at the start of a 6/8 bar, the last half of the bar is filled as a quaver rest followed by a crotchet rest. However, standard notation would have the last half of the bar filled as a crotchet rest followed by a quaver, or perhaps with a dotted crotchet rest (not my favourite!). Another example is when notating a bass part for a waltz with just a crotchet on beat 1 of every bar. The bar is filled with a minim rest, rather than two crotchet rests.

I suggest that MS should allow the user to modify the grouping of rests filling a bar in a similar manner to defining beaming groups for different time signatures. So for a 3/4 time signature the default could be defined as three crotchet rests; for 6/8 it could be defined as crotchet-quaver-crotchet-quaver rests.

Comments

• Sep 13, 2019 - 14:43
Title Allow modification of default for filling measures with rests. ⇒ Allow modification of default for filling measures with rests

Wait, so this thread talks about allowing user modification, and node #294411 talks about changing the default style of rest filling, they aren't suggesting the same thing?

Reply

• Sep 13, 2019 - 14:46

True, although I suspect that most people asking for user customization would actually be happy with better defaults. Any implementation that is based on the beaming would tick both boxes, though.

Reply

• Sep 13, 2019 - 16:53

There already is a (much) older issue for this: #4867: Rests in measures should be grouped according to time signature. So I'd say just updated that one, will feel good if we can finally close it soon! The reason to keep both issues open is in case the fix does not involve beam groups or other customization possibilities, we'd want to close the other but still leave this one open, perhaps with some additional information explaining the use case and proposed UI.

Reply