Text not kept when moving (cut-paste) an existing rehearsal mark

• May 31, 2015 - 13:07
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

I was surprised to notice that the text of a rehearsal mark is not kept when moving it from one bar (cut) to another (paste). Bug or feature? I couldn't find anything about it in the handbook or in the issue tracker.

For example, using this simple score:
ms_rehearsalmarks_before.png
Moving "B" to the 3rd bar transforms it to "A1"
Moving "Verse" transforms it to "Chorus1"
ms_rehearsalmarks_after.png

Win7 - 2.0.1

Attachment Size
test_move_rehearsal_marks.mscz 4.38 KB

Comments

• May 31, 2015 - 15:44

This is currently by design, mostly. Pasting rehearsal marks auto-calculates the next letter in sequence. That enables you to add the same rehearsal mark from the palette over and over (which is basically a paste operation) and have it keep incrementing as it goes. I can see this is always what one might want, however. We should perhaps consider a way of disabling this for ordinary copy and paste, or otherwise making it optional.

Although, in your sample score, moving the "B" via cut and paste *should* have recreated it as "B", since that *is* the next marking in sequence. And pasting any *other* marking into that slot works - just pasting the B itself does not. I think the algorithm is outsmarting itself - it sees the B it is trying to add and thinks it is already added, then decides it needs to change to A1 to squeeze it between the A and B. Or something like that. So that much is a bug, I think.

Reply

• Jun 2, 2015 - 04:24

(Above, I meant to say, "I can see this is *not* always what one might want")

I found the code responsible for this. It's my code, but to be honest, I have no idea what it is trying to accomplish. There are two lines where, after calculating the next letter in sequence (the variable "s"), I reject it if it is the same as the text of the rehearsal mark I am pasting (the expression "current->xmlText()"). I do this here:

https://github.com/musescore/MuseScore/blob/31a8d3d82a0277714a070d90a77…

and here:

https://github.com/musescore/MuseScore/blob/31a8d3d82a0277714a070d90a77…

The question is, what was I thinking? There must have been some case I was trying to handle. I know the same code is used for copy/paste and also adding from the palette. But right now I can't think why I have those tests comparing s and current->xmlText().

Simply skipping those tests seems to fix this problem. It must break something else or I wouldn't have added that code, but I can't figure out what breaks.

Reply

• Jun 2, 2015 - 08:09

Thank you for your swift answer!

I know that, I've already have several times similar situations "Huuuh? What the h**k did I want to do here???" ;-)
Leave it like this a few days and don't modify it yet, maybe the reason will come back later... :-)

Reply

• Jun 8, 2015 - 02:33

The mystery is solved, I think:-). For anyone curious, this was a fallback used to handle a case where MuseScore was unable to detect a sequence.

In fixing this, I propose to simply disble the automatic resequence on copy/paste, reserving it only for adding via the palette (and of course the explicit resequence command in Edit / Tools).

Reply