musescore / musescore/MuseScore
Explode loses the slur between a grace note and its main note
@miiizen is already working on this.
Since Sep 8, 2026.
- Dominant language
- C++
- Stars
- 15.1k
- Forks
- 3.3k
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 91
Description
Issue type
Engraving bug (incorrect score rendering)
Description with steps to reproduce
- Create a single staff (e.g. "Flute") with 2 voices, each containing one normal note with a grace note attached before it.
- Add a slur between the grace note and its main note, in both voices.
- Select the measure(s) and run Tools > Explode.
Actual behaviour: Explode moves voice 2's note (with its grace note) down to the new second staff, but the slur between the grace note and the main note is lost on that staff. The voice that stays in place (voice 1) keeps its slur.
Expected behaviour: both slurs should be preserved after Explode, exactly like ties are preserved on notes that get moved to another staff.
Supporting files, videos and screenshots
Screenshot showing "Before explode" / "After explode": the slur is present on staff 1 (unchanged voice) and missing on staff 2 (exploded voice), annotated "slur is lost".
In which versions of MuseScore Studio is this issue present?
5.0.0 (main branch)
Regression
I was unable to check
Operating system
macOS
Additional context
Root cause identified: when Explode separates voices onto different staves (ImplodeExplode::explode, src/engraving/editing/implodeexplode.cpp), it clones each voice via CloneVoice::cloneVoice(..., link=false). In doCloneVoice (src/engraving/editing/clonevoice.cpp), the code that reconnects slurs to their new start/end note looks up the correspondence via the old note's links() list — a mechanism that only works for linked clones (used by the "exchange voice" feature), not for the plain clones Explode creates. For ordinary notes this goes unnoticed because a later fallback (Spanner::findStartCR/findEndCR) re-resolves the slur endpoint by tick+track. That fallback can't find grace notes, though, since a grace note shares its parent's tick and isn't the element actually stored in the segment — so a slur anchored on a grace note has no way to be recovered, and is silently dropped.
Fix ready, will be submitted as a PR referencing this issue.
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
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.
Assessment
This issue has not been assessed yet.