Slurs to grace notes disappear after inserting measures

• Oct 15, 2019 - 11:59
Reported version
3.2
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project

OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.2.3.7635, revision: d2d863f

  1. Create an empty score.
  2. Add a note in bar 1 and in bar 2
  3. Add a grace note to each main note
  4. Add slurs from the grace notes to the main notes
  5. Insert one or more measures immediately before bar 2

Result: the slur in bar 1 remains correctly placed; the main note and grace note in bar 2 are shifted right to accommodate the inserted bar(s); the slur attached to the note in the original bar 2 is not shifted right and is positioned on the screen where it was before the bar was inserted.

  1. Save score
  2. Re-open score

Result: the misplaced slur is no longer shown - i.e. neither in its misplaced nor its "correct" position - it has just disappeared.

  1. Add a note the last bar of a system.
  2. Add a grace note and slur to the main note
  3. Insert a bar immediately before this to force the next bar onto the next system.

Result the slur from the grace note to the main note has disappeared (there is no misplacement - it has just gone.)

But if, instead of 10, you add a system break immediately before the bar with the gracenote the slur from the grace note to the main note moves with the note onto the next system.

Other information:
- The same behaviour occurs for all types of grace note, and for groups of grace notes.
- The same behaviour happens in page view and continuous view.
- A tie between a grace note and a main note is not affected - i.e. it moves with the notes.
- Before saving and re-opening, selecting the misplaced slur and inspecting it shows zero offset.
- Before saving and re-opening, the "elastic" lines shown after double clicking on the misplaced slur indicates that it is still associated with the grace note and main note.
- Forcing a re-draw by switching between continuous view before saving and re-opening leaves the slur in its misplaced location - it does not disappear until the score is saved and re-opened.

This behaviour is particularly annoying as it is very rare that a grace note is not slurred onto the main note and all grace note to main note slurs in a score that occur after the insertion point of the new bars are affected and have to be replaced after bars have been inserted. Clicking on a grace note and using "select all similar" does not help as with all gracenotes selected if one adds a slur, this is entered as one huge slur from the first grace note to the last grace note. Each gracenote has to be a) found, b) selected, c) have a slur added individually. This gets tedious and is error prone.


Comments

Regression No Yes

Just checked behaviour of:

  • MuseScore version (32-bit): 2.3.2, revision: 4592407

and

  • MuseScore version (64-bit): 3.3.0.8677, revision: cf84ff0

MS 2.3.2 behaves OK. The slurs move with their associated notes and grace notes after bars are inserted and remain in the score after a save and reload. So definitely a regression

MS 3.3.0 has the same bad behaviour reported in the original post.

Status PR created fixed

Fixed in branch master, commit a37fda3e5b

_fix #295703: Slurs to grace notes disappear after inserting bars

Resolves: https://musescore.org/en/node/295703.

When the SPANNER_TICK property of a spanner changes, the spanner's startElement and endElement are invalidated. Usually the spanner's start and end elements can be recalculated from the SPANNER_TICK and SPANNER_TICKS properties, but since grace notes occur on the same tick as their parent notes, determining the real start and elements for grace note slurs is tricky. The solution here is to invalidate the start and end elements in an undoable manner before changing the SPANNER_TICK property of the spanner when time is added or removed before the spanner's start, and then set the start and end elements back to what they were. This required modifying Score::undoChangeSpannerElements() so that the start and end elements can be changed to or from nullptr._

I (the OP) used "bars" as that is what MS uses in it's menu -"Insert bars". Or is that just a UK localisation thing? Whatever, "bars"/"measures" doesn't worry me.

The issue tracker is generally in American English as a standard. It makes it easier to find existing issues if there is consistency. The is actually a British English translation of MuseScore so those who speak the British form have MuseScore in their own language, just as is done for the French, Dutch and so forth.

Fix version
3.3.1