copy/paste and "R" do not delete slurs or lines in target measures
1. Create two measures each containing at least one slur and a line.
2. Copy measure 1 and paste it over measure 2.
Result: Measure 2 now has all the slurs and lines combined from the old measure 2 and the pasted measure 1.
Expected result: Measure 2 should no longer contain anything from the old measure 2.
I am using MuseScore nightly ff2b92c on Kubuntu 14.04 64-bit.
Note: I did find this closed bug report: http://musescore.org/en/node/29446, but since it was dealing with a crash, I didn't re-open it, but created a new report instead.
Fix version
3.1.0
Comments
There has been a considerable amount of back and forth on these points. The current behavior is, I would argue, "mostly" correct, according to the compromises reached as a result of the discussions that led to this point.
If you are copying a measure with hairpin (for example) into another measure that already has a hairpin, then you do indeed end up with two hairpins, and that is probably not what you want. But if your source measure does *not* have the hairpin, chances are pretty good you want to *keep* the existing hairpin. Similar for pedal and other lines. Especially voltas, since they are not copied anyhow. And it's not just just about copy & paste - what about entering new notes via note entry mode. Normally, one would want to preserve most of the lines where possible.
For some background, see #28761: Lengthening note before a line produces incorrect results, plus the other issues referenced within that thread.
I could see an argument that maybe slurs should be treated differently, since they are more likely to not make sense any more when copying a non-slurred passage into a slurred one - the old slurs may not make any sense for the new passage. They are already deleted if their attachment points are removed as a result of the copy - eg, a slur betwene beats 2 & 3 is deleted if you copy a whole note into the measure. Maybe they should be deleted in all cases for copy and paste specifically, even if *not* for note entry.
For copy & paste, it is *also* possible we could make a special case if the *source* contains hairpins or other lines and choose to delete any corresponding lines in the destination if so. But actually, there is a simple method of avoiding the duplication already - just deselect the appropriate line type in the Selection Filter before doing the copy. This will keep the lines in the destination, not the lines in the source, but chances are pretty good that's just as good or better, I would think.
Anyhow, I think you'll see there is more to this issue than meets the eye, and meeting all needs is easier said than done!
Okay, I can see the benefits of this by design, particularly regarding lines. However, I would argue that non-volta lines--and slurs in particular--should be replaced unless they extend beyond the pasted range. This also is more consistent with the copy behavior, as lines are only copied if the line's beginning and end point are anchored within the copy range.
Take this example:
![copying lines 01.png]( "copying lines 01.png")
![copying lines 02.png]( "copying lines 02.png")
If I copy measure 1 and paste it over measure 2, I get:
I can't think of any scenario where this would be the desired behavior. I would expect instead that measure 2 would appear exactly like measure 1.
Starting again with the initial example above, if I copy measure 2 and paste it over measure 3, I get this:
![copying lines 03.png]( "copying lines 03.png")
This behavior is more expected, because the slur starting on beat 4 of measure 3 extends beyond the region I am pasting over.
Another example:
![copying lines 04.png]( "copying lines 04.png")
![copying lines 05.png]( "copying lines 05.png")
If I copy measure 1 and paste it over measure 2, I get:
...which is certainly never what I would be attempting to accomplish. However, MuseScore's current behavior when copying and pasting measures within a long, multi-measure ottava marking is expected behavior.
So, to summarize: any non-volta line that both starts and ends within the paste region should be replaced, whereas any lines that extend outside of the paste region should remain exactly as they do now. This is my opinion, of course, but I can't think of any scenarios where this behavior would be undesirable or unexpected.
The cases where the current behavior is desired are quite simple to state - the case where the source does not *also* contain its own version of the same lines. Your examples always assume the source *also* contains lines and hence there will be duplications, but that isn't necessarily the case.
Eg, you have entered a line for a 2nd trumpet part with slurs, then you decide to replace it with the notes from the 1st trombone part, which do not contain slurs. Why remove the slurs unnecessarily? Although as I said, I can see slurs being a special case - they are actually the only lines that are attached to specific notes and note just time positions. Hmm, maybe trills too. Still, to me it's a toss-up, and again, the advantage of the current system is you can always filter out the slurs or trills on the copy operation if your source happens to also have them.
It's also important to consider methods of replacing contents other than copy and paste - I specifically mentioned note entry, and I think it pretty clear one would not expect a hairpin to disappear just because you happened to change some of the notes in that measure. It was lines disappearing needlessly that started the whole series of changes a few months.
It really quite a delictate balance, and I would be wary of changing much about it. I'm not saying there is no possible room for improvement, but I think your proposed change would go too far. I would not want to see a hairpin deleted just because I replaced the notes in the measure. You can always delete lines after the fact, but it's more work to add them if they are deleted.
This makes sense, I guess. It's just very contrary to what I'm used to from years of using other notation software like Finale, which is why I thought it might be a bug. At least it's easy enough to work around by deleting the measures first before I paste into them.
I do think it's worth considering slurs and trills as special cases, though, as they are really more like articulations. One wouldn't expect a pasted measure to inherit the replaced measure's staccato and accent markings, so why should slurs and trills be any different? (Of course, the existing behavior should still be preserved when dealing with lines that extend beyond the paste range.)
The problem with the example you gave regarding the trumpet and trombone parts is that at least in my case, I am almost never copying musical material similar enough where inheriting slurs would be a desired behavior. To me, that would be like copying the words from a paragraph, pasting them over another paragraph and inheriting the destination paragraph's punctuation. In 99% of cases, this would lead to incorrect punctuation.
Anyway, I don't wish to overstate my case. It would be interesting to hear input from other composers on this matter.
Thank you for all the work you put into this wonderful project! I currently own Finale 2012, but I have been preferring to work in MuseScore ever since the 2.0 beta came out. There are so many ways that MuseScore's workflow trumps Finale! I am so excited for the 2.0 release! :)
I don't think you are overstating your case; indeed I think that you are MAKING a case. This is interesting.
:)
I agree, it's interesting :-) BTW, I did choose my trombone and trumpet example to be pretty "real world" - it's not uncommon at all in bag band writing for trumepts and trombones to have virtually identical rhythms, but no slurs in the trombone part because a slur on a trombone is basically a gliss. So actually, it is *not* unusual in this particular instance that it would make sense to keep the original slurs. I run into this case on a pretty regular basis, in fact, not that I've ever consciously relied on this particular "feature".
Anyhow, right now I'm leaning toward agreeing it is probably worth special casing slurs and trills, maybe only for the specific case mentioned where there is a copy and paste that replaces both the start and end note at once. It is pretty important, I think, that we don't delete a slur just because we replace the start note - that was got us into this mess in the first place :-)
The code that handles the deletion of lines when notes are placed is divorced from the code that actually does the replacing. I think that's good, because it means we could add the special case in the "paste" code without affecting anything else at all.
I was about to open an issue on this behaviour when I saw it was already open.
Mark, I understand the different situations you are presenting, but aren't we producing (let say) 95% unexpected behaviour to be able to handle 5% of the cases? Ok I don't have any statistics, each usage is different, just a gut feeling ;-)
Taking the examples of Chris (#2), spontaneously and intuitively, I would really have expected:
- example 2 to never happen
- example 3, bad luck for me, to lose the slur to bar 4
That said, I needed an unconditional copy-paste and after a very long and tremendous :-) analysis of the problem, I've found my workaround: delete the destination bars before pasting.
I teach composition and have been encouraging all of my students to use MuseScore for their composition/arranging work. Now that I have had students bringing me scores over the past five months, I can see just how confusing this copy/paste issue has been for them. I find that my students are very puzzled when they paste over a measure to find the pasted measure inheriting the slurs, etc. that were in the old measure. This is clearly not what they expect to happen. To make matters worse, sometimes they don't notice the retained slurs/lines, especially when copying/pasting a large number of measures. I have to correct their scores when they bring them in, and they say things like "I never put that slur there... how did it get there?"
I would like to reiterate my previous suggestion for improving this behavior:
1. Pasting should replace all slurs/lines that are contained within the paste region. Slurs/lines that extend outside of the paste region should remain.
2. Copying will only copy slurs/lines that are contained within the copy region. Slurs/lines that extend outside of the copy region should be ignored.
This behavior would be logical to every musician I have talked to about this matter, and would be especially helpful to my young students.
I agree with s.chriscollins, the current behavior when both ends of the slur are in both the source and the destination just makes for more examination and work after the paste.
![Copying over slurs 1.png]( "Copying over slurs 1.png")
![Copying over slurs 2a.png]( "Copying over slurs 2a.png")
I start with
The two parts I now want in complete unison, so I copy the measure in the top staff over the one in the bottom staff. Now I get
So I then have to go through the destination area and (a) recognize and (b) delete the 'double slurs' - quite time consuming for an extensive paste.
This bug was recently highlighted on Tantacrul's popular YouTube video "Music Software & Interface Design: MuseScore" starting at 28:53.
See https://github.com/musescore/MuseScore/pull/4855
Fixed in branch master, commit 14ebaa81d4
fix #45361: remove extra annotations and slurs on pasting range
Fixed in branch master, commit a01cf31bf4
_Merge pull request #4855 from dmitrio95/45361-copy-paste-replace-elements
fix #45361, fix #281083: remove extra annotations and spanners on paste and note duration change_
Automatically closed -- issue fixed for 2 weeks with no activity.