You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when you enter a note in a measure in MuseScore (as in any other notation software, of course), the measure is automatically completed with the necessary rests.
The rest grouping, though, is correct only in simple meters. In compunds meters, this happens:
Although using 4th+8th instead of a dotted 4th was common in old scores, it's not standard anymore. While it could go unnoticed in 6/8, it becomes more evident in 9/8 and dramatically evident 12/8.
This is valid also for different denominators:
For reference, this is a screenshot from Gould's Behind Bars (which I don't necessarily consider to be taken always as the Word of God, but it's still a very reliable and shared source about notation):
The same issue appears to affect complex time signatures. In the example given, the 5/4 meter is set on a 2+3 scheme which is correctly followed for the notes, but not for the rests:
This happens with any complex time signature, always working fine with any customized grouping of notes, but always ignoring it when completing the measure with the necessary rests.
Problem to be solved
In a score featuring solo or few instruments, manually adjusting the wrongly grouped rests in compound and complex meters wouldn't steal a lot of time (since you proceed to write notes sequentially anyway); but in a big orchestral score, when it happens very often that an instruments plays only the first beat, this could result in a significant amount of time spent in tweaking something that shouldn't even happen in the very first place, since it doesn't happen in simple meters (and in any other notation software).
Prior art
In Sibelius, this is the automated completion of a 12/8 measure:
This is a 7/4 measure setted to a 2+3+2 subdivion, correctly applied both on notes and rests:
Checklist
This request follows the guidelines for reporting issues
I have verified that this feature request has not been logged before, by searching the issue tracker for similar requests
The text was updated successfully, but these errors were encountered:
Your idea
Currently, when you enter a note in a measure in MuseScore (as in any other notation software, of course), the measure is automatically completed with the necessary rests.
The rest grouping, though, is correct only in simple meters. In compunds meters, this happens:
Although using 4th+8th instead of a dotted 4th was common in old scores, it's not standard anymore. While it could go unnoticed in 6/8, it becomes more evident in 9/8 and dramatically evident 12/8.
This is valid also for different denominators:
For reference, this is a screenshot from Gould's Behind Bars (which I don't necessarily consider to be taken always as the Word of God, but it's still a very reliable and shared source about notation):
The same issue appears to affect complex time signatures. In the example given, the 5/4 meter is set on a 2+3 scheme which is correctly followed for the notes, but not for the rests:
This happens with any complex time signature, always working fine with any customized grouping of notes, but always ignoring it when completing the measure with the necessary rests.
Problem to be solved
In a score featuring solo or few instruments, manually adjusting the wrongly grouped rests in compound and complex meters wouldn't steal a lot of time (since you proceed to write notes sequentially anyway); but in a big orchestral score, when it happens very often that an instruments plays only the first beat, this could result in a significant amount of time spent in tweaking something that shouldn't even happen in the very first place, since it doesn't happen in simple meters (and in any other notation software).
Prior art
In Sibelius, this is the automated completion of a 12/8 measure:
This is a 7/4 measure setted to a 2+3+2 subdivion, correctly applied both on notes and rests:
Checklist
The text was updated successfully, but these errors were encountered: