Various issues with copy & paste for list selections

• Jul 20, 2021 - 23:29
Reported version
3.6
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

To reproduce:
a) In a new score add several 1/4 notes, then add lyrics to them (e.g. "one two three")
b) add a hairpin that spans those notes
c) add the same number of 1/2 notes in a later measure
d) CTRL+select (list select) the hairpin and the lyrics and copy to clipboard
e) paste them on to the first 1/2 note
f) lyrics are pasted note-for-note but hairpin only extends across first two notes
OR
a) In a new score add at least 8 notes
b) add various elements such as slurs, ottava lines, pedal marks, breath marks, tempo marks, system text etc. etc. to the first 4 notes
c) CTRL+select (list select) all these elements (not the notes) and copy to clipboard
d) paste them on to the fifth note
e) nothing happens!

Actually this is only a small sample of some of the behaviours that happen when copying and pasting a list of non-note elements in the score. Figured bass in particular has some especially odd behaviour when multiple F.B. indications on the same note are copied & pasted.

I spent quite a lot of time trying to figure out all the current logic/limitations, much of which I documented in https://musescore.org/en/node/2861 but that was specifically about copying single lines, which I have now fixed (in the MU4 codebase), so I think it makes sense to start a new issue for copying list selections (range selections are covered elsewhere too).

Essentially though there are two fundamentally different algorithms used to determine the target of pasted elements:
a) paste according to relative time position - the new symbol is pasted with the same length and same relative start position in "ticks". Currently this is used for lines, dynamics, chords symbols and fret diagrams.
b) paste according to relative ordinal note/rest position - elements are reattached to the "nth" note/rest relative to where they were originally attached, regardless of duration. This occurs currently for all text-type elements except dynamics/chord symbols/fret diagrams, and articulations/ornaments.

Even a) isn't actually a single case, because for chord symbols/fret diagrams it's able to create new hidden segments as needed to ensure they occur at exactly the same relative tick position, but for lines/dynamics this isn't true, they're pasted onto whatever note occurs at or just before that time position (meaning they can be pasted on top of each other). Also for b) lyrics behave slightly differently to other element types as they are never pasted onto rests (how important is it to preserve this?).

From a user perspective, having two completely different algorithms apply for the same paste operation doesn't seem sensible at all, and further, at least for many types of element, both choices are useful/valid.
Obviously certain operations aren't going to be sensible (pasting an articulation where there is no note!), but they can just be skipped as needed.

So my proposal is that we support both, but the user should choose what they want - I'd think the default operation should be "preserve time positions", but I'm not sure what you'd sensibly call the option "preserve ordinal note position" or the best way to allow the user to choose it (I'd be fine with it being a shortcut key, e.g. ctrl+shift+V mapped to an action, probably doesn't need a menu option at this stage). Alternatively the default is "preserve ordinal note position" which at least has the merit of being less likely to require skipping certain elements, and the new action is called "Paste preserving time positions".

Unfortunately there are some limitations in current code that would make certain logically-useful operations very difficult to implement (specifically - being able to create hidden segments to attach text and lines too), so whatever improvements are implemented initially will still have to be a compromise. But I think we can go with a starting point of either a) or b) "as best we can", even accepting that in some cases it still won't produce an ideal result (e.g. if you selected two lyrics from consecutive 1/4 notes and pasted them onto a 1/2 note with "preserve time positions", it would either need to skip one lyric, or concatenate them together)

And note as part of this the intention is to expand support to all types of element. There may be some cases that fall into the "too hard" basket (time signatures come to mind!). But given that this is a list selection - the user has deliberately chosen specific elements and copied them to the clipboard, the assumption should be that they expect them all to be pasted. I've already looked at what's involved in supporting the various elements that currently don't paste with list selections (especially lines) and I don't see any insurmountable difficulties there - e.g. the logic for pasting hairpins can easily be generalized to work with all lines, and likewise the logic for pasting Staff Texts (and Stickings!) can be generalized to work with rehearsal marks/tempo indications/system text etc.

One thing I haven't covered is whether to extend pasting a list selection that includes notes/rests. This becomes thornier but ultimately if we allow a user to include notes/rests in their list selection and for them to copy it to the clipboard, it means they expect them to pasted. In such a case the ONLY sensible choice is "paste preserving time positions". But for now I'm assuming they are never pasted (as is the current behaviour).


Comments

FWIW, the feeling when this was implemented was that indeed the user did expect those different things depending on the type of element copied. Users don't always expect perfect consistency, they expect things to work "naturally", and that can mean differently for one element type versus another if that is what seems most natural. What happened was, it was first implemented it was only for articulations and maybe lyrics, using the "nth" method. When chord symbols were added, it was realized this didn't make sense, so the new method was added, and after some discussion, the feedback was not to mess with the existing behavior. But frankly, I have a hard time imagining use cases where I'm sure I'd prefer the "nth" method, and I kind of doubt anyone would really notice or mind if it were changed.

I can totally understand why both are useful, especially for lyrics. Sometimes you want the same words sung over a different rhythmic pattern, other times (particularly choral music) you want the lyrics to happen at the same time positions (*). Chord symbols likewise - in most cases you probably want to preserve the time positions, but in other cases the same harmonic sequence follows the changed rhythm of the melody.
Articulations/ornaments are arguably never usefully copied just to the same time position, but it's not that often I'd expect a user would bother selecting a bunch of different articulations/ornaments and pasting them elsewhere where the note durations etc. were very different.

(*) And ideally pasting lyrics in such case should be smart and add in melismas etc. as needed, and possibly even break up notes as needed to ensure each lyric has a note to attach to.