Space bar shortcut does not work when play panel window is in foreground

• Oct 6, 2014 - 18:41
Type
Functional
Severity
3
Status
closed
Project

The label on the play button on the play panel says "Start or stop playback (Space)". However, nothing happens when the Space Bar is pressed when the Play Panel was the last window to have been clicked on. The bug is that the (Space) hint is incorrect since it does not work. Rather than removing the (Space) hint, a much more useful fix would be to honor the Space Bar event when the Play Panel is the active window.


Comments

Severity

I should have noted that this is a MuseScore 2.0 Beta 1 bug. I went back to 1.3 and found that it does work there.

Title Space bar shortcut does not work when play pannel is forground window Space bar shortcut does not work when play panel window is in foreground
Severity

The spacebar is supposed to work only when the score has focus. Since it's being used by most controllers (check boxes, buttons, etc.) it can't be set as a global shortcut, so it won't work in any other window, being it play panel, mixer, master palette, etc. However, I do hesitate to close this issue and mark it by design, because it does indeed apear as a hint in the play panel window.

I've used many digital audio workstations, most of them had a mixer window but none of them would take priority away from the playback shortcuts.

FWIW, thinking of MuseScore as akin to DAW software is likely to get you into a lot of trouble with respect to expectations. MuseScore is a notation program - for producing printed notation - that just happens to have some playback functions. In that sense it's more like a word processor or a desktop publishing program that happens to have a "read aloud" mode. This is bound to lead to some differences in expectations.

In particular, the space bar is the universal standard way to activate checkboxes with the keyboard. So space really can't be made available for other purposes in windows that contain checkboxes. Not without seriously inconveniencing people trying to control MuseScore by keyboard alone - for instance, blind users - and we're really trying hard to make MuseScore as accessible as possible.

lasconic: not sure if there are other substitutes that are likely to be well-known

@Marc: Thank you for making things more clear.
@lasconic: Yes. Natively from Qt QCheckBoxes, QToolButtons and other controlls, except maybe a few that allow Return/Enter use the Space key.

The spacebar does work when the Play Panel has focus in 1.3. It may not be immediately obvious how it got broken but I certainly do not think that it is appropriate to to declare that a feature that worked and was documented by a hint in the play panel window is one that was not designed in.

My primary focus with MuseScore is producing MuseScore files for use as practice aids. I provide these scores to around 80 chorus members who are distinctly not technical. (They are told to use 1.3) I also use the practice aids I produce. 2.0 has features that make me use 2.0 rather than 1.3 for my own practice. However I find it a repeated annoyance that the space bar doesn't work because I forgot to click on the score after having adjusted the tempo or master volume.

If you officially release 2.0 with this feature not working, members of the user community will see it as breaking a feature that was working in the version they had been using. For this reason, I believe that the priority should be set to Normal rather than Minor. However, I am just a user, not a developer so I feel that I should defer in this decision to people who have done a great job in making an excellent program.

Severity

I'm going to try and make everyone happy. If I find a good way to do that... well, everybody will be happy. :) If not, unfortunatelly I'm going to remove the hint, because while it's true that a lot of users are used to space being a global shortcut and it's an inconvinience to click everytime in the score, I think that it's a much bigger inconvinience for blind users if we move back the Space global, because in that scenario they won't be able to use a lot of controlers.

Severity

I don't see the use of the space bar as a method of causing a check mark as incompatible with the use of the space bar to cause play/stop when the play panel is in the foreground. The space bar certainly should not work universally to cause playing. It would be very annoying to have the space bar cause the score to be played while editing a musical attribute. However, having the play panel in the foreground means that the user is actively wanting to control play, not edit an attribute of the score.

The only other auxiliary window I use when I am practicing my music is the Mixer. It would be nice to have the space bar work there too so that you could easily hear the effect of a set of mixer adjustments. It does not currently work in 1.3 so that would be a new feature.

We are not talking about editing score attributes - we are talking about activating the controls *within the play panel* Also the mixer. The play panel does not happen to contain checkboxes right now, but it contains other controls (eg, the loop controls) that are basically checkboxes in disguise. And the mixer contains actual checkboxes. The space bar is how a user would activate those controls within the play panel via keyboard.

It's a bit unfortunate, and maybe we could consider using a different shortcut for toggling these checboxes and somehow communicate this to users, but we could just as easily ask users who wish to do playback within one of these two windows to use a different shortcut.

I hadn't realized that if I place the focus on a Mute or Solo button in the Mixer panel, I could use the space bar to toggle their action. I withdraw my request to have the space bar start and stop playing when the Mixer is the focused panel.

The problem is the need for consistency between the main (score) window and the play panel window. In the main window, the space bar controls playing. Therefore, for consistency, it should do the same in the play panel. This is currently the case with the loop controls. Shift-I marks the start of a loop section, Shift-O marks the end, and shift-L toggles looping in both the main and play windows.

It would take some re-learning by people who use MuseScore 1.2 to play scores if you switched from space bar to enter in both the main and play windows. However, it would at least preserve consistency so you would not need to be aware which window is currently in focus. (Could you assign Enter as the new shortcut in both windows but retain space as a deprecated shortcut to ease the transition?) It is very important that the play/stop shortcut be a very easily accessed key. This is because for using MuseScore to practice, you typically have your eyes and hands on the actual paper score while you are playing the music.

My understanding of the problem is that there is a conflict between two pre-existing capabilities of MuseScore. One is its ability ability to be operated by keyboard only. The other is its ability to start and stop playback using the same keyboard action within the both the Score window and the Play panel. The problem was introduced when checkbox-like objects were added to the Play panel. This is because the standard way to operate checkbox objects is with the spacebar.

A possible solution would be to define dedicated keyboard actions for each of the ckeckbox-like objects on the play panel. If keyboard actions were defined for these objects, there would be no need to use a generic spacebar event to activate them. Three of the new objects: Set loop In position, Set loop Out position, and enable Loop already have dedicated keyboard actions. The remaining ckeckbox-like objects are Play, Rewind, Count-in, and Metronome. The dedicated keyboard actions for Play and Rewind are obvious: spacebar and home. This would put these actions in alignment with those defined for the Score window. This leaves only Count-in and Metronome without dedicated keyboard actions. These actions only need to be local to the Play panel so Shift+C and Shift+M are possibilities.