-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix #222031: remove ties and spanners when removing induvidual notes within a chord #3564
Conversation
a48d0df
to
1b8679d
Compare
|
||
void Note::connectTiedNotes() | ||
{ | ||
if (tieBack()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible that tieBack() returns nullptr? If it is, whether it is a corrupted logic or usual case?
If it is a corrupted logic, it is better not to check nullptr since it allows finding the corrupted place faster thanks to the crash. It is better for development to have crashes on invalid program state, than checking nullptr and skipping such corrupted program state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, note may have only a forward tie or no ties at all, and in those cases tieBack()
will return nullptr
. I see nothing wrong about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is calling connect/disconnect valid in the case of nullptr ties?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the purpose of these member functions is just to ensure that all ties that should be connected to the given note will be properly connected (or disconnected) with this note and those notes that should be bound to it with the ties. The note is not required to have any of those ties, and if it doesn't have them then these functions will just do nothing.
In fact, these functions are based on the code that was placed in undo.cpp and chord.cpp to handle ties connection/disconnection when adding/deleting a single note. I moved it to separate functions to make note deletion process more unified (which was the purpose of the whole commit) and reduce code duplication, and made some changes to make it suitable for more general case that that of deletion and addition of the note to the chord. Although my "generalization" may be not so good, the discussed checks on existence of backward and forward ties were present in the previous version of this code too (see, e.g., this), so I have not added anything when assuming that the note in the considered cases may have just one tie or no ties.
@dmitrio95 there are conflicts when manually merging the fix to 2.3. Could you please create the separate PR to 2.3 for this fix? |
@anatoly-os OK, I will prepare a new PR when I have a time. |
Thank you! |
@anatoly-os Just have opened #3712 with this patch ported to 2.3. |
In the current version of MuseScore removing individual notes within a chord behaves differently compared to removing the whole chord. While this can be a little surprising from the user's point of view, such a behavior may also lead to crashes like the one described in this bug report.
This pull request is aimed to handle individual notes removal in a way more similar to the case of removal of the whole chord, i.e. remove properly ties and spanners connected to the note being removed and restore the correct previous configuration when undoing the removal.