Easy fingering input mode

You can already use Ctrl+Alt+Shift+Left/Right to move the cursor (since plain Left/Right moves the fingering itself), so that's at least soemwhat helpful. In 3.0, Alt+Left/Right is also available.

Hi Marc, I just installed the 3.0 beta and am testing fingering input (macOS 10.14). When inputting fingering, alt + left or right arrows (I hesitate to write "alt right"!) doesn't seem to do anything. If I'm doing something wrong, could anyone offer instructions for moving the cursor to the next note in a voice while entering fingerings?

A fingering input mode would be a godsend. Dorico just added this in its latest update, and since I add fingerings to nearly all notes in my scores for students, it may be worth switching for this feature alone, although I like the simplicity of MuseScore much better. Hopefully 3.0 will simplify adding fingerings. All we really need is a way to move the cursor to the next note or chord (or perhaps note within a chord) while eliminating as many keystrokes as possible.

Maybe you are not hitting Esc to complete entry of one fingering before moving on? These navigation shortcuts only work when not in text edit mode. Although if someone files an official suggestion for them to work in text edit mode, that's probably possible, and would save a keystroke.

Yes, I had tried hitting esc first. On macOS, it looks like you can just press the right or left arrow keys. 3.0 beta is now much easier than 2.x, though keystrokes can still be reduced. Currently, it seems you need to enter a fingering, then type esc, then the right arrow twice to move to the next note, then enter fingering mode again.

I set up a shortcut (ctrl-F) to enter fingering on my system. This means that I still need 5 keystrokes to get from entering fingering for 1 note to entering fingering for the next note. If a proper fingering mode is implemented, this can be reduced to a single keystroke. While I don't know the details of what's going on behind the scenes, I imagine it shouldn't be too difficult. Perhaps hitting, say, the tab key while in text input mode for fingering could act as a macro for all of the above keystrokes? Maybe more experienced users will have better suggestions.

Probably on Mac Alt maps to something else (Option?). In any case, you customize that shortcut too, [ and ] are probably available).

I tried all possible modifier keys: ctrl, option/alt, cmd, shift, along with the left and right arrow keys. cmd-right moves the cursor to the next measure; the others do nothing on macOS.

Could I bother you to describe step by step which keystrokes you use to move the cursor to the next note when adding fingerings? (Are you on Windows or Linux?) Then we Mac users can at least know the expected behavior. Many thanks in advance.

I'm on Windows. For me, if I define a shortcut to add finger (right now I have Ctrl+Alt+F), then the following works

1) click note
2) Ctrl+Alt+F (enters fingering edit mode)
3) type fingering
4) Esc (leaves edit mode)
5) Alt+Right (moves cursor to next note)
6) Ctrl+Alt+F (enters fingering edit mode)
7) etc.

Did you try customizing the Alt+Right shortcut? The command is called "Accessibility: Next element"

Good to know, but how easier it would be to be able to just press space bar between fingering as we can between chord for example.

Thanks. That explains it: I needed to add keyboard shortcuts for next and previous elements. I used just the left and right arrow keys for these shortcuts and they worked fine on macOS.

I also agree that hitting the spacebar would be much easier still and save many keystrokes. In the meantime, these shortcuts will still save a lot of time.

Sure, a new fingering mode would be nice someday, but that's a lot more work. That's why this suggestion is still open :-)

Hi Marc,
Reading more carefully your suggestion, it appears to me that if Alt+Right (or Alt+Left) was accepted in fingering input mode and would move you to the next note still in fingering mode everyone would be happy.
As this "just" means that Alt+Right should be accepted by MuseScore in fingering mode and would apply a combination of existing behaviour (leave fingering, move cursor, enter fingering again) would it be possible that it is easier to program than one thought until now?
Fred

It's possible, yes. In theory, part of that is very simple: extend next-element to also work in text edit mode, and to have it force an endEdit if you current element is text. I think that's probably worth doing no matter what. The second part sounds simple but not sure what complications would come up: if current element is fingering and current mode is text edit, then finish command by also issues the fingering command. Bonus points if we notice the current text style and apply that to the new fingering as well, so it works for all fingering types. Not quite sure how well the command-within-a-command would fly, but it's conceivable it would work easily too.

This approach, if it worked at all, would only "mostly" work, though, sicne there is no guarantee "next element" is a note and not a rest or articulation or something else.

FWIW, I went ahead and implemented this, works pretty well, also works for staff text et al too. I made it so it skips to the next note, and also made it so the same shortcut (Alt+Left/Right) works for chord symbols and figured bass too (it already does for lyrics). So, enter one text element (whether fingering or something else), then while in edit mode, hit Alt+Right, and edit mode is terminated, cursor moves to next note, then a new text element of the same type is created and you are in edit mode for that.

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

Marc, this is great news—thanks! I downloaded the latest nightly build for Mac but this feature doesn't seem to be working. I guess it has yet to make its way to the nightly builds, or is there anything special I need to do to get it working on macOS?

Also, if such a feature hasn't yet been implemented, I can imagine alt+up and alt+down arrows moving to the next higher or lower notes of a chord.

Wonderful, Marc, thanks a lot! Will be really really useful.

@key-notes Marc's changes have not been merged yet. When that happens, this issue will be marked as fixed.

No need for Alt+Up/Down - the existing Alt+Left/Right commands already move through the notes of a chord, as well as through mult8e voices. That's the whole basis of what I did - leveraging the existing Alt+Left/Right behavior but adding code to automatically pop you out and back into edit mode. That's what enabled me to knock this out in a few hours. No guarantees it will get merged, but another advantage of my approach is that it is very low impact - only these commands are affected and only while editing text.

I have updated the PR so that now Space and Shift+Space work as well, for fingering only. Windows users can test this and give feedback by downloading the build generated as part of the PR: https://ci.appveyor.com/api/buildjobs/b8kqem185vf56de5/artifacts/MuseSc…

Meanwhile, here is a GIF showing my PR in action. In this example, I am using guitar LH fingering, but the same applies to all the fingering styles: enter one normally using the palette, menu, or customized shortcut, then while in text edit mode (double-click the fingering to get there if you didn't use the shortcut), hit Space to move to the next note, type another fingering, Space, type another fingering, Space, etc. It's as quick and easy as it is for lyrics.

As I said, it's not guaranteed this will be merged, but I do think my adding support for Space / Shift+Space will less the likelihood of it being rejected.

I understand there is currently an issue with how the "next note" command works in the presence of multiple voices - see #282091: Fingerings disturb navigation with accessibility shortcuts in multi-voices context. That's not a result of this PR, but it will hinder the usefulness of the fingering mode that other bug is fixed.

I tried. With Space for navigation, it's easiest and "natural", no doubt. But how I do that (image below)?
With two voices (from beat 3), I fail: for the F voice 1, the fingering jumps above the notehead, and ignores the B voice2 and so on.

And other thing: when I enter the "initial" fingering, eg 1 (piano) or 1 (LH), the 1 goes in the same way to the left of the notehead.

Right, as I said, there is a known issue - reported by you :-) - unrelated to this PR involving navigation with multiple voices and fingering. So it will be good to get that bug fixed. It's a good idea anyhow, but becomes especially import when this PR is merged.

As for the layout, my PR for layout improvements is totally separate from this one. So, the build for the layout improvements does not contain the fingering mode changes, and the build for the fingering mode does not include the layout improvement changes. That's the nature of how the automatic builds for PR's work - each builds against a base of only what has already been merged. When both PR's are actually merged, then you will be able to test both changes together, in a nightly build.

Understood now (I hope). Also: how I do for adding RH fingerings? Currently, the RH fingering also comes to the left to the notehead?

<< I have updated the PR so that now Space and Shift+Space work as well >>
Thanks a lot for that Marc. That will be very very useful.

I thought I responded to the comment about RH fingerings but maybe I forgot to hit Save? Anyhow, again, this PR does not include my layout improvements - each PR is separate. So each build contains only the fixes relevant to that issues. Meaning, yes, this build will continue to show RH fingering the exact same way that it does in the "master" builds - which is, above the note for single notes, to the left for chords.

As for how to do it, it's exactly the same as for LH - first entering the fingering any way you like, then while in text edit mode, hit Space. It moves to the next note and adds another fingering of the same kind you started with. So if you start with LH fingering, you will keep entering LH fingerings. If you start with RH fingering, you will keep entering RH fingerings. If you start with a staff text, you will keep entering staff texts. So it's not just a fingering mode, it's an any-kind-of-text-you-start-with mode (well, as long as it's a plain text element, iI didn't also implement this for dynamics or other texts that work differently).

Fixed in branch master, commit 04aefc9407

fix #278175: add fingering mode (also works for staff text)

Fixed in branch master, commit c33ac31c6e

_Merge pull request #4521 from MarcSabatella/278175-fingering-mode

fix #278175: add fingering mode (also works for staff text)_

Thanks so much Marc for this work. Without any comparison, this way to input fingerings is incredibly faster, and easier (and less painful for your hand - and your mind! - if you're used to input a lot of fingerings in your scores).

It's the first time in the "history" of the program's development that double-clicks are no longer necessary (I leave aside the old drag and drop) to enter fingerings. To be marked with a white stone!

From now, it's a pity that the navigation issue is not resolved, ie #282091: Fingerings disturb navigation with accessibility shortcuts in multi-voices context You can input fingerings in the other voices, but it's just unexpected and, to be honest, a bit/very strange to have to go backwards to enter fingerings.

After some tries, probably it is easier - otherwise you can mix the brushes possibly in the round trips - to do all of voice 1 first (using only the Space bar), then go back for the other voices, with only Shift + Space - but having to go back, alas, through notes in voice 1.
As if we had to enter lyrics starting at the end of the verse :)

But well, for now, the qualitative leap is so important that we can tinker a bit more, waiting for the fix. Thanks again.

You're welcome, I'm glad we found an easy solution! Too bad indeed about the navigation glitch with multiple voices but hopefully that can be fixed soon too.

<< Thanks so much Mark for this work. >>
+1

.

Automatically closed -- issue fixed for 2 weeks with no activity.

Oh my goodness, thank you SOOO so much Marc!
This feature was the reason I had to switch back to Sibelius - I stumbled across this article and I will start using Musescore again!
Thank you for all you do!