Inability to enter the last note E with the mouse in Guitar + Tablature template.

• Apr 2, 2017 - 10:21
Reported version
3.0
Type
Functional
Frequency
Few
Severity
S4 - Minor
Reproducibility
Always
Status
PR created
Regression
No
Workaround
Yes
Project

2.0.3 and currents 2.1 dev. /Windows 7

1) Guitar + Tablature template
2) With the mouse: enter the E2 (lowest note in guitar standard notation in an usual tuning, corresponding to the last open string in the Tab)

Result: failure

It works by some other manner (enter the E via the keyboard), or by workaround (enter F2 with the mouse, then arrow Down)

Or by increasing the distance between the staves.
It works eg in Style -> General -> Page -> Grand staff distance -> Increase the value to 7.5sp (instead of 6.5)

Maybe this setting should be by default in this template?

- Without being strictly as a bug, its effect is quite unexpected, and so considered, first, by mouse users as a bug (see, eg https://musescore.org/en/node/185051, and I've seen this question many times on guitar forums). So, solving this is quite wished/preferable.


Comments

A possible solution is to alter the algorithm that guesses which staff you are trying to click, so it gives wider space around standard staves compared to tab. After all, you don’t enter notes above or below tab staves, only directly on them. Another is to favor the current staff, only switching to another if you click directly it. Either of these would be fairly simple I suspect. Probably too late for 3.5 but could conceivably be in 3.5.1

True, but as far as I know it’s meaningless to click there.

Looking at the code, I think it’s better to just prefer the current staff And not special case tab. We already do that in at least one other place (when dragging lines, it seems), so I am looking at adapting that same code to use here.

I have it working as I described and will submit a PR shortly.

Here is what I am doing:

When deciding which staff to place a note on after the user clicks, we currently use a split point half way between the staves. So anything above that goes to the upper staff, anything below goes to the lower staff. I just added code to prefer the staff where the cursor actually is, so the split point above and below that staff is 80% of the way to the adjacent staff instead of only 50%. I think this works well, also will help for piano music (which is one reason I didn't want to tie this to tablature).

The only slight glitch is that there is a separate bit of code - this is the code I mentioned adapting - that decides which system you are aiming for. That is, in a guitar standard+tab score, if you are on the standard staff and you try to click high above the staff, that code is different. Right now it too defaults to 50% of the distance between the systems, so if you click too high, not only are you in the wrong staff, but the wrong system and hence wrong measure. I can take advantage of the existing code that knows how to prefer the current system, but if I do that, it actually goes all the way to the system above before it switches over - I can't easily make it stop at 80% (not without risking breaking something else). So I have to decide which is better: keeping that much as it is, or going with the 100%. Or try harder to get the 80% to work...

https://github.com/musescore/MuseScore/pull/6285

This version of the PR just lets the "prefer current system" prefer it all the way. So if you are currently entering notes on one system, then you want to enter something on the system above, you have to click all the way on a staff to get it there. This feels acceptable to me, it should be relatively less common to jump around in note input mode from system to system compared to jumping around from staff to staff within a system. So I felt it important not to prefer the current staff quite so strongly (I'm actually giving it 75% of the space above and below now).

A test build will be available and I'll post the link.

Sorry, I didn't see the Windows build yet. Tested and approved. So much better not to have to struggle with the program for something really basic: notes input! (one in particular, in this case)

Risk of an unforeseen disadvantage to this change. Not a big risk, and personally I’d be happy to take it, but we’re getting close enough to the final 3.5 release that we are being more conservative about what changes to merge. Others are being marked for 3.5.1, which we all know from past experience is inevitable a few weeks later. I did put in a vote for this to be included in 3.5 anyhow, but ultimately it’s not my decision.