Preliminary MuseScore 4 Accessibility Tutorials

• Aug 11, 2022 - 23:35

I've created some basic tutorials to help blind users get up and running with current (alpha 2) builds of MuseScore 4. There are some bugs I show here, as well as how to work around them - hopefully we'll get them fixed before the real release. So far, I've made four (originally I posted three, but there was a glitch in the audio in one, so Ive replaced and also split it into two).

The first video is to help with basic setup of the program, since it's a brand new sequence and is unfortunately probably the least accessible thing there is, so you definitely will want my play-by-play:

https://youtu.be/RmLCdv9duVc

Next, a tutorial on how to create a new score. Here, it turns out that NVDA has some limitations compared to Narrator or Orca (I don't have a Mac to test with VoiceOver, and my JAWS license ran out some time ago), but I skip over the things that don't work with NVDA and show how to work around that:

https://youtu.be/5HSNGG3zzLo

Next, a video that gives a tour of the rest of the main window interface - the various toolbars and panels you will use:

https://youtu.be/g_mWzndxxzg

Finally, a tutorial to get you started on entering music into the newly created score:

https://youtu.be/8HSy6Ml2h60

This doesn't even come close to showing you how to do everything there is to do with MuseScore. but it should allow you to get started, and if you're already familiar with MuseScore 3, really, most of the rest is pretty much the same.


Comments

The video tutorials are REALLY GOOD! After using them I find:

1 When setting up a score, I can't change the key-signature or time-signature, or the Anacrusis information, or the number of bars in the score.

I also find when in the score that the f9 paletes key doesn't take me to them as it did in 3.6. Am I missing something?

In reply to by rogerfrdhm

Thanks for the comments!

Yes, you'll notice in my tutorial on setting up the score, I skipped past the key and time signature section of the wizard, because they don't seem to work with NVDA, although they do with Narrator. So right now it isn't obvious what the problem is here, but I have filed a bug report already. Meanwhile, the workaround is to do as I do in the tutorial - skip over these settings in the wizard, and know that you can take care of all of this after setting up the score.

F9 opens and closes the palette but does not immediately move the focus to the search box like it used to. Instead, use the command specifically design for palette search - Ctrl+F9. This has the advantage of always going directly to the search box, whether the palette is currently open or closed. In 3.6, pressing F9 while the palette was open would close the palette, so you'd have to press F9 twice to do the search. So really, Ctrl+F9 is the best way to reach the palettes in both versions - it's always just single command instead of sometimes needing to press once, sometimes needing to press twice.

EDIT: actually, it seems Ctrl+F9 does not work if the palette is not already open in MuseScore 4, so if you previously closed it with F9, you'll still need to press F9 again to reopen it. That's not good, so I've filed a bug about that.

Thanks for the reminder about numlock! I think different keyboards work differently i that regard - none of mine have a numeric keypad built in, so there is no numlock key, and other keyboards have a permanent numeric keyboard with no numlock. So we'll definitely want to be sure we understand how to describe this best for all users.

In reply to by Marc Sabatella

This is probably a dum question. I've installed the first Alpha version. Where do I go to get the Alpha 2 version. Do I have to delete Alpha 1 first before installing Alpha 2? And the same question applies when updated versions come along. I apologize for not being very good at computery things.

In reply to by Marc Sabatella

Braille displays.

I use a Hims Polaris 6 braille display along with NVDA speech output for everything I do with a computer. In version 3.6 of Musescore, everything that appeared on the screen and everything I typed, also appeared on the braille display, so it was easy to check what was happening.

In version 4 alpha, when I input title composer etc, key-signature, time-signature etc, absolutely nothing appears on the display. If you type in to an edit box, the information is visually present on the screen, but nothing whatsoever appears under the fingers on a braille display. Could this have something to do with the keyboard disconnect with regard to the numpad keystrokes as well? I know no the answer; I just ask the question, for the two would appear to be related, and as I say, there was never any problem of disconnect in Version 3.6.

In reply to by rogerfrdhm

Thanks for the report! I will pass it along.

Actually, it's a little curious to me - some screen readers read everything about the note (it's pitch, duration, beat, etc) when you enter the notes via keyboard, but NVDA doesn't. For the screen readers that read everything when you enter the note (Orca, at least), it also works when pressing R.

But let me be sure I understand. You aren't hearing notes being read as you enter them with the keyboard, right? I assume you just hear the key you pressed being read, both in MuseScore 3 and MsueScore 4. At least that's how NVDA works for me. So even if the key signature contains E flat, if you press "E", NVDA simply reads "E", not "E flat", and the only way you know an E flat has been entered is that you hear the note played when you enter it. Correct?

I wonder if we should make NVDA and other screen readers do what Orca does and fully read each note as you enter it.

As it is, though, NVDA normally doesn't read anything, but MsueScore 3 did at least play the pitch of the note when using R to repeat, and now it doesn't. So it's not an issue with anything having to do with the screen reader as far as I can, more just about how the "R" commands works with playback. Still, I'm reporting the issue to GitHub.

In reply to by rogerfrdhm

It's just that with NVDA the R command doesn't repeat the sounding note, as it did in Musescore 3. I think it a good idea that any screenreader reports as accurately as possible what is happening on the screen. To that end, If there's an E flat, it should say so. Ironically, personally for me, since I am blessed with perfect pitch, I don't actually need the information anyway; but other people will.

On another matter, I'd never heard of Orca until this alpha release. What's it used for, and where do I get it, for perhaps if I'm testing things for blind people, as I am trying to do, I should know about it.

In reply to by rogerfrdhm

Right, so you're not necessarily R to read the note, just to play it. I've filed that as an issue. I do think it would also be useful if more screen readers would read the full info for each note as you enter it, but it would also be good to hear from people who actually rely on this. Maybe that would be annoying to a lot of people. A lot of refine that we've done over the years has been to read less information when people told us the amount we were reading was too much.

Orca is the main Linux screen reader, and MuseScore started supporting it along with JAWS for Windows a few years ago. To get Orca, you start by having a system with Linux instead of Windows, then you install Orca from using whatever controls your particular Linux system offers. Each is different. But that is a whole other can of works, and I'm guessing you're not really wanting to enter the world of Linux.

Anyhow, for MuseScore 3, we support NVDA, JAWS, and Orca. For MuseScore 4, we support those plus Narrator and VoiceOver.

In reply to by rogerfrdhm

No, nothing has changed there. When you start up, you're in normal mode. "N" toggles you between that and note input mode. Specifically, step-time mode; there are actually other note input modes as well you can access from the toolbar. This is the same between MuseScore 3 and MuseScore 4.

By the way, I found after restarting my computer, suddenly NVDA started reading the notes as I entered them again - both in MuseScore 3 and MuseScore 4. So, whether I type "C" or type "R", after entering the note, the full information about the note is read. Somehow that had stopped working, maybe when I was trying to also run Narrator? Or maybe it was a problem caused by switching between MuseScore 3 and MuseScore 4? Anyhow, MuseScore is supposed to read the note to you after entering it, and for me, now it does, even though it temporarily stopped in both MuseScore 3 and MuseScore 4 earlier this week.

In reply to by rogerfrdhm

The problem with the R command was for me that it didn't Sound the note. There's no need for information about the note, since it's already been input, and one presumes the user knows what has been input. It was rather that in Musescore three, after pressing the R key, the note plays as a repeat as it should, but in Musescore 4 it didn't play or give any information. All you need is a Repeat Sound.

In reply to by rogerfrdhm

Right and as I said, I can reproduce that and have reported it in the issue tracker.

But MuseScore is supposed to be reading every note as you enter it, both in 3 and 4. It’s just that sometimes this gets “stuck” - in both versions - and stops working for some reason. Since it happens in both versions, I suspect it’s more of an NVDA bug than a MuseScore one.

In reply to by Jojo-Schmitz

"Normal" is the name for the mode you are in when not in note input mode. "Step-time" is a specific sub-mode of note input mode, the one that's enabled by default when you press "N". So it's the "normal Note Input mode" in the generic sense of the word "normal" - of all the note input sub-modes, it's the one we usually mean - but it's not "Normal mode" with a capital "N", which is more or less the opposite of note input mode.

In reply to by Jojo-Schmitz

Normal mode, as I understand it, means it is easier to edit information. Ties, for example, work differently than in Note input mode. But, I have to say, I'm not really sure Why it is thought good to have two input modes; and it would be simpler just to have one, since one can alter information quite as easily in one as in the other. I fond myself Normal mode, which it would be better to be called Edit mode, is more useful.

In reply to by rogerfrdhm

The basic difference is that in normal mode, simply clicking with the mouse doesn't enter new notes - it does other things like select or move things. If not for that, it would probably be possible to merge the two modes. And perhaps someday a way will be found to do that even for mouse users.

But for now, normal mode is what you should be in when not entering notes, and note input mode - as the name suggests - is the way to enter notes. So don't think of normal mode as an "input" mode at all - it's more of a "navigation and editing" mode.

Again, to be clear: none of this has changed between MuseScore 3 and 4 (or for that matter, between 2 and 3, or 1 & 2) - this distinction has been baked in from the beginning.

In reply to by rogerfrdhm

Another bug.

When using Narrator, and inputting notes, if you alter a note with the up arrow, more often than not, you are dumpted out of the program altogether, a bit like what used to happen with the Palegges menu in version three, before 3.3 The program seems to be highly instable. I have not experienced the same result when using NVDA.I think.

In reply to by rogerfrdhm

Thanks for the reprot! Yes, sometimes I see crashes with the arrow keys also, but I'm not sure it's only with Narrator, because I almost never use that, and I see crashes more often than that. So far I haven't figured out the pattern though. If you do figure out exactly how to reproduce the problem reliably, let us know!

And yes like all experimental "alpha" pre-releases, you can expect crashes and other bugs. It's a lot more stable than the alpha of MuseScore 3 was, actually, but still, plenty left to fix before the actual release. Just keep the reports coming!

In reply to by rogerfrdhm

Findings.

1 When inputting notes for the first time When you press N, you go straight to bar 1, which is fair enough, except it isn't clear whether in input or normal mode. It's a shame the Normal" mode isn't called Edit mode, since that is what it is, and what would ABNORMAL mode be anyway! Musescore defaults to Normal mode, so it should say so. But if you tab through the toolbars to Note input toolbar panel, it reports Steptime by default. It is unclear to me how the change has been made, or how one changes the note input setting. Pressing spacebar, though it tells you is a toggle, doesn't toggle or change anything.

2 If you press f9, the Palettes key, there is no report as to whether the Palette is open or not. Nothing is spoken. Pressing Tab will get you to "add" palettes button, so one is to assume they have been opened. And when you select, for example, the Tempo Palette with the spacebar, it still says, Not selected. The only clue is that it says Expanded, not selected. And ironically, the only way you can select is if you Collapse it with the right arrow. Then, you can down arrow past the notation value choices to the tempo word choices. Selecting one of these with the spacebar adds the selected tempo mark to the score. It's rather a strange way of doing things.

In reply to by rogerfrdhm

  1. Yes, I agree it's unfortunate that the current mode is not read when switch. I'm reporting to our issue tracker now. Originally it didn't read in MsueScore 3 either, but this feature was added recently and apparently didn't make it into MuseScore 4 yet. For the record though - Edit mode is something very different from normal mode. it's true that some editing operations can be done in normal mode. others, though, require edit mode - which is designed for making manual adjustments to the size or shape of things. Also for editing text. We do plan to revisit how this works in a future release.

  2. As I mentioned earlier, you probably should not be using F9 - not in either MuseScore 3 or 4 - because you don't really need to ever close the palette. Instead, leave the palettes open always, and use Ctrl+F9 to get there, which takes you directly to the search box. But anyhow, I agree the way the palettes expand and how you need to do this before navigating within them is awkward. I'm reporting this to our issue tracker as well.

It's important to remember when using Musescore with NVDA, [I can't speak for any other screen reader], that before doing anything at all like entering notes, you turn on the Numlock key. This is because it will then report, quarters for num 5, eights for num 4, etc. Otherwise, it will just report, 5, 4, etc. You'll also find that after a few bars, you will begin to enter rubbish in to the score. I don't know what's going on; all I know is that if you remember to turn on numlock, you avoid the above outlined problems. I think this piece of information should be added to the accessibility manual, when it is written.

Findings.

1 When inputting Title, Composer etc, whether using NVDA or Narrator, the edit boxes are not read out, so you can't check if you have made a typo.

2 Key-signatures.
Using Narrator, you can read up to B Major, but not keys of F sharp and C sharp major. And using NVDA, as already mentioned, it won't read them at all! And similarly with flats, you can get up to about four of them, but no more using Narrator.

3

Note input.

Whether the numlock is on or off appears to be irrelevant. In note input mode, using the numpad, I can only input crochets, and no other note values. If I use the number keys, I can input some basic notation, but not dotted notes, or rests, or ties.

It does seem a great pity that when all worked so well in terms of the above basics in 3.6, it is now all spoilt. And for what? Let's hope it's fixed soon.

In reply to by rogerfrdhm

Yes, this is covered in the tutorial. Those boxes work with some screen readers (like Narrator) but for reasons we don't yet understand, not with NVDA. But this has been reported and will be investigated and hopefully fixed. BTW, thanks for reminding us about the issue with F sharp and C sharp. It actually is reading the key, but not the sharp - so when you hear it read F major" coming after "B major", know that this is really F sharp. Unfortunately different screen readers handle these special characters differently. We're working on a fix for that also.

I explained elsewhere that there are currently problems with numeric keypads on some systems, those are being investigated. Meanwhile, though, the standard number keys should work fine; nothing has changed with respect to that. Can you explain what you mean about not being able to enter dotted notes? The process should be the same as always - type "5 . C" (five dot C) to enter a dotted quarter note C. Simialrly, to enter a tied note, select the duration then press the shortcut for the tie command. Currently this is still "+", although there is talk of changing this, since other programs use + for sharp and that does make sense.

Anyhow, don't judge MuseScore 4 by an alpha test pre-release. MsueScore 3 was far far far worse in its alpha release, but thanks to people finding and reporting bugs, we got it into excellent shape! That's the whole reason to have these alpha releases - to find issues and fix them before the release. So, thanks for helping report what you find!

In reply to by rogerfrdhm

BTW, when you ask "and for what?", that is definitely worth discussing as well!

The whole reason for all these changes is to make MuseScore easier to use - arranging the windows and buttons more logically, making the shortcuts logical and matching the expectations of new users who are more used to other programs than they are to older versions of MuseScore. And also to make it more accessible in general - making more commands and windows accessible by keyboard, improving the screen reader descriptions of many items, grouping controls so you can move through the interface more efficiently with Tab and F6, and most importantly, making it work on the screen readers that come with Windows and macOS (Narrator and VoiceOver), which has never been possible before.

These are huge improvements, but they require big changes, and along the way, it is expect t some things might break. That's why these pre-releases exist - to help us find the problems we didn't find already while introducing all these improvements.

So, please stick with us, and I think you'll find that as these problems are ironed out, you'll start discovering and being amazed by what is possible that was never possible before!

In reply to by Marc Sabatella

ello. I am from Poland. I am blind. NVDA. I've only been using this program for a month. Version 3. I am delighted with the availability. There are over 400 keyboard shortcuts to choose from. Not all of them are programmed, but each user can set the necessary hotkeys himself. I'm having trouble choosing a tone. Now I don't. After opening the score, I press the keyboard shortcut shift + k and I have access to all keys. It's wonderful. These shortcuts are selected in Edit/Properties. This is the quickest way to get to the different options you need. Thank you.

Dear Marc!
Very very remarkable is the muse score 4. I increasingly feel that I have to take this program seriously.
I have been blind since birth, so I use a computer with a screen reader.
Music is the center of my life.
I'm basically using an NVDA screen reader, but I find the narrator works better.
There are good results with Jawsz, but I am also sure that there is still room for improvement in accessibility.
Question: now, the 4th
after the release of the main version, is the commitment of the creators to improve accessibility still there?
I think primarily of palettes and articulations, they are not really blind friends.
Secondly, the muse sound installer cannot be said to be such.
I would like to emphasize once again that muse score 4 is very, very remarkable for me, especially because of the orchestral library.
How is it possible to enter tremolo with a screen reader?
Of course, I offer all my help to
to test for future accessibility, because if the program evolves in this way, it can become an essential application for me when it comes to composing.

By the way, I'm using a Reaper now, but I really need an ideal sheet music editor for the blind with excellent sounds. Muse score 4 might be like this, but I would be interested to know how committed the creators really are to accessibility, as many other companies that make similar apps like Steinberg (dorico) at all
it's not.
I find Sibelius expensive, and with the muse sound library, muse score can really be a worthy competitor.
I would very much like to hope that the creators of muse score will be even more committed to the accessibility of the program, and this will not lag behind over time, as with other companies.
A basic error is that when I select groups of instruments, for example, templates, the screen reader does not inform me if I have actually selected them. the usability of palettes is also questionable, this should be corrected as soon as possible
I need it.
I can't find a way to adjust the volume either with a screen reader or the mixer is a bit confusing.
I look forward to your response.

In reply to by Viktor Erdődy

Thanks for your comments!

I'm not sure what you mean when you say you are selecting groups of instruments. Where are you selecting them? You mentioned template, so I guess you mean in the instrument definition dialog, but you cannot select groups of instruments at all there. You can add instruments and remove them, but this is done one instrument at a time, and MuseScore does provide feedback on that. It's possible you are missing that there are three columns of information there, and it's the last column that lists the instruments you have actually added to your score. This is proving to be easy for people to miss and is causing some confusion, but once you reach that third column, you will find you do find what instruments you have added.

Also it isn't clear what problem you are having with the palette. It definitely works by keyboard and screenreader, and it's even reasonable efficient when you use the palette search facility. if you're having a problem, feel free to explain in more detail.

The mixer is indeed still a bit awkward (although it's considerably better than MuseScore 3 was). To adjust volume, you'll want to navigate to the slider for the volume then use left/right to move it. NVDA doesn't read the values but Narrator does.

And yes, as problems are reported, there is still a commitment to fixing them, and to making further improvements!

Dear Marc!
first of all, thank you very much for the detailed and exhaustive answers to my questions.

Yes, the palettes are really very nicely available, as you described in detail.
I listened to your videos, which clarify the basic questions about the program and help you get started. I think it's very valuable, but I have one or two questions.
How can I modify the reservation afterwards if I decide not to enter it directly when creating the sheet music. Often
sometimes I decide later on what tone a piece should be in.
I can now easily insert a tempo marker using alt-shift-T, this turns out to be very useful.
I was just starting to study the possibilities of actually typing notes, and I realized a lot. Mostly to the fact that basically the program handles notes in overwrite mode. I understood that I would give the time first, and then the actual sound.
W / q, as well as shiftw/shiftq, serve as the value of the already entered sound
lengthen or shorten. Sometimes I perceive that this does not make the value of the note lengthen or shorten. Why is this, obviously I'm doing something wrong.
I have also observed that unnecessary pauses can be deleted by moving the sounds to the right of the pause with the cut/paste command. I have found that the shift arrows do not always select me well. What is the fastest way to select a section with a screen reader?
Can there be a specific
this is especially important for big projects.
That's all for now, but I will continue to study the program, because I see more and more the possibility that mus score can become the main tool of composing for me, especially because of the fantastic sounds.

In reply to by Viktor Erdődy

Hello, and sorry for the delay in responding. I have set aside the remainder of this week (and next week as necessary) for working on some new tutorials to replace these older ones - much has changed in the last few months.

Meanwhile, I will try to address your questions.

Your first question mentioned changing "reservation" and "tone", but I don't understand what you mean. Are you referring to the key signature? You can change key signatures using the palette. Just select the existing key - or any measure - then add a new key signature from the palette.

Yes, the program works in overwrite mode, and yes, you select duration before pitch. This also applies to the shortcuts "Q" and "W". These don't change the pitch of notes already entered while in note input mode - they simply change what is selected on the toolbar, to influence the duration of the next note. Shift+Q and Shift+W will change the duration of the current note, but your screenreader probably won't read this right away. You'll discover the duration changed if you navigate away from this note and back, though.

Cut and paste is indeed the way "delete" rests. You can't really delete silence, but you can replace it with sound, and that's what cut and paste does. Shift plus arrow keys should be working well, I'm not sure what issue you are encountering. Shift plus right extends a selection a note or rest at a time, Shift plus Ctrl+right extends a measure at a time. Shift plus Ctrl+Home extends all the way to the end of the score. There are other methods that may work depending on what specifically you want to do.

I hope this helps!

In reply to by Marc Sabatella

Hi Marc and Members
Thanks Marc for the great tutorials.

Would it be possible to tweak some of the dialogs so that buttons are in Tab order as opposed to using left and right arrows? I'm going to be teaching blind school kids to use MuseScore as their main tool for composition assignments and the way things are at present is going to be a steep learning curve.
For example, Cancel, Next, Back and OK would ideally be found using Tab. Also, Radio Buttons would ideally be found with Up and Down and then a button would be automatically ticked once it has the focus.

Thanks Team For Your Fantastic Efforts

Stephen

In reply to by chord symbols xml

This was a conscious design decision based on analysis of how other complex modern applications are doing things and various different published style guidelines. It's a change from the old-school way of doing things to be sure, but apparently it's picking up steam across the board. Our experience has been that once users are aware of this they adapt. But we will continue to monitor feedback over time.

In reply to by chord symbols xml

That's a great idea; I have no idea how feasible it is though. I recommend opening an issue to request this on GitHub - https://github.com/musescore/MuseScore/issues/new?assignees=&labels=&te…

Also be sure to check out the current version of my accessibility tutorials - this thread is from back in the "alpha" and is pretty out of date by now. The current versions are at https://www.youtube.com/playlist?list=PLpx1s2WkyujYgLkA0r30sQGjVhWl4NKZ3

The biggest accessibility problem for me is that I cannot use MuseScore with one hand only, since for most tasks, one has to use both the keyboard and the mouse at the same time.

In reply to by Marc Sabatella

Musescore is certainly useable with only one hand, and no mouse. But there are certain stumbling blocks. For instance, having to hold the Alt key and then arrow keys is impossible to do with only one hand, as is for example control+shift+arrows. All that can't be done using one hand, though one might do it with the mouse.

In reply to by rogerfrdhm

Much depends on the layout of your specific keyboard. On mine, Alt+cursor is doable with one hand. Adding Shift is possible, but not fun. "Sticky keys" is definitely the answer for one-handed keyboard operation in cases like that as mentioned. It seems to be supported on all major operating systems.

In reply to by Marc Sabatella

"Sticky keys" assumes one uses Windows, although there are alternatives on other operating systems, but in every implementation I find it more cumbersome than helpful (two keystrokes taking longer).

I've been using MuseScore for about 9 years now, and although it has gotten better over time, in my experience, MuseScore is one of the most difficult interfaces to use with one hand, especially compared to software like Inkscape, Krita, Blender and GIMP... I sometimes have to do some rather complicated things and those almost always require the use of mouse (or are extremely inconvenient with keyboard only). The basic assumption for MuseScore is that one hand is on the keyboard while the other is on the mouse. When this assumption is not met, the workflow is really slow and inconvenient. I often have to let go of the keyboard and do things with the mouse. And then let go of the mouse and work with the keyboard. Very slow and inconvenient.

What would certainly help is to have the different functions for the left mouse button and the middle mouse button (the wheel). The wheel being only for navigation (zooming and panning), while the left button being for selecting elements.

In reply to by kresimir

The sticky keys feature is not specific to Windows; it is also available as a native feature (and under the same name) on macOS, most Linux systems, and Chromebooks. But indeed, it's not for everyone - it's really meant as a specific accessibility feature for specific types of disability or other specific use cases.

Can you explain what you are finding you still need the mouse for? The only thing I am aware of that requires the mouse is palette customization, which can only be done via drag & drop. I think literally everything else can be done keyboard alone. Certainly there is no expectation you'll have one hand on the mouse; very many of use rarely use one, and some never do. Shift+click is convenient as a method of selection, I guess, but hardly required, as you can select by keyboard alone in many ways. I guess the one thing I do still find a bit awkward to work without the mouse is the Mixer. It's possible, but rather slower.

Regarding your last comment, I also don't understand that. The wheel is already for navigation only; the left mouse button is already for selecting.

In reply to by Marc Sabatella

There are many things that are very difficult to do with keyboard, but that is beside my point. Now, don't get me wrong, I actually prefer using the mouse to keyboard for most things, and I don't mind switching between keyboard and mouse occasionally. What find difficult is having to use them both at the same time, especially for zooming and navigating the score (which is something one does all the time, and it should be done without thinking about it). My biggest issue is that no option to zoom with the mouse wheel (one has to hold Ctrl) and zooming with keyboard alone is clunky (no fine control), and requires often letting go of the mouse: I zoom in and out all the time (up to 1600% do do some fine adjustments), and I often have to get my hand off the mouse to do it, to type in the zoom percentage.

Also, the middle mouse button panning does not work when in note input mode.

Here are some specific things that are difficult to do with keyboard alone (but as I said, I have no complaint about any of them, since I don't mind using the mouse):
- Modifying the shapes of slurs
- Picking custom symbols from the Master Palette. Especially when it comes to positioning ornaments on top of each other and other fine adjustments.
- Adjusting beams, while possible with keyboard only through the inspector, is cumbersome without a mouse.
- Creating custom tuplets is quite difficult without a mouse. Tuplets like these: https://musescore.org/en/node/337407#comment-1151971
- Selecting many elements (for example, I want to hide 96 out of 113 staccato dots).

In reply to by kresimir

Thanks for the examples! I'd like to understand better so we can see what improvements can be made.

First, are you making a distinction between "middle mouse button" and "scroll wheel"? The scroll wheel definitely works in note input mode. If your mouse is configured to send true scroll events with the middle button, that should work too, but perhaps it is configured to send a click instead? if so, maybe your system has a setting to change that.

Zooming is indeed something that is harder to do with fine control one-handed. Do you have a good suggestion for how that might work based on how other programs accommodate that? Ctrl+scroll wheel is a pretty standard gesture, and I'm not really aware of common alternatives. Similar for Ctrl+click to make list selections. Sticky keys might help with these?

Similarly, beam adjustment by keyboard alone does indeed require an awkward interaction with the Properties panel. It would be useful for Alt+Left/Right to be able to select the beam directly.

But the other things you list - slur editing, using the master palette, adjusting position of ornaments, creating custom tuplets - should all be easily doable via keyboard alone. If you continue to have trouble with these, best to start a new thread and describe the problem in more detail, and then someone can understand and assist better.

In reply to by Marc Sabatella

Regarding zoom, all my problems would be solved if there was an option to change the wheel to zoom (without Ctrl) and use Ctrl+wheel to scroll up and down, in other words, reverse the vertical scrolling and zooming controls with the wheel. This is how Inkscape, Krita, and GIMP do it, they all can be configured to zoom with the wheel alone, and scroll up and down with Ctrl+wheel. Of course, this is not (and shouldn't be) the default behaviour, but rather an accessibility feature.

The middle mouse button (i.e. pushing the wheel) is used for panning in MuseScore and it mostly works, but it has some very odd behaviour. For example, if an ornament is selected, middle mouse button does not pan, but moves the ornament. In note input mode, middle mouse button does not pan, but does nothing.

In reply to by kresimir

Forgive my confusion, but if you made zoom be scroll wheel alone, then you'd just need Shift to scroll, and surely that's more common? Anyhow, feel free to submit a feature request for this via GitHub - https://github.com/musescore/MuseScore/issues/new?assignees=&labels=&te…. I recommend explaining the use case in more detail, so the developers can better understand the how this proves useful.

I see now that you are making a distinction between the "middle mouse button" and actually scrolling. Normally, of course, the scroll wheel is used to actually scroll, and that works as expected for me. But I gather some devices also allow you to push the scroll wheel instead of turn it to enable additional functionality in some applications. It sounds like you are saying that on your system, MuseScore just interprets that as a standard mouse click? I don't have a device with a physical pushable scroll wheel to test with - I'm mostly using touch devices where scroll wheel is actually two-finger swipe.

According to https://github.com/musescore/MuseScore/issues/11656, a fix was implemented to enable drag on middle mouse button , but I think perhaps this has not yet been made available in a release yet. It may work in nightly builds made from the "master" branch. I'll look into that.

In reply to by Marc Sabatella

Using a real mouse vs. using a touch pad on a laptop are two entirely different experiences. The two cannot compare in any practical way. Therefore, if you are trying to understand what I am talking about by imagining a touch pad, there is bound to be confusion.

So, to be clear, everything I am writing here applies to a standard physical mouse, with three buttons (left, right, and the wheel, which when pushed is called the middle mouse button). Nothing I write here is applicable to a touch pad, I never use one.

In MuseScore, pushing the middle mouse button and dragging is like grabbing the page and moving it around. This operation is called panning and it replaces almost all need for scrolling. It works very well, apart from a few odd, inconsistent behaviours I mentioned above. Therefore, in my workflow, zooming is much more common than scrolling up and down, especially in MuseScore where pages are laid out horizontally and there isn't much need to scroll up and down. Come to think of it, I never really scroll up and down. Small scrolling within the page can easily be achieved with panning, and zooming out on one spot and zooming in on another (thus achieving the equivalent to scrolling by zooming out and zooming in to a different spot). And I also use the navigator to quickly jump to a different page.

In reply to by kresimir

I mostly understand now. And I think that link I provided suggests the issue should be fixed in a coming update.

Of course I am familiar with panning since it is possible with the left button as well although with the caveats you are noting. Even without those caveats I personally would not see it as a good substitute for scrolling, since it takes a very long time to move longer distances, but the addition of the scroll bars in MuseScore 4 should help with that. It would be a shame to have to keep the navigator open all the time just to move around, since it takes space and slows MuseScore down overall. So hopefully we can find you good alternatives. Are you still finding the navigator necessary even with the scroll bars?

Also, it sounds like your mouse wheel doesn’t allow horizontal scrolling? The ones I have used did, and most of my touchpads do as well. If your wheel doesn’t allow horizontal scrolling except by holding Shift, then that would indeed be a limitation that would render it less useful that otherwise.

Note you can change the scrolling of pages to be vertical if you like, though, in Edit / Preferences / Canvas.

In reply to by Marc Sabatella

I don't really need scrolling, like I said, the best solution would be to do the same thing Inkscape, Krita and GIMP do, have an option in the preferences to switch the mouse wheel from scrolling to zooming. If this option is on, then the Ctrl+wheel becomes vertical scrolling and Shift+wheel remains horizontal scrolling, and wheel alone zooms. If the option is off, that's the default, the current behaviour.

I quite like the navigator, for quickly jumping between pages. Scrollbars are less precise in navigation and require more precision in clicking, and the navigator is faster if I have to quickly go from say page 1 to page 15. I guess it's a matter of preference.

For me, horizontal layout is perfectly fine, it makes more sense than vertical, but it's good to know that there is an option to change that. No single configuration can be satisfying for everyone, that's why more options are always better. Just because I can't imagine a use case for some of them, doesn't mean that for someone else, they make a difference between being able to use MuseScore and not.

In reply to by kresimir

Yes, understood, we all work differently. I just wanted to be sure a) I understood your requests in order to be able to pass them on most effectively, and b) that you understood what was already possible, as not everyone is aware of all features. I surprising number of people don't even know the scroll wheel is a thing at all, for example, and simply are in the habit of dragging because it never occurred to them there was an alternative.

Do you still have an unanswered question? Please log in first to post your question.