[MU4 Issue]Transpose using a shortcut for 'Transpose up half a step' gives strange results.

[grigorax]

Describe the bug
Using a shortcut (OPT-T in this case) for the action 'Transpose up half a step' can give four different results depending on what was selected and how. Only one of these results is correct (Case (3).)

To Reproduce
Define the shortcut OPT-T for the action 'Transpose up half a step'.

Case (1)

1. Using the very simple test score attached, click in bar 1 to select it. Then do OPT-T.
2. The key signature changes from Dm to D#m for bars 1–19. Then it reverts to Dm in bar 21. In bar 22, the key Dm is restated.
3. In bar 1 only, the notes and the chord are transposed, as expected.

Case (2)

1. Click in bar 2 to select it. Then do OPT-T.
2. There is no change in key signature. The notes and chord of bar 2 are transposed correctly.
3. The rest of the score does not change.

Case (3)

1. CMD-Click on any selection of notes, so they all go blue. Then do OPT-T.
2. The selected notes are transposed (as expected), but not their chord.

Case (4)

1. Make any selection with a blue rectangle, that starts on the first note of the first bar of a line. Very Strange!
2. Then do OPT-T.
3. This applies, in this score, to bars 1, 10, and 21.
4. The result is similar to Case (1).

Case (5)

1. Select the whole piece. Then do OPT-T.
2. The key signature changes, for the whole piece, to D#min.
3. This is all very well, but the same key signature is restated in bar 22.

Case (6)

1. Select an empty bar. Then do OPT-T.
2. No change.

—I am sure there are heaps of other cases to try, but that should enough to go on with.

Expected behaviour
It is not clear from the name of the action, 'Transpose up half a step', whether or not the check box, 'Transpose key signatures', conceptually, is checked for this action.

Let's assume that, for a selection with a blue rectangle, this box is always "checked".

Then the key signature should change to D#min at the start of the selection, and then go back to Dm at the end of the selection.
This never happens.

For a selection of individual notes (Case (3)), assuming the check box, 'Transpose key signatures', conceptually, is NOT checked for this action, then the behaviour is as expected.

Screenshots for Case (1):

Platform information

• MacOS 13.1. Macbook M1 Pro.
• MU Version - (Nightly) OS: macOS 13.1, Arch.: x86_64, MuseScore version (64-bit): 4.0.2-230470504, revision: github-musescore-musescore-a36e598

Additional context
Notes.
The shortcut action, ‘Transpose up half a step’, is ambiguously defined.
I found that the undo action, CMD-Z, did not always return the score to its original state. I.e.,
In the sequence: State-1, Action, CMD-Z, State-2, it seems that State-2 is not always = State-1.
e.g.,

• Different Layout
• Notes enharmonically different.

Alternative to the shortcut: Click on the Key signatures panel. Result: The result is much the same, except that when I tried it, a similar error was produced for all bars, not just the first bar of the line.

[grigorax]

Here is the score.
Transposition Error - BLANK Score.mscz.zip

[MarcSabatella]

FWIW, this command is a holdover from very early on in the development of MuseScore. Its behavior was never very well defined and most people found it pretty annoying because it was given a default shortcut that people would hit accidentally and mess up their scores. The default shortcut was removed some years ago but the command itself remains very awkward. I'm not convinced it needs to still exist, but if it does, it should be redesigned from scratch I think.

[oMrSmith]

I agree and think: It makes more sense to use the normal transpose function and then descide
whether to transpose by a minor second or by an augmented prime.

[grigorax]

I agree with Marc. I find the Transpose menu item under 'Tools' is daunting to use. I tried assigning a shortcut to the action 'Transpose...', hoping it would at least open the Transpose dialogue for me. But no, it goes ahead and does its own weird thing. — That was because it promised it would replace an existing shortcut, but it did no such thing. Much better to use the Palette in conjunction with the arrow commands. Get rid of the Tool, I say.

But don't forget that using the Palette also causes the error under discussion, as in my notes.

[MarcSabatella]

To be clear, I am absolutely not recommending getting rid of the extremely useful and necessary Tools / Transpose dialog. Just the separate command that operates without the dialog. The Palette is useful for changing key signature, but and the arrow keys for changing pitch in specific ways, but the Tools / Transpose dialog offers a ton of functionality you simply can't get any other way. if you need help learning how to use it, first try the transposition info in Handbook section on pitch, and if you have further questions, please ask on the Support forum.

[grigorax]

You're right Marc, that was a bit intemperate! I am sure many people prefer using the dialogue method. If one stays clear of that shortcut I was using, I guess it's OK. However, MuseScore's 26-item drop-down menu is for me a bit of a deterrent. Transposition is not something I do a lot of, I am just intrigued by the bug with the first note of the line, etc.

A very simple improvement to do for the time being would be modify the dialogue window : (1) put more space between the Chromatic and Diatonic sections. (2) Increase the indent distance and get rid of those rectangles.

If change (1) makes the dialogue window too tall, have two menu items – Transpose Chromatically and Transpose Diatonically.

[sammik]

@grigorax I guess, most of strange things were fixed by #17601 and one (cancel in bar 22) hopefully will be fixed by #18279

so if You have some time, please, check Your score with following PR build
https://github.com/musescore/MuseScore/suites/13966482028/artifacts/778554724

Thank You

[grigorax]

With that Github link I get 'Page not found'. – Even with https://github.com/musescore/MuseScore/suites/.

[sammik]

With that Github link I get 'Page not found'. – Even with https://github.com/musescore/MuseScore/suites/.
Strange, it should work.

Or You can find it on this page https://github.com/musescore/MuseScore/actions/runs/5417835047
at the bottom under "Artifacts"

[grigorax]

OK thanks I got it.
– OS: macOS 13.4, Arch.: x86_64, MuseScore version (64-bit): 4.1.0-231610302, revision: github-musescore-musescore-644a78d

But, sorry, no change. I tested it on the same 'Blank' score as above, using OPT-T as a shortcut for 'Transpose up a semitone'. I got the same result, for all cases.

[sammik]

@grigorax I did some test.

1. strenge key signature at bar 22 - it is fixed by fix #18197 #18212 correct instrument change and key signatures behaviour #18279 (PR build I pusted), but you need to create new test file from scratch.
   In Your test file, F key signatures are resent and saved in measures 21 and 34, thats why they appear after transposing. You can verify it by changing key signature in first measure - you will se key change inmeasure 21, and if you delete those change, another one appears in measure 34.
2. _"It is not clear from the name of the action, 'Transpose up half a step', whether or not the check box, 'Transpose key signatures', conceptually, is checked for this action."
   Answer is - Yes, it is checked and does exactly, what it says, it does - transposes also key signatures, if key signatures are selected. That's, why, if you select first measure, it transposes key signature (because KS is there), and if You select only second measure, it doesnt transpose key signature (because there is no KS in second measure)

So I dont see any issues here, it works as it should (by design), but behaviour is different, then You expected.

[grigorax]

I see my problem now. This time I created the score using the supplied revision, and this works much better.

• There is no more that glitch at bar number 22.
• Thanks for your clarification in point 2.
• For bars not including bar 1, the behaviour is as I would expect.

However, if I select bar 1 in the upper stave and press OPT-T, I get, in my piano score

• A change in the key signature for the whole of the upper stave (=RH)
• No change in the key signature for the lower stave (=LH). !!!
• (The notes are transposed as expected.)
  See the attached score. —I think this does not look correct.

TB 4.mscz.zip

I still do not agree that a bar specifying a key signature (implicitly in the case of Cmaj at the start of the score) should be treated any differently.

[sammik]

However, if I select bar 1 in the upper stave and press OPT-T, I get, in my piano score

• A change in the key signature for the whole of the upper stave (=RH)
• No change in the key signature for the lower stave (=LH). !!!
• (The notes are transposed as expected.)
  See the attached score. —I think this does not look correct.

Well, I think, it is also by design: "what is selected, that is transposed".
(It is valid to have different key signature in left and in right hand.)

[zacjansheski]

Let's close this, it is mostly resolved/"by design" and it has become a tad too convoluted for efficient action moving forward. If there is still an issue in the master, feel free to open a fresh log, thank you!