Pasting notehead onto rest changes rest duration
OS: Windows 7 Home Premium; Product ID: 00359-OEM-8992687-00010.
HW: AMD-A4-3300M APU with Radeon HD Graphics 1.90 GHz.
Memory: 6.00 GB
System Type: 64 bit
Model: HP Pavilion G7
MuseScore Version: 2.0.3; Revision: 3c7a69d.
Title: Right click to paste works, but 'note' repeatedly
Step 1.
Open the test file: Test_20160420_42z.mscz
Result: The test file opens.
Step 2.
Select and right click to copy the last (eighth) note, of the Contrabass line, in the next to last measure.
Result: The last note is highlighted.
Step 3.
Select the last rest in the same measure.
Result: The rest is highlighted.
Step 4.
Right click and paste the eighth-note over the rest.
Result: The note is pasted in, spanning the last two measures with sixteenth-notes, and the following whole note is broken up.
Step 5.
Right click the sixteenth-note that follows the just created tied note at the beginning of the last measure, and select paste to paste an eighth note over that sixteenth-note.
Result: Nothing happens. Repeated fresh copying of an eighth-note and pasting over the the sixteen-note note continues to yield no results.
Step 6.
Click the undo button, at the top of the menu.
Result: Nothing happens.
Step 7.
Continue to click the Undo button, at the top of the menu.
Result: Eventually, the very first paste will be undone.
Comments: The fact that the very first paste will eventually be undone, and the original whole note will be restored, suggests that all the 'pastes' might have been working, but the screen wasn't being updated with the pasted eighth-notes.
About the Title - I know... I'm bad.
| Attachment | Size |
|---|---|
| Test_20160420_42z.mscz | 10.15 KB |
Comments
This is by design. What is happening is that you are only selecting the *note* rather than the *chord*. Copying a *note* copies only the *note* properties - pitch, etc - not the *chord* properties, such as duration. Pasting a *note* onto another note just replaces the desintation note with the pasted note, effectively changing the pitch, while keeping the other chord properties (like duration) unchanged. You aren't seeing this happen because the desitnation chord already had that same pitch, but paste onto a note with a different pitch and you'll see this in effect.
If you want to copy full chord including the duration and other chord attributes, you simply need to copy the whole chord - more technically, a "range" that includes the chord. So, select it in such a way as to get the blue rectangle to appear around it. Eg, with nothing selected, Shift+click the note. Or, click the note, then press Shift+right to extend the selection, then Shift_left to contract it again. Or any of the various other methods of selecting the full chord.
FWIW, this is unchanged from previous versions, except there were bugs (fixed in 2.0.3) that caused the pasted note to also get the transposition wrong.
That being the case, then the same keystrokes operation produces two different results, depending on whether the paste is over a note, or over a rest. The result is an inconsistent UI, which some would consider a UI design error.
This could be altered so that the same keystrokes would always produce the same result (copy pitch, or copy pitch + duration) would always be consistent, whether pasting over a note or a rest. But at this point I imagine there is little support for changing it.
Oh, Contrare...! And this is what is so inconsistent - Copy (by click selecting) and pasting a sixteenth note over a eight note rest DOES paste the pitch AND duration, but copy and pasting over an an actual eighth note pastes only the pitch.
From consistency pov pasting a notehead onto a rest should change the rest into a one-note chord preserving the duration of the rest.
Unless Marc knows a scenario in which this would not be the desired behavior?
Considering that copy/paste (or cut/paste) is so frequently used to move groups of notes, and the key MUST be used, I can now see a reason for requiring shift to be used to also select a single note pitch and duration. Though, the difference between pasting over another note, and pasting over a rest, does yield unexpected and confusing results for the uninformed. The fact that the 'box appears when pitch AND duration are selected gives some indication that something is different, and I can't say that the behavior never provided some warning, but I still associated the blue highlighted note and the blue box around groups of notes as indicating exactly the the same thing - the note(s) were highlighted, thereby and always selecting both pitch and duration.
Maybe this is saying that the UI operation of highlighting note(s), not how it is accomplished (whether the shift key is used or not), should always select either pitch, or pitch and duration. When we copy and paste a string of text (i.e. or pictures, etc.), don't we always copy all attributes with it?
And would anyone ever want to select only pitch for a group of notes? Not very often, I suspect.
So, assuming that the key always has to be used to select a group of notes, and rarely (if ever) is it desirable to copy and paste only pitch when a group notes has been selected, I'd propose the following:
1. Any time a note(s) is selected to copy both pitch AND duration, whether it be by click, of click/click, either
A) a box always be put around the note(s), or
B) the note(s) always only be highlighted without the box.
2. (preferably) Have selecting a single note (by clicking to highlight) copy both pitch AND duration, remembering that the note will be highlighted the same as a group of notes (either with or without a box).
3. If only pitch of a single note is wanted, require the key, or some other key concurrent with the mouse click, but do highlight the note differently from copying both pitch and duration.
The keystrokes are somewhat inconsistent because shift key is used to select a range of notes, but not in the case of selecting a single note. However, the object is that any time note(s) are selected, and the same kind of highlighting is displayed, both pitch and duration are copied. The copying of all attributes is intuitive, and widely expected.
5. Make pasting over a rest consistent with pasting over a note.
And if nobody cares, that's fine with me!
While I do support the bug report as I rephrased it I rather dislike the change you're proposing.
There are other reasons than copy-paste to select a notehead (change its pitch for example, or change its appearance). Selecting a chord instead would make these things harder for me.
Actually, the times I need to copy and paste a single note are extremely rare, as simply entering the same note at the target seems just simpler and faster to me.
For me personally, the only times I wish to select a single notehead is to either change its duration/position (of that one notehead, not of its stem nor the other notes in that chord) or change its appearance (make it a triangle or an x).
So my personal opinion would be no against changing the way selection works now, but yes to making the copy-paste of a notehead to a rest consistent.
My observations:
- At the time you select a note, MuseScore cannot possibly know what your intentions are. So the selection has to be one or the other - the note or the chord. But the latter is out of the question that would make it impossible to select a single note for the purpsoe of, say, deleting it or changing its pitch or adding a fingering etc. So clicking a note absolutely must remain a selection of the note only.
- Copying and pasting a single note would normally be rare. The vast majority of copy/paste operations - like 99.9% - would be to copy a *range* of notes. As noted, if your goal is to simply enter a pitch, it is far far far simpler to just type the letter than to find another note of the same pitch then copy it then go back to the destination and paste. So the behavior we are talking about is something most users will never encounter.
- One of the very few situations where it makes sense to copy and paste a single note is to copy its properties *other* than pitch - alternate notehead, the "play" property, etc. And in these cases, the majorty of the time, you don't *want* duration or any chord properties copied.
- The only other case I can think of where you might be inclined to use copy and paste of a single note rather than simply entering the note is when you really do want to change the duration of the destination. It's still counterproductive in terms of actual effort - it's three clicks (select destination, set duration, enter pitch) to enter a new note, but four clicks (select source, copy, select destination, paste) to do the copy and paste. But it's close enough that I guess I can sort of imagine some case where it might seem to make sense (like you are thinking about the source primarily, and only later do you think about the destination). So indeed somewhere in the world there exists a user who would reasonably expect copying a single note to copy the chord duration along with it in at least some cases.
- Given that the two use cases above end up being mututally incompatible - eg, there exist use cases in which the user would expect the copy/paste to copy note properties only and *not* duration, but other use cases in which he would expect the duration to be copied as well - it's clear there is no way one single behavior can satisfy both use cases. Therefore, we should focus on making both use cases *possible*.
- This is already the case: copy just the note to copy note properties only, copy the chord (range) to copy the duration. Whereas changing the current behavior in this respect to always copy duration as well would be wrong - it would cause the very useful functionality of copying note properties only to be lost.
- That said, I agree it is inconsistent that pasting a note onto a chord keeps the duration but pasting onto a rest does not. I can see why implementation-wise this might be - when pasting onto a rest, there is no chord to keep the properties of, so we have to create a brand new one, and in the process, we take the properties from source note. But sure, when creating the new chord, we might as well preserve the properties that make to take from the destination rest rather than the source note. So I'd consider this inconsistency a bug, albeit an extremely minor one.
See also some discussion also in #248611: Copying note head to rest does not retain note spelling - we also aren't preserving enharmonic spelling.
Anyhow, regarding duration, what do we think? It's true when pasting onto another note, we keep the destination duration, but when pasting onto a rest, we keep the source duration. I believe the request here is for the rest case to be handled same as the note case - the destination duration should be preserved. Is this still the consensus?
I see where the duration gets set (the setNoteRest() call in ChordRest::drop() for the NOTE case), and it's trivial to keep the rest's duration when pasting a note - just pass in duration() instead of data.duration. Maybe check to be sure we do the right thing for local time signatures, except paste is pretty messed up for that case, so there's probably no good answer.
I believe the request here is for the rest case to be handled same as the note case - the destination duration should be preserved. Is this still the consensus?
Yes (as far as me being a consensus counts ;) )
In reply to See also some discussion… by Marc Sabatella
You can't paste into measures with local time signatures, so there no need to worry about them.
https://github.com/musescore/MuseScore/pull/3286
Fixed in branch master, commit 345fe7bfc4
fix #107231: paste of note onto rest should preserve destination duration
Fixed in branch 2.2, commit 33e0d0d1f8
fix #107231: paste of note onto rest should preserve destination duration
Automatically closed -- issue fixed for 2 weeks with no activity.