Shortcuts not working for sub-beaming 16th and 32nd notes

• May 9, 2016 - 19:48
P2 - Medium
S4 - Minor

As verified in

The palette works just fine, but when a keyboard shortcut is set up for the sub-beaming of 16th and 32nd notes there is either no activity or some sort of improper behavior within a beam. This has also been verified by Marc Sabatella. I would imagine this to be a very simple fix in the code ;)

P.S. for Component I don't know whether Code or User interface is preferable for this particular situation. I'll stick with code.

GIT commit: 3c7a69d


FWIW, we've had only one report of this, so it just hasn't been enough of an issue in practice to make it a priority for anyone. Feel free to continue to see if anyone else on the forum will come here and say this miss this.

Personally I can't imagine ever using such a shortcut. The default is normally fine for me, and in the rare situations where it isn't, it generally isn't score-wide, so I'd change it in the time signature properties, not just for one beam via shortcut.

In reply to by Marc Sabatella

Understandable that not many people have got to that point of customization where they'd be desirous to utilize the sub-beaming keyboard shortcuts available for that particular kind of workflow. Yet, if it isn't going to be updated, why have the option appear in the shortcut section like a loose-appendage which does nothing? Maybe in the mean-time it'd be better to remove it from the list than to have it appear as if functional when in actuality it is merely nothing and may cause confusion to the one who attempts to utilize what appears to be available?

Don't get me wrong - it's a bug to be sure, and better to fix it than remove the option. Probably just as easy, too. But there have been hundreds of bugs fixed since this was submitted and that took time. It's just a question of priorities, and we take that process seriously. Some really great improvements have happened in the last few months that have really made a difference for thousands of musicians, and I'm sure they are grateful we chose to prioritize that work as highly as we did. I don't think any of the work I have done this year was a less worthy use of my time than fixing this particualr bug would have been, and I suspect other developers would say the same.

So, as with any other bug, I expect this will get dealt with in due course, after more pressing issues have been addressed.

That's great! If you click "Contribute" above, then "Development", you'll see the "Git Workflow" and "Deverlopdocument and other resources that explain the process. Basically, assuming you created a fork on GitHub and cloned that to your local machine, you create a branch for your work, commit it, then go to GitHub and submit a pull request.

In reply to by njvdberg

Glad you took the challenge! Maybe we can get lucky and have the code implemented in 3.3 before it goes out of beta period? Anatoly-os is quoted to have said for September 1-18:

"Beta release testing period. Only fixes and small improvements will be included in the release." This could be considered a 'small improvement', so maybe it can be implemented if verified to be solid/bug-free.

Fix version