copy / paste of chord symbols does not preserve timing
Windows 7, GIT commit: 3543170
I am calling this a feature request rather than a bug, because I guess it was a deliberate design choice to track notes rather than ticks. I can see that this design choice would be appropriate for certain types of elements like lyrics, but I think it makes the feature all but useless for chord symbols, which are quite likely to be copied onto very different sequences of notes. Since code to honor tick positions is already present (but commented out), I wonder if maybe the behavior could be made element-type-specific, so chord symbols copy accord to tick and other element types accord to note?
Specific steps to see what I'm talking about if it's not clear:
1) open attached score
2) click first chord symbol
3) right click same chord, select all similar
4) Ctrl+C
5) click measure 17 (first empty measure after double bar on third system)
6) Ctrl+V
Result: relative tick positions of chords are not preserved. The Dmi7b5 should come two bars after the Ebma7, etc.
Thinking about the use cases for copying of chord symbols separately from the whole region, the most common ones will probably involve copying across passage with entirely different rhythms (eg, from a written melody to a section of slash notation or vice versa, different passages of a melody over a repeating sequence of chords, etc). The case where the notes are similar but pitches different - really the case the current code is designed to facilitate - are practically non-existent. It would be more likely the notes would be identical aside from transposition, in which case the regular copy/paste of a full region suffices.
| Attachment | Size |
|---|---|
| There_Will_Never_Be_Another_You.mscz | 3.04 KB |
Comments
As you said, it is a deliberate choice, but as a possibly intermediate step:
When the count by notes does not match the count by timing:
*) For lyrics, going by notes makes surely more sense then going by timing.
*) For articulations, it is potentially difficult to forecast the intended result, but it could be argued that going by notes could be preferable in the majority of cases.
*) For figured bass, as chords are always relative to the bass note, going by timing is surely wrong (going by notes may occasionally be wrong too: in that case, there is no 'automatic' solution)
As I have little familiarity with chord symbols, I was not sure how to deal with the last supported case. I provisionally decided to deal with it as with the other, waiting for reactions.
Your description makes clear that the current solution is not what the user would commonly expect and gives unreasonable results; then it can be reasonably considered a bug.
I have posted a pull request fixing this point.
M.
Should be fixed in commit https://github.com/musescore/MuseScore/commit/c87402c85c819f8046abc91e4…
Nice, thanks. Seems this feature will make a nice stop gap until we get true filtering of what gets copied and pasted. In fact, this might easily cover most cases people normally care about. Especially if dynamics and staff text could be added to the list of supported elements (with tick-based semantics just as for chord symbols).
This feature and the 'filtered paste' are two somehow different thinks, or at least they may involve two different levels.
One level is the possibility to select what get pasted, another is the kind of selection involved. Previously there was no way to paste (filtered or not) a disjointed selection. This is a first implementation of the latter.
'Filtered pasting' could be added in future, but disjointed selection had to work in the first place.
M.
Automatically closed -- issue fixed for 2 weeks with no activity.