Delete notes/measures or change offsets in first measure when there are beaming notes in the next system/staff causes a crash
latest version: 073fcdc
1. Open attached file
2. Select any syllable from two first systems
3. Either:
- Press [ctrl] + [←] or [ctrl] + [→]
- In Object Controller uncheck Automatic Placement
4. Crash...
Attachment | Size |
---|---|
StworcoGwiadzistych2.mscz | 13.04 KB |
Comments
Same last commit 073fcdc / Windows7
First of all, this issue is not fundamentally due to the presence of lyrics or not.
- By deleting these lyrics, you can get a crash, eg, by cutting the first or second note of the score (or by unchecking "Automatic placement" in Inspector).
See the file at this step: 1) StworcoGwiadzistych2.mscz
- By adding a time signature (which was cut in the original score, why, by inadvertance?), the improvement is real. You can cut the first note, and the issue seems fixed.
See the file at this step: 2) StworcoGwiadzistych2.mscz
This lack of time signature is an important part of this issue. But the problem more fundamental is elsewhere.
- Indeed, if you copy and paste the first measure in the fifth (the first of the next system), then you delete again the first or second note of the score, again the crash occurs (or by unchecking "Automatic placement" in Inspector). See the file at this step: 3) StworcoGwiadzistych2.mscz
The reason: rhythm / beams are similar in the first measure of each system
So, to reproduce from scratch:
1) "My First Score"
2) Enter two eighth notes in the first measure
3) Enter two eighth notes in the measure 5 (first of second system)
4) Cut the first or second eighth note (first measure), or untick "Automatic placement" in Inspector
Result: crash
- Same behavior by deleting the content of the whole measure (Del). No crash by deleting the note or measure belonging to the second system.
EDIT: Same crash with a different step #4. Instead of cutting a note, do: Exit note input mode-> again Note input mode -> enter an additional note in the first measure -> crash
- Other example of crash (after "Del" the first measure)
No stack trace, but output if a failed Assertion (on a self-built version in DEBUG mode):
Debug: ChangeProperty::flip(): Note QVariant(bool, true) -> QVariant(bool, false) (...\MuseScore\libmscore\undo.cpp:3344 , virtual void Ms::ChangeProperty::flip())
Fatal: ASSERT: "!isEmpty()" in file C:/Qt/5.6/mingw49_32/include/QtCore/qvector.h, line 230 (:0, )
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Very recent issue (three days), on October 18.
- This nightly works: 7f9585a
- Not this one, the only one of October 18: 681a27f
Maybe a new side effect of this commit?: https://github.com/musescore/MuseScore/commit/79b7746f5b49c79889d5a4733…
cadiz1 wrote: By adding a time signature (which was cut in the original score, why, by inadvertance?)
No, it was done by purpose - it's based on gregorian chant.
By the way - thank you for your investigation
"No, it was done by purpose - it's based on gregorian chant."
Okay. But it's not really a good idea to delete a time signature - this can lead to some issues. Really preferable to simply hide this time signature ("V" shorcut), and if wished, untick "Show invisible" in View: completely harmless for the same displayed result.
Well. I have to say that I am impressed.
So far (I mean before 2.0) removing
timestamptime signature could allows to fit another measure in the same system:Hidden
timestamptime signature:Removed
timestamptime signature:I have just discovered, that from now on hidden
timestamptime signature behaves the same as removed:There's another problem - it's really hard now to select hidden
timestamptime signature in order to un-hide it... But, that's different issue.Cadiz1, thank you for your tip. Since now I will definitely hide
timestamptime signature.I am sorry for off-topic.
"it's really hard now to select hidden timestamp in order to un-hide it... But, that's different issue."
Indeed, different issue, thanks. This one: updated: #137511: Clef collides with time signature after adding a staff and Undo
Title updated, because no necessary that the notes in the first measure of staff/system have beams. Only in the next one (staff/ system)
See this test file: new test.mscz
1) Delete the note measure 1, or the whole measure (or change any offsets in Inspector
Result: crash
2) Change the note value (quarter note, half note) in the measure 5 - so, no more beams.
Result: no issue when the step #1 is repeated.
See also #138396: Crash while reseting chord positions
Probably it is good to add the possible workarounds:
1. unbeam all notes - work on the piece - re-beam them
2. in continuous view it seems to be possible to work with beams and without problems.
(doesn't that point to a problem of viewing?)
Is f8c3049 already the cure for this?
Apperently this is indeed the fix, with that commit I can't reproduce the crash, without I can.
That was a quick fix though and it probably doesn't fix the root cause of the crash. Not sure why the beamsegment array is empty. Maybe werner has a better idea.
f8c3049 fixes the crash, but another issue appears (with step1, comment #8): the beam of the eighth notes measure 5 is now broken (image below)
Same test file: new test_0.mscz
And re-appears by entering a new note in measure 5 or following.
Fixed in branch master, commit 8dfc84f701
fix #138211 restore beaming for last measure in partial layout
Seems to fix the given problems, but I have now other problems:
the clefs are missing for the attached file, and also there are problems with overlapping lyrics.
appimage-file on linuxmint
ea88600
"the clefs are missing for the attached file"
Indeed, due to a new bug introduced there is two days. To correct this: right-click on lute staff -> Staff Properties -> Tick "Show clef"
Result: the clefs for the voices are returning. And if wished, hide the Tab clef. So: Kremberg3.mscz
For the lyrics, worth to be thorough.
Automatically closed -- issue fixed for 2 weeks with no activity.