Cross-measure beaming does not respect full note value when “Display note values across measure boundaries” is enabled
Nobody has claimed this yet.
Assessment
This issue has not been assessed yet.
Description
Issue type
UX/Interaction bug (incorrect behaviour)
Description with steps to reproduce
Environment
MuseScore Studio 4.6.4
macOS
Description
The example is from Chopin's Op.28 No.5.
When the option Style → Score → “Display note values across measure boundaries” is enabled, MuseScore correctly displays a note starting near the end of a measure with its full nominal value across the barline (e.g. an eighth note starting on the second half of beat 3 in 3/8). And the duration of this note is correctly recognized as eighth.
However, beaming behavior does not match the displayed note value: The note is displayed as a full eighth note, but when it is beamed together with a preceding eighth note in the same voice, MuseScore renders the beam group as one eighth note + one sixteenth note, instead of two eighth notes beamed together.
This creates an internal contradiction between:
- the displayed note value (eighth note across barline), and
- the beaming logic, which still follows the internally split durations (sixteenth + sixteenth).
Expected Behavior
When “Display note values across measure boundaries” is enabled:
- Beaming should follow the displayed (nominal) note value, not the internally split duration.
- Two eighth notes that visually appear as eighth notes (even if one crosses a barline) should be able to form a normal eighth-note beam group.
Reproduction Steps
- Create a score in 3/8.
- Enable Style → Score → Display note values across measure boundaries.
- In one voice, enter:
- An eighth note on the second half of beat 2.
- An eighth note on the second half of beat 3 (crossing the barline).
- Attempt to beam the two notes together.
Supporting files, videos and screenshots
In which versions of MuseScore Studio is this issue present?
4.6.4
Regression
I was unable to check
Operating system
macOS 26.2
Additional context
No response
Checklist
- This report follows the guidelines for reporting bugs and issues
- I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
- I have attached all requested files and information to this report
- I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible
- Dominant language
- C++
- Stars
- 15.1k
- Forks
- 3.3k
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 91
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from musescore/MuseScore
-
engraving P3 UI
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
needs design
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
community P3 UI
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
regression nightly UX/interaction
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
All issues in musescore/MuseScore
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
LadybirdBrowser/ladybird#12123 ·