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

• Apr 2, 2017 - 10:21
Reported version
S4 - Minor

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, and I've seen this question many times on guitar forums). So, solving this is quite wished/preferable.


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...

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.

Status PR created fixed

Fixed in branch 3.x, commit 0819633fb9

_fix #185056: hard to enter notes above/below staff + collect_artifacts


Currently, when you click to enter a note in note input mode,
and you click a location between two staves or systems,
we try to guess which you mean using a simple split point
located half way between the staves or systems.
This makes it hard to enter notes far above or below the staff,
because at some point we think you mean a different staff.
This comes up all the time for piano music and also guitar,
especially guitar+tab.

My fix here is simple, I prefer the current system and staff.
Current meaning, the one where the note input cursor is.
I let this staff take 75% of the stave above and below,
instead of only 50%.
Thus, clicking far above/below the current staff
will still enter notes onto that staff until you get much closer
to the adjacent staff.

The code is based on existing code that already does the same thing
when choosing which system (and hence measure) to use.
This code exists for things like dragging line handles.
One issue is that the existing code actually went all out
in preferring a system - claiming all of the space
up until the next system.
So I modified that existing code to take an additional parameter
to control the spacing factor for preferred staves,
defaulting to 1.0 so the exisitng use cases are unaffected
(and I checked the math carefully to be sure the effect is the same)._

Fix version