Problem using CTRL-DwnArrow and Ctrl-UpArrow to move selected notes down strings sets on the Tablature Staff
Posted to Forum on Feb 22, 2021 - 08:57
Several other users have verified the issue with one stating the issue was observed in Ver 2.
I have uploaded a score that has 4 one-measure examples with text above each example on how to make the error occur and not occur.
1) Installed the latest release of Musescore 3.6.2.548021803 (Windows 10 Pro, 64-bit) .
2) Created a new score with a linked staff using Acoustic Guitar and Tab. 6-str. Simple.
3) First noticed the issue in a larger score, but I have reduced the score to 1 measure to simplify the issue.
4) Entered 4 quarter notes such as F A C E in arpeggio fashion in the top standard (Notation) Staff.
5) Selected the tablature measure and the pressed CTRL+DownArrow several times until at least one note was on the lowest string (Low E). That process takes the selected 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.
6) I then pressed CTRL+UpArrow several times until the notes were back at the original strings and frets. That exercise was successful!
7) I then stacked the F note with an A above it. 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 could be 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.
While a user could use CTRL-V repeatedly to back step, this isn't always successful. This was acknowledged by another user in my forum post. On larger notes selections, the score must be carefully reviewed before pressing the save button.
I have uploaded a score that has 4 one-measure examples with text above each example on how to make the error occur and (not occur).
I took a screen video of this occurring which I tried to upload with this submission, but it did not accept it.
| Attachment | Size |
|---|---|
| TestCaseForMusescore.mscz | 21.61 KB |
Comments
I suspect this is related to #71326: TAB note movement issue., which has to do with the order in which we try to move strings. But here, I don't know we give up so soon moving those last two notes. Workaround is to select only those notes. One way or another, one needs to accept that it's not always possible to move an entire selection, so doing things piecemeal is always necessary to some extent.
In reply to I suspect this is related to… by Marc Sabatella
Marc, I read your comments and you may have some valid points, but in my opinion there are some simple cases that show inconsistent behavior. I have attached a second score that is only 1 measure. It consist of 2 Dyads.
The first part of this brief may be overcome by events. see MORE TESTING, INTERESTING RESULTS below.
Select ONLY the left Dyad in the Tablature Staff and use CTRL-DwnArrow and CTRL-UpArrow to move the
two notes in that Dyad. This works as one might expect it do. Now deselect that Dyad and select the right Dyad
in the Tablature staff. Use CTRL-DwnArrow and CTRL-UpArrow to move only those two notes.
That Dyad also works as expected. The two Dyads are basically independent systems. Changing one Dyad
does not affect the other. Now select both Dyads by clicking in the tablature staff measure and press
CTRL-DwnArrow one time. Now press the CTRL-UpArrow one time. You should see that the right Dyad is already lost.
Selecting notes individually from top to bottom helps a bit, but when using repeated CTRL-DwnArrow presses,
it puts an empty string between the 2 notes of the Dyad. And that causes 6 fret spans that are unacceptable to
most players. But if the CTRL-DwnArrow presses are continued until it reaches the Low E string (the bottom line) and then several CTRL-UpArrow presses are utilized, there is no empty string between the Dyad notes.
This behavior is inconsistent.
Other notation programs contain this feature so it's certainly doable. I'll think some more about your response. Maybe I'll do some simulations. At this time, I'm not seeing why the algorithms to do this should be that complicated, but maybe the devil is in the details!
MORE TESTING, INTERESTING RESULTS
I just did another test while I was doing this writeup. Using the same score as above, I selected the two diads in the Tablature staff and moved them up and down the tabulature staff WITH THE MOUSE and it worked.
I then I used another test score. This one had 2 measures and triads, etc. Again, if I used the CTRL+UP and CTRL+DOWN movements the system went luney tunes. When I used the mouse on the selected notes to to move them up and down on the staff, it also works. That score is also attached (Checking Tablature Moving using a Mouse.mscz)
There exists a problem that, at first glance, looks like the score is corrupted like we saw before, but actually the score is intact. The problem is that when moving the selected notes too far up or down with the mouse, the limits are not set correctly and the mouse causes the indexing to go too far both on the High E and on the Low E so it shows garbage. For example if you moved the mouse too far UP while dragging the notes, you get garbage data, but if you continue and move it back down a bit the valid values are displayed. Same for the Low E side except you have to move the mouse up a little. It's likely an array bounds issue...the infamous off by one) that can be easily addressed.
I'm not sure it has anything to do with the positioning of the notes/frets on this or that beat. As Marc said above : "Workaround is to select only those notes. One way or another, one needs to accept that it's not always possible to move an entire selection"
Indeed, the notes return to the initial state not, as you do, by selecting the range of notes with click/click + Shift, but by selecting the notes individually (with continuous pressing of the Ctrl key). In this case, the two lowest notes of the dyads return to their initial position as expected, as well as the lowest of a dyad and the next single note. I haven't gone through all the situations, but this is probably the way to go.
See:
I believe that I have found the reason for the undesired behavior.
First, as soon as it becomes impossible to refret a note, the entire operation gives up. Instead, it should give up trying to refret notes on that chord, but continue to try to refret the rest of the notes in the selection.
Second, there is a sanity check that makes sure that the same string is not used for multiple notes in a chord. But it is being called immediately after moving every note instead of waiting until all notes in the chord are moved. So it is detecting and preventing collisions that never should have occurred in the first place.
Fortunately, both of these mistakes are easy to correct. See https://github.com/mattmcclinch/MuseScore/commit/39fe612.
Thanks mattmcclinch for looking into this issue.
I found an interesting thing recently using the mouse to move a group of selected chords instead of the CTRL+UP (and DOWN) buttons works as expected except for some software limits that seem to be off when you try to move past the HIGH E or LOW E strings. Even then it doesn't corrupt the score if you move the mouse cursor a bit in the opposite direction. I made a video, but evidently .MP4 files are not uploadable to this tracker. I haven't downloaded any of the code, but I think I read that was doable. Not sure what kind of hoops one has to go through to do so.
The manual for v3.6 addresses the use of this feature at the bottom of Page 118. It discusses using the
CTRL-UP and CTRL-DOWN keys which is known to have issues. The use of the MOUSE is not addressed but,
at this point, seems to work much better for this task and doesn't corrupt the score.
The attached video shows the mouse in action and that it, in this short test, does move the notes on the staff as one might expect.
Towards the end of the video, the issue that the mouse can attempt to move notes too far up (beyond the
High E string) as well as too far down (beyond the Low E string) is shown. After that sequence, it is
also shown that the notes have not been corrupted and can easily be moved back with the mouse. Possibly some limits in the software need to be adjusted.
You mean https://musescore.org/en/handbook/3/tablature#change-string-number ? Don't see how/where that discusses these keys to have issues
I agree the type of changes suggested here should address this case. But I seem to recall - perhaps incorrectly - that there is a reason these checks are as hard as they are, some case in which it needed to be this way. Any such discussion would have been the better part of 10 years ago and even if there was a reason then, it might not apply anymore. But it would be good to think this through a bit to be sure.
One word: please don't break anything. A regression can happen quickly... (this has already been seen alas)
I say it as I think: the Tablature section is completely abandoned or even neglected. In the sense that no developer for the last three years has supervised anything. And other suggestions, of higher priority in my opinion, remain unheeded since years.
Lacking an overall vision and a thorough knowledge of this part of the code, I'm afraid that patches here and there will end up causing unexpected effects. If I'm wrong, so much the better.
I share your concern about the possibility of regressions, hence my caution. And indeed, it's too bad no one with any real tablature expertise has stepped up to "own" this code. We have tried to fix the most serious issues as they come up, but no doubt, since few if any of the regular developers use tab much ourselves, it's hard for us to get a good sense of priority.
At this point it seems there may not be any more 3.x releases, although that could certainly change. Personally I'd still like to see a 3.6.3 in a month or so to catch the remaining 3.6.2 regressions and whatever other easy/safe fixes that exist, but I also know that each release takes resources away from MuseScore 4, and also, the more that goes into a release, the more chance of a regression that then necessitates another release.
So to me, what makes sense is to have a discussion on the forum about tablature in general, with three goals in mind:
1) identifying any really serious issues that still remain in tablature that would be candidates to fix in a 3.6.3 release should one happen
2) identifying and prioritizing remaining issues to try to fix for MuseScore 4
3) identifying any broad areas of improvement other than just bug fixes to be considered for MuseScore 4
In fact, for points 1 and 2, I don't know if we can speak of "urgent" issues to be solved. There have been a couple of serious regressions that have been fixed in versions 3.3 or 3.4 of memory. The problem of the dots not appearing in the tablature for printing is certainly annoying. #270551: [EPIC] Tablature issues
On the other hand, for point 3, suggestions, feature requests (so, for version 4), I can think of several things. Some of them appear in the EPIC, such as the possibility to switch automatically from the first to the last string (and vice versa), and the ability to display frets in bold, italics etc.
Others are filled in the Issue Tracker: like the possibility to hide one of the standard or TAB staves. The problem of displaying half notes - in "Full" staff type - is also recurrent (almost systematic confusion with the display of a tremolo).
Then, from memory, a few ones are not formally filled in the Issue Tracker, like the possibility to choose specific positions in the TAB (instead of systematically displaying the first position, e.g. the first open string, instead of the fifth fret, 2nd string) has also come back very frequently. Personally, I just wouldn't want the creation of a new dialog box, because with options added more and more, MuseScore will end up looking like it didn't want to be! At the very least, the default behavior should remain the same as it is now.
Finally, recently, requests have been made for improvements to the display of fingerings in the TAB staff. I probably have to forget a few others (eg I recall just now, some glitches with the beaming in historical tabs)
EDIT: Ah, and of course, the systematic duplication of elements such as lines and others in linked standard and TAB staves was discussed at length many years ago. In the end, nothing came of it. It is always a painful problem to deal with, however, and it is so still relevant today.
cwfly, If you analyze the "garbage" data, as you put it, I think you will find that it is not garbage at all. It may be an ergonomically unfeasible fretting of the chord, but it does produce the correct notes. This happens for essentially the same reason as I described above, though it follows a different code path. The notes are moved one at a time, and the collision avoidance routine is run at each step of the way. But in this case, if a fret is not found for a particular note on the next string up or down, the process continues for the rest of the notes in the selection, and this includes the rest of the notes in the same chord. This forces certain notes in the chord that cannot move in the indicated direction to move in the opposite direction in order to make room for the notes that were successfully moved in the desired direction. This is what you get for randomly dragging a selection of notes. If you want sensible results, then pay attention to what you are dragging, or else use the keyboard. Oh, wait, that doesn't always work. But my patch fixes that. Unless I haven't thought this through and my patch breaks everything.
No one is saying the patch breaks everything, just that it would be good to try to get a handle on what it was that caused people to think imposing these limitations was necessary and to be sure that that specific case isn't still an issue. Maybe I'm wrong in memory - it was a long time ago - but I do think it prudent to proceed with caution and take this possibility into consideration.
I've already done that. I have examined the git history and consulted the relevant issues that prompted the commits, and I think I have a handle on the situation.
mattmcclinch,
I didn't mean to affend you or anyone else by using the word "garbage". The issue is not the validity of the note (SPN is correct), it is the fact that you can't get back to where you were on the fretboard without manually moving specific notes back. I certainly didn't mean to affend mattmcclinch because he actually looked into the issue.
As I mentioned in a previous post (Feb 28, 2021 @ 14:55), selecting a group of notes (2 measures of stacked notes in a small test) and using the MOUSE to move all of the selected notes works good enough. I don't know why there is a difference between using CTRL+UP/DOWN and using the mouse, but there is a difference. There is the small issue at the limits (see Feb 28, 2021 @ 14:55), but it recovers nicely if you move the mouse a bit. On the Feb 28, 2021 @ 14:55 Post, I attached a short video (.GIF) that shows the mouse in action.
@cwfly,
You have not offended me. But you misunderstand. With my post regarding what you see as “garbage data”, I was addressing your concern about moving notes with the mouse. I encourage you to read what I wrote again with this in mind, because I was really trying to explain what is going on, and how the “issue at the limits”, as you put it, is not what you think.