stem too short after changing octave of a note in a chord

• Oct 26, 2013 - 03:07
S4 - Minor


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.

Attachment Size
short-arpeggio.png 1.06 KB
Status (old) active patch (ready to commit)

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.

Status (old) closed active

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.