create a quarter note c-chord ... 'n', '5', 'g', 'c', 'e' -- at this point the stem is correct.
drop the e down octave 'shift-down-arrow' -- notice the stem is now too short
I think that other issue is indeed a duplication. This one is probably worded better, so I'll close the other as a duplicate of this. First, though, here is additional info I posted to the other issue:
Trying to attach an arpeggio to such a chord ends up yielding incorrect results as well.
Example: created chord as C G E Ctrl+Up. The stem will be incorrect after the Ctrl+Up - too short. Now add an arpeggio. This will also be too short.
Selecting the whole chord and pressing Down and then Up fixes both problems.
Incidentally, the problem occurs with any move of a note in a chord, but the sequencing issues that cause the problem also mask it most of the time in single line moves.
I'm not entirely happy with this fix, as I've said in the PR. However, I think it produces the correct result.
Seems this has started happening again. Since I've been mucking with the layout code, I assumed I broke it and looked into it, but I think the culprit is actually this:
which removes the code added as part of the original fix.
The issue is caused by notes not being sorted within the chord before the call to layoutChords1(), which expects notes within each chord to be sorted by line. The original fix was to make sure upDown sorts the notes after each change. I think it still should. We could of course add another sort call to layoutChords1(), but then it happens on each layout and not just on the actual upDown operation itself. So unless we're making a policy decision to no longer bother keeping notes sorted within a chord, I think we need to re-implement something like the original fix for this issue.
Comments
problem seen in nightly build:
f3e7de1
Hi mtherieau
That commit is a month old. Can you please try with the latest?
I wonder if it's a duplicate of this: #22560: Stem disappears when layered note is moved an octave by ctrl+up
Thanks
Note that saving the file with the short stem and reloading the file will fix the issue.
I think that other issue is indeed a duplication. This one is probably worded better, so I'll close the other as a duplicate of this. First, though, here is additional info I posted to the other issue:
Trying to attach an arpeggio to such a chord ends up yielding incorrect results as well.
Example: created chord as C G E Ctrl+Up. The stem will be incorrect after the Ctrl+Up - too short. Now add an arpeggio. This will also be too short.
Selecting the whole chord and pressing Down and then Up fixes both problems.
https://github.com/musescore/MuseScore/pull/677
Incidentally, the problem occurs with any move of a note in a chord, but the sequencing issues that cause the problem also mask it most of the time in single line moves.
I'm not entirely happy with this fix, as I've said in the PR. However, I think it produces the correct result.
6f49e49
Automatically closed -- issue fixed for 2 weeks with no activity.
Seems this has started happening again. Since I've been mucking with the layout code, I assumed I broke it and looked into it, but I think the culprit is actually this:
https://github.com/musescore/MuseScore/commit/ef3a7da47cbc597571c30a8f5…
which removes the code added as part of the original fix.
The issue is caused by notes not being sorted within the chord before the call to layoutChords1(), which expects notes within each chord to be sorted by line. The original fix was to make sure upDown sorts the notes after each change. I think it still should. We could of course add another sort call to layoutChords1(), but then it happens on each layout and not just on the actual upDown operation itself. So unless we're making a policy decision to no longer bother keeping notes sorted within a chord, I think we need to re-implement something like the original fix for this issue.
fixed in ecc4ee0fa5.
Automatically closed -- issue fixed for 2 weeks with no activity.