Problem using CTRL-DwnArrow and Ctrl-UpArrow to move a set of notes down strings sets on the Tablature Staff

• Feb 22, 2021 - 08:57

I installed the latest release of Musescore 3.6.2.548021803 a few days ago (Windows 10 Pro) . I created a new score with a linked staff using Acoustic Guitar and Tab. 6-str. Simple.
I first noticed the issue in a larger score, but I have reduced it to 1 measure to simplify the issue.

1) I entered 4 quarter notes such as F A C E in arpeggio fashion in the top standard (Notation) Staff. I then selected the tablature measure and the pressed CTRL+DownArrow several times until I ran out of fretboard. That process takes the same notes in the tablature staff and moves them to lower string sets, higher up on the fretboard. This usage is described on Page 118 of the latest PDF manual.
2) I then pressed CTRL+UpArrow several times until the notes were back at the original strings and frets.
That exercise was successful!
3) I then stacked the F note with an A above it on the standard notation staff. When I pressed the CTRL+ DownArrow until it could go no lower and then Pressed CTRL+UpArrow numerous times, the stacked F & A moved back where they were, but the other notes didn't move back to where they were originally.

I tried numerous other combinations. The only stacked version that worked successfully was if the last note of the measure was stacked. This has led me to believe it is an indexing error.

I downloaded two in-work musescore builds, the nightly MuseScoreNightly-202102210427-3.x-2ba915f-x86_64, and the MuseScoreNightly-latest-x86_64. Both of these exhibited the same behavior. I tried other scores that I was using, newly created scores specifically for this purpose, and some older version 2 files. Same behaviors as above were observed.
So either I'm doing something silly, or there exists a bug. I took a screen video of this occurring, although I didn't have a microphone hooked up. I tried to upload it with submission, but I'm not sure it accepted it.
While I have used Musescore in the past (V1 and V2), for the last few years I have been using Sibelius mainly because of a similar feature to the one I described above. I use that feature often! Just recently, I decided to try Musescore again and have been pleasantly surprised at the progress that has been made.

I have uploaded a score that has 4 one measure examples with text above each example on how to make the error occur.

Please let me know if I am doing something wrong.

Attachment Size
TestCaseForMusescore.mscz 21.61 KB

Comments

You don't do anything silly, and it's not a bug per se, as far I know (nothing new since the implementation of the TAB feature since version 2)
Let's rather say - for some important constraints in the code I suppose, I won't say more, I'm not an expert in this field - that it's a limitation of the function in these cases. It would be worse if you had three-note chords, see the attached file : 1TestCaseForMusescore.mscz
In short, the best thing to do is to avoid this kind of situation, ie modifying measures containing single notes and chords (with single notes, it works as expected, as you noticed)
And if not, just edit (with Ctlr + Up) the fret numbers that have not returned to the initial state.

In reply to by cadiz1

Thank you for your quick reply. Although the bug is destructive, one can recover rather quickly IF it is observed. In my short 1 measure examples, it is easy to detect the error, but I have the need to perform this action on much larger sections numerous times a day and daily. I agree with your statement that higher counts of stacking exacerbate the problem. I dummied down the test case in the score I submitted so that the issue could be observed easily and quickly. I respectfully disagree with the statement that it's a "limitation of the function in these cases". I would suggest it was more of a weak test case that caused the issue to remain. Let's see how others weigh in on the issue. Thanks again for your reply.

Do you still have an unanswered question? Please log in first to post your question.