Paste leaves "residual" chord names
OS X 10.10.1 NB ff55cdd
This is an annoyance when copying and pasting blocks of slash chord measures in rhythm instruments.
1. Copy a two measure block with slashes and chord names above the first slash in each measure.
2. Highlight a different two measure block of slashes with chord names above the first and third slash in each measure that are different than the ones that you copied.
3. Paste the first two measure block over the highlighted two measure block. The chord names above the first slash are changed to the chord names from the copied block. However, the chord names above slash 3 in both measures is preserved.
See before and after screen shots, plus the attached test score.
| Attachment | Size |
|---|---|
| Screen Shot 2014-12-17 at 9.13.23 AM.png | 11.55 KB |
| Screen Shot 2014-12-17 at 9.13.42 AM.png | 11.28 KB |
| Test Chord Copy Paste.mscz | 4.4 KB |
Comments
This is one of this case when sometimes you will love the behavior, sometimes you will hate it... It's pretty cool that the chordnames are not removed in my opinion. So I would call it a feature.
Seems we've gone back and forth on this, also whether chord symbols are removed on delete of a range. The feature of replacing chords on the same beat was added just this summer I think, and at the time, it seemed to make sense to preserve the chords that were not being replaced. I don't have strong feelings about this. One good thing about the current behavior - if you *don't* want to keep those chords, it's easy enough to remove them but hitting Delete just before you paste. Whereas if we changed it to remove these chords on paste, there would be no obvious way to prevent that.
OK I guess I will accept this verdict although it is not clear to me how the current behavior is beneficial.
I think this can remain open for discussion. One benefit is as I already - the current way, you can get the behavior you want with just a single extra keystroke. If it were changed to work the way you want by default, there would be no correspondingly easy way to get the current behavior. So if there exists *any* reasonable use case for the current behavior, I think that seals the deal. On the other hand, if there really is no possible situation where anyone would ever want to keep the current chords, then maybe the ability to get that behavior isn't so important.
I cannot think of a situation where a "copy/paste" procedure would be invoked that would not require a replacement of the changes if they are included in the "copy" procedure.
It makes sense to me that the chord names should be replaced.
In terms of deletes, perhaps a choice of whether or not to include the changes could be included.
Chords *are* replaced. That is, if there is a chord on beat 1 in both the source and destination, the chord in the destination is replaced by the one in the source.
The question is whether chords that are *not* replaced - like if there is a chord on beat in the destination but not in the source - should be arbitrarily deleted. Currently, they are *not* - if they don't need to be replaced, they are left in place.
On further thought, it seems "obvious" to me that is is correct and necessary. Consider, what if you've carefully entered a whole series of chord symbols into a passage. You then decide to replace the notes only, not the chords, by copying in a different passage that has no chord symbols at all. Do you want this to result in all the chords in the destination to be deleted? I say, surely not!
For delete, chords are included unelss you exclude them via the selection filter.
So it still seems to me the current implementation is the most flexible. If you want the old chords deleted, you can delete them,. if you don't, then don't. And when deleting notes, you have a chocie whether or not to delete the chords. I think any change to this would remove some very useful functionality.