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
Issue type
Engraving bug (incorrect score rendering)
Description with steps to reproduce
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 viaCloneVoice::cloneVoice(..., link=false). IndoCloneVoice(src/engraving/editing/clonevoice.cpp), the code that reconnects slurs to their new start/end note looks up the correspondence via the old note'slinks()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