Keep mouse as pointing device when entering notes from computer keyboard

• Feb 15, 2024 - 17:33

In several earlier discussions, the most recent one being here: (https://musescore.org/en/comment/1228012#comment-1228012),

people have requested that the mouse should be able to continue to be used as a pointing device when entering notes from a keyboard - be it the computer keyboard, the onscreen Piano keyboard, or a MIDI keyboard.

As things stand, entering a note from the computer keyboard automatically switches to Note Input mode, in which the mouse can be used only to enter notes, and not as a pointing device. As a new user, I agree with several people who find it annoying to have to press Esc to leave Note Input mode every time I enter a note from the keyboard in order to continue using the mouse to move around in the score. I feel that the mouse should be able to be used as a pointing device while entering notes from a keyboard.

Unless I misunderstand, the basic concept of MuseScore seems to be that there have to be two separate modes, Note Entry and Normal (or Edit), and that in Note Entry mode, all possible note entry devices, including the mouse, are enabled for note entry. The two modes are seen as somehow mutually exclusive.

Yet when one thinks about it, in MuseScore the computer keyboard is not used exclusively for entering notes when in Note Input mode. It is a hybrid device: The ABCDEFG keys enter notes, but other keys do a range of other things when in Note Input mode - for example the arrow keys can be used to move around in the score or to move a rest up or down. So it seems that Note Input should be conceived of as a function that various devices can perform, rather than as a mode in which all devices perform the same function and only that function. From my point of view as a word-processor user, it would be like having a separate mode for "editing" (formatting, outlining, etc. etc.) and a different mode for "entering text" in Word or OpenOffice. But in fact both are possible at all times using the keyboard and mouse and/or touchpad.

Such a change in the conceptual perspective, I feel, would make it easier to see that being able to choose what the mouse does at various times would not constitute a fundamental challenge to the way MuseScore works.

Comments

• Feb 15, 2024 - 22:31

I agree to what you say and at the same time is surprised by the discussions this simple issue causes.
It is just «leave thing as they are», but give those who wants it the choice of disabling the mouse for note input.
No talk about design, multiple options, concerns, problems, what ifs and whatever artificial obstacle to prevent implementing a simple, harmless “thing”.

Reply

• Feb 16, 2024 - 06:09

P.S. it's not necessarily "harmless" if MuseScore allows clicking any kind of element while in note entry... certain strange things could happen. For example, should the user be able to select a staff text while in note entry? A beam? Of course range selections are not enabled by the official builds while in note entry.

What would happen if the user were press a note [A-G] after selecting a beam somewhere far away from current note entry mode? What I'm getting at is, it seems reasonable to limit user-selectivity instead of being careless about it. Only allow noteheads and rests to be selected would be my suggestion to play it safe. Or maybe have note-entry mode be exited when selecting anything but a note/rest?

Reply

• Feb 16, 2024 - 07:15

Got something working for 3.x, maybe I can get JoJo-Schmitz to test it out on his "3.7"
1) Advanced preference "disableMouseEntry"
2) Selection is allowed while in note entry and operates like mentioned:
If note/rest, select it and move note entry cursor
if staff is selected, do nothing
If other elements are selected, exit note entry and select them (like clef/barline)

Example:

video.gif

Reply

• Oct 9, 2024 - 10:58

Jojo, some people on the French forum are interested in the function that's implemented in that build (MuseScore-3.7.0.7947196158-x86_64). I followed the link I had (https://github.com/Jojo-Schmitz/MuseScore/actions/runs/7928451642) and the page is there on GitHub, but I can't seem to download it. Can it (or a later version) still be accessed?
Thanks,
Les
-later- Someone there posted a link explaining how to download it. Sorry for the inconvenience.

Reply

• Feb 16, 2024 - 07:57

I agree. I get the impression that note entry by mouse is considered a fundamental feature of MuseScore, and that even allowing it to be toggled on and off would somehow compromise the fundamental nature of the program. I'm all for being able to use the mouse to enter notes, but to me its use as a pointing device is more important. I don't see why there can't be a choice.

Reply

• Feb 16, 2024 - 03:36

An alternative reason to want this option would be to eradicate the following problem:
1) Leaving focus of MuseScore while in note entry (scrolling a pdf or whatever)
2) Gaining focus again via mouse click... accidentally possibly inserting a note....

Not wise to perform, but... "it can happen" is all I'll say about that.
Disabling mouse input as an option would be one solution.

Reply

• Feb 18, 2024 - 09:10

Okay, I created a custom Workspace, then found the mouse-toggle entry and added it to the toolbar, then cleared the "M" shortcut from the default and added "M" as the shortcut key to toggle mouse entry. And it all seems to work just fine. (If anyone needs help with all this just ask.)

May you have even more of what you love most in life, and even discover a few new things to love and get plenty of those!

PS I gave the folks on the French-language forum a heads-up. Hope that's okay...

Reply

• Feb 21, 2024 - 12:59

As explained in previous discussion, no one denies the usefulness of some way for users who wish to not be able to use the mouse during note input to have that wish granted. What is still missing is a concrete proposal for how such a change could be presented that is actually logical, discoverable to new users, and doesn't impact existing users.

Previously I made what I think is an extremely sensible proposal that requires no new option at all: simply change the behavior of click to not enter a note if clicking somewhere other than the current measure. I'd like to see discussion of that proposal. And if someone has an equally specific alternative proposal, I'd like to see that proposal along with discussion of how your proposal address the points I previously raised with previous proposals.

Reply

• Feb 21, 2024 - 15:55

"simply change the behavior of click to not enter a note if clicking somewhere other than the current measure"

Not enter a note... and place the cursor/insertion point at the location of the click? I think that's a great idea and I'm for it, as I've said elsewhere. It makes perfect sense for the mouse to input notes in a chord or as part of a series of notes and rests, but not outside the current measure, as you say.

New users, who are used to using the mouse as a pointing device in other types of applications, would welcome it, because they're likely to be disoriented by the mouse suddenly changing functions when they enter a note from the computer keyboard. When you think about it, it's not very logical to switch to note input mode if a single note is entered from the keyboard. If it is logical, then why doesn't clicking within a measure with the mouse immediately switch on note input mode? As a new user, that confused me. What I needed to discover was how to turn that off. But as it turns out there was no way - until worldwideweary came along.

If your suggestion were implemented, it would recognize the fact that the mouse is a hybrid device, just as the computer keyboard is a hybrid device in that it performs both note entry and cursor movement functions. People who really want to be able to toggle the mouse on and off might not be content with it, however. How are you going to keep 'em down on the farm after they've seen Paree?

Reply

• Feb 21, 2024 - 19:04

Yes, I mean that clicking would move the cursor but not add a note.

I don't understand your confusion about why inputting a note puts you in note input modebut selecting a note doesn't - seems pretty plainly obvious to me. So it still seems to me you are probably misunderstanding something very fundamental here, although I can't quite tell what.

Easiest way to toggle the mouse off is, of course, to not use it. So I'm not really understanding that last comment either. If the default already does exactly what you want, why on earth would you want to have to press a button to get that behavior instead of getting it automatically?

Reply

• Feb 22, 2024 - 10:06

"I don't understand your confusion"
I'm not confused; "annoyed" would be the better term. It's annoying that inputting a note from the computer keyboard turns the mouse into a note-input device as opposed to a pointing device. What I'm misunderstanding is why, if the preceding is the case, doesn't clicking within a measure (not "selecting a note") with the mouse not also turn on note input mode. I believe that the fundamental thing I am not understanding is the need for a strictly enforced black-white, Manichean, Republican-Democrat distinction between modes.

"Easiest way to toggle the mouse off is, of course, to not use it"
But how can you not use the mouse for note input when the doggone software forces you to as soon as you enter a note from the keyboard?

Your proposed solution would solve the problem for me, but I don't see how it's any more or less dogmatically correct than worldwideweary's prototype solution, which is working very well for me.

Reply

• Feb 23, 2024 - 00:09

As explained multiple times before, it's not using the keyboard" that turns the mouse into a note input device - it's *entering note input mdoe that does. Doesn't matter if you do it by typing a note name, by clicking the toolbar icon, are by any of the several other methods that exist. Once you're in note input mode, the keyboard, mouse, piano keyboard window, and MIDI keyboard (if present) are all available for note input.

It's surprisingly difficult to design a music notation program that doesn't use a concept of modes to differentiate between ordinary selecting/editing vs entering notes. But if you'd like to start a new thread with a concrete proposal based on your experience as a user interface designer, by all means, you're welcome to do so. Please include screenshot mockups, specific workflows, etc. But I think you'll find it easier said than done.

As for the mouse - once again, the program does not in any whatsoever force you to use the mouse for note input. Millions of users never touch the mouse. keyboard shortcuts exist for virtually everything. If you don't want to use the mouse for note input, then don't use the mouse for note input. You are for whatever reason choosing to use it for navigation, but the keyboard exists for that as well. And if you are currently in note input mode want to use the mouse to navigate, there is a very simple shortcut to make that possible: Esc.

The only question is whether there could be another way of allowing the mouse to function for navigation while in note input, one that doesn't exit note input mode. Forcing people to find and enable some obscure oscvure and then never be allowed to use the mouse for note input again until they repeat that process is terrible design. Forcing users to constantly toggle the mouse on and off manually is equally terrible design. The goal here is to find a solution that actually works well for everyone.

But there is nothing "dogmatic" about insisting on a user interface that is both useful to all of MuseScore millions of existing users instead of just a select few, and also one that is easily discoverable by the millions of new users as well. That is the whole purpose of these discussions - to discuss problems and solutions rationally and come up with solutions that work for everyone.

Reply

• Feb 23, 2024 - 07:13

Thanks for your answer. I never said that using the keyboard switches to note input mode. I said that entering a note from the keyboard does. When one is in normal mode and presses A, B, C, D, E, F or G, shouldn't they do something that corresponds to normal mode, just as the "N" key does? If one wants to enter notes from the computer keyboard, shouldn't one have to press "N" or click the icon to do so? But currently, pressing any of those keys (ABCDEFG) in itself switches to note input mode. As I've pointed out, when in Normal mode, clicking with the mouse in a measure in a place where a note can be expected to be does not automatically turn on note input mode. So why should pressing a "note" key do so?

Being able to use the mouse to navigate while in note entry mode, to me, is not conceptually different from being able to enter a note from the computer keyboard while in Normal mode. In other words, both user-input devices have a hybrid nature.

"Forcing users to constantly toggle the mouse on and off manually is equally terrible design."

I agree. And that is exactly what the application does now. The toggle is the Esc key.

" But if you'd like to start a new thread with a concrete proposal based on your experience as a user interface designer, "

Come on, Mark. I have never claimed to be a user interface designer or to have programming skills or whatever. All I'm trying to do here, and I've tried to make that clear, is to give the benefit of my reactions as a longtime word-processor user. If that's not of interest, fine.

Reply

• Feb 21, 2024 - 18:10

About Marc's proposal : Some heavy mouse users, using mouse input only might not like this change. That will require two clicks instead of 1 to start inputting notes in another measure than the current one.
And it doesn't entirely satisfy the non mouse entry users like myself : even in the current measure, I never want mouse click to enter a note.
So I prefer the current option implemented in 3.7

Reply

• Feb 21, 2024 - 19:01

I must have missed where someone posted a design specification for that. Can someone please repost it into this thread?

In any case, keep in mind this isn't about voting on one favorite for our own personal use. It's about coming together to find the best compromise for all users.

Until I see the design spec for the "3.7" feature, I will refrain from comment on that. But I can address your comments on my own proposal:

  • Yes, it's true that some mouse users might sometimes actually want the mouse click to enter a note when changing measures. My guess is that it's 50/50 at best though and it would still be seen as a win overall. Obviously we'll need a lot for feedback on this, ideally from a working prototype build.

  • I'm not clear on why someone who primarily uses keyboard for note input would be clicking within a measure. Can you describe the real world use case for this that isn't solved much better by simply using the keyboard to navigate? The use case of wanting select to entirely different locations is easy enough to understand because even though shortcuts exist for moving between measures or staves, they might not be as efficient in some cases. But I'm struggling to understand your case.

It's certainly possible that some sort of hybrid could also exist, where the default* behavior* is one that almost everyone would find an improvement, but there would also be an option to have other behaviors. Like, a three-state option, with the choices being "the old way", "the 3.7 way" (whatever that is), and "the way we think most people will want to use all the time".

Reply

• Feb 21, 2024 - 22:47

Hey Marc, my previous post above: https://musescore.org/en/node/360642#comment-1229291 kind of gives a simplified sense of the description of the PR mentioned. Not sure if it'll be useful for discussion though. That + the mouse button added into the "Note Input" Toolbar (not needing to alter an advanced preference, and also provides a cmd-shortcut for toggling) gives a sense of the description of the PR mentioned. I also decided against keeping note-entry (while disabling mouse input) if the selection was not a ChordRest, because it seemed a potential hazard if anything else were selected (like a frame or tempo mark or something) while retaining note-entry.

Reply

• Feb 23, 2024 - 00:16

It's not very detailed at all, I'm afraid. What would be more useful is something that looks roughly like a Handbook article describing how the feature works, to someone who has never heard of this feature before.

Certainly if a PR that changes behavior is to be considered, that level of detail would be useful.

But as it is, I can try to read between the lines. It sounds like you are proposing adding an option to Edit / Preferences / Adnavced that once set, makes it henceforth impossible to enter a note by mouse?

This is something what I said was pretty obviously unacceptable as being hard to discover but also all-or-nothing.

Putting that same option on the toolbar helps with discoverability but clutters the interface and isn't ideal. But more importantly, it's now a lot of extra work to go between navigation and note input by mouse.

I'm hoping to agree on a solution with none of these disadvantages - one that actually makes both navigation and note input by mouse easy, and is easy to discover. Hence my proposal.

Reply

• Feb 23, 2024 - 03:34

Oh, I'm not proposing anything anymore (Jojo got it merged in his fork), it's just an implementation for users of his "3.7" branch. I personally don't find the addition of one button to be an act of cluttering the interface, but we've all our opinions about this kind of stuff. If something like this were to be implemented into Mu4, a handbook-like statement would be nice.

Originally it was merely an advanced preference, but after a user wanted a shortcut, I provided a command along with taking the opportunity to implement a toggle-based icon that can be added to the Note Input toolbar. Once showing, it's very easy to enable or disable via toggle/shortcut which could be assigned to whatever. I sort of presumed that anyone who wanted this probably wouldn't be switching "back and forth" between mouse-navigation and mouse-note-input often enough to see it as "a lot of work". For example, fwiw, I never use mouse-entry, so disabling it would be left untouched (on my personal build I even disabled vertical dragging of notes-pitches to be safe) and would give me the benefit of non-accidental note entry when switching between applications via mouse if I were in note-entry and forgot to get out of it.

By the way, while I was learning to implement the button, I got the idea that it would be kind of nice to get a hover-over highlighting for the "to-be selected" element during navigation, and then figured it shouldn't require note-entry to work with ability to choose the color via another toolbar button. Didn't try PRing it yet to the "3.7" thing, but it looks like this:

hover.gif

Actually strangely kind of "fun", but I'm not sure the guys working on Mu4 would find it agreeable

Reply

• Feb 22, 2024 - 10:40

Here's a stab at it, for your... input:

"In this prototype, the computer keyboard is both a note-input device and a navigation device (horizontal arrow and PgUp and PgDn keys), as well as serving to issue commands (for example, striking "P" shows the Piano keyboard by default). This being the case, entering a note from the computer keyboard, since the keys ABCDEFG correspond to notes (in the English-speaking world), does not automatically switch on Note Input Mode. Neither does clicking with the mouse within a measure. Note Input mode is toggled on and off with the "N" key and/or the leftmost icon (resembling the letter "N" but with a notehead attached) on the Note Input toolbar.
In Note Input mode, the keyboard retains its "hybrid" nature: striking ABCDEFG enters the respective notes, but the navigation keys can still be used for navigation.The midi keyboard enters the note played thereon in the current measure. The mouse can be used as a navigation device or as a note entry device. Its behaviour is toggled via the "mouse" icon on the Note Input toolbar; a shortcut key can also be assigned in Advanced Preferences. If the mouse is being used in note entry mode, clicking on anything other than an empty space within a measure, a note head, or a rest automatically toggles note entry mode off for the mouse (it returns to acting as a pointing device)."

Reply

• Feb 23, 2024 - 00:32

In at least one of the earlier discussions (https://github.com/musescore/MuseScore/issues/21399), I also proposed another super-simple change that would have very little impact and solve the problem well except for the discoverability aspect: making Alt+click move the cursor. Currently it enters a rest, which is an almost entirely unknown feature and not really needed because right-click does the same and is better documented.

Reply

• Feb 23, 2024 - 05:26

This seems simple and easy, and discoverable enough if Mu4's handbook had that information added. I'd just warn to consider something like with the PR in 3.7: exit note-entry when something besides a notehead/rest is selected to mitigate potential issues with note-entry mode, or at least verify code-wise/beta testing that nothing funny happens if so.

Unfortunately, not disabling note-entry wouldn't additionally solve the annoyance for keyboard-entry users of having possibly a note entered when refocusing into Musescore if the user stayed within note-entry while switching windows via mouse. Have had it happen in the past when moving mouse to another monitor, scrolling down in a pdf-viewer, then clicking back into musescore while entering notes. The potential for stuff like that is removed by disabling mouse-input via toggle.

Reply

• Feb 26, 2024 - 15:11

"Discoverable" doesn't mean "a user can find information about it in the "documentation". Practically the opposite, actually - it means something that is designed to work so naturally people can figure it out without documentation. That is almost always a goal of UI design, and for any feature as central to a program as note input is to MuseScore, discoverability is absolutely is one of the primary factors.

Reply

• Feb 26, 2024 - 17:43

I think I understand. Unlike Mu4's hidden voice-3/4 options or the lack of search results in the palette of items that were added in by the user, something rather like the big N for note-entry right smack in the front of the program, border-lining into the realm of the fabled intuitive experience. Musescore historically has been pretty good about this.

Reply

• Feb 26, 2024 - 18:17

I suppose one could view voice 3 and 4 as "hidden". Or just not shown at first so as to not clutter the UI if you don't need them. As well as some of the other items on the tool bar. It is easy to dive into new software without checking the manual first. Then complain when you can't figure something out. I've certainly done it.
It seems to me that MU4 is very consistent as far as note entry mode goes. Mousers have to click into and out of note entry. So do keyboard users. The only difference being that keyboarders click in by basically entering a note.

Reply

• Feb 26, 2024 - 18:22

Sometimes hidden can be obscure in description. Like, the inclusion of "Note Anchored Lines" existed for I know not how long before I became aware of them, even though technically the command could be described as easily discoverable, their insertion being available in the Add→Lines Menu. There's a relativism at play here related to the user's tendency for search, etc.

Reply

• Feb 26, 2024 - 22:14

Which raises another issue: it looks like the + sign on the toolbar is a replica of the options in the Add menu above (except + lacks the tuples found within the add menu). Is this to be seen as a "clutter of the toolbar" when it is an exact replica of available options from the Add menu, yet missing the tuples? Why the duplication? I suppose it increases discoverability...

Reply

• Feb 27, 2024 - 00:53

Your interpretation/statement is in error.
Also, the + method doesn't exist in MU3: only in Mu4, so the duplication only exists in Mu4 in relation to the Add menu and the + toolbar.

P.S. Looks like the tuple icon: tuple.png makes up for the lack of presence in the + toolbar, which accounts for the "discrepancy"

Reply

• Feb 27, 2024 - 04:20

Not sure of the error about reading your post. If you'd like to point it out, feel free to do so.
Anyways, seems rather that the thread is to be about "keeping mouse as pointing device when entering notes from computer keyboard" and not merely a button. So far, to re-iterate the status as it seems to me:

1) There's the toggle button to be able to enable/disable on command the mouse as note-input device, considered by some so far as cluttering the toolbar and also unnecessary, which is currently incorporated into "3.7 Evolution".

2) There's the proposal of Alt+Click for navigation only, but as Marc rightly pointed out, that would have a discoverability issue, and then

3) The reduced version: to maintain the mouse as input-device only within the current measure of Note Entry, but that would have repercussions for someone who liked to jump around by measures while inserting notes at the same exact time with the mouse for whatever reason. Not sure if there is anything that "stands out" as most acceptable.
...Hopefully it works out for Mu4 users and this concept.

Reply

• Feb 27, 2024 - 21:52

Actually, I do understand what the thread is about. It will be interesting to see if anything comes of it. Believe me, if I where a keyboard note input person (hereafter known as a keyboarder), I would find some method of keeping the mouse as a pointing device while inputting notes with the keyboard (or scenario 1 above), very desirable. Why not.
But consider how consistent note input is right now, Regardless of our method of choice, there are at least two ways to enter note input. (Oh no, the dreaded duplicity) A keyboarder can 1. hit "N" or 2. enter a note.
A mouser can 1. hit "N", or 2. double click in a measure. Very similar.
But now there seems to be a problem that might need a software alteration. We need to use the mouse as a pointing device. The keyboarder has two ways to do that. They can 1 hit "esc" or 2 hit "N". The mouser has the same choices.
But some keyboarders don't want to have to leave input mode at all. Nothing wrong with that. So someone needs to come up with a way to do that.
"Discoverability"? there are many important things already in sub-menus. MU4 hid and/or moved or totally changed almost everything. A setting like "keep mouse as pointing device" (KMPD), doesn't need to be on the main UI. But it must be noted that users need to spend some time in the manual. We tend to just jump in and start pushing buttons. I'm certainly guilty.
I'm just not seeing the problem with remembering to use MU4 the way it is now. And it is a question of remembering to hit "N".

Reply

• Feb 29, 2024 - 07:51

I was responding to your saying "Besides this thread is not about that, It's about, in my view, an unnecessary button."

To me, the button on the toolbar is just a convenient way to see if mouse input is toggled on or not. So in a way it's unnecessary, yes. I'd rather toggle with the "M" key, which is how I have it set up, OR have a click anywhere outside the current measure switch mouse input off, as in Mark Sabatella's suggestion in the GitHub thread.

Anyway thanks to you both for carrying on the discussion. I've been distracted by what happened in front of the embassy in DC.

Let me add a question I've asked before: Is there a place in the documentation where the need for two modes is explained? I know the necessity for it seems to be a basic assumption, but that's a sincere question.

Reply

• Feb 29, 2024 - 16:36

I'm not sure that clicking outside the current measure is better than just using "N". They both require some kind of action.

I don't think the need for any of the modes is explained in the manual. Seems to me that there are two basic modes. Input and Output. There are several sub-modes within each of the basic modes. I assume your question has to do with why keyboard and mouse input are activated at the same time. Consider that for a mouser, it might be quicker to select duration with the keyboard and pitch with the mouse. I don't do it that way because I prefer the slow, painstaking method of doing both with the mouse. It's the way I've done it for some 15 years of using notation software.

Reply

• Mar 5, 2024 - 15:30

I'm gonna bail, fellows, unless somebody really needs further input from me on this subject. Thanks again to worldwideweary for his work.+ It enables a choice that I think is useful and will be useful for others, without changing anything else for those who like things just the way they are. I would definitely be in favor of it being included in official versions of MuseScore.

  • and God bless him!

Reply

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