musescore / musescore/MuseScore

Explode loses the slur between a grace note and its main note

Open
#34,809 0 comments 0 reactions 2 assignees View on GitHub

@miiizen is already working on this.

Since Sep 8, 2026.

engraving needs review
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
  1. Create a single staff (e.g. "Flute") with 2 voices, each containing one normal note with a grace note attached before it.
  2. Add a slur between the grace note and its main note, in both voices.
  3. 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".

Image
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.