Open question: why do we need note input mode?
Open question: why do we need note input mode?
Except for the behaviour of the mouse, do we really need a 'note input mode'?
Wouldn't the program be easier to learn and use with only one mode (which means no mode at all in fact)?
Possibly with a button to switch the mouse behaviour between "select tool" and "note input tool". (Users using only the keyboard to enter notes would never use this and always keep their mouse as "select tool".)
?
Comments
"Except for behavior of the mouse" is a pretty big exception, is it not? And whether you call it a "mode" or a "tool" seems irrelevant - we are talking about two different states the program can be in. So I'm not quite understanding what you are proposing. It's certainly possible to design an interface that would be less "stateful", but the devil is in the details. Depending the specifics of the design, it could well end up being easier to learn but harder to use, or vice versa, or in fact harder both to learn and use.
In reply to "Except for behavior of the by Marc Sabatella
<< whether you call it a "mode" or a "tool" seems irrelevant - we are talking about two different states the program can be in >>
No. Only inputting notes with the mouse would require to switch the mouse behaviour, the state of the program would not change.
<< I'm not quite understanding what you are proposing>>
I don't propose anything, I was (and still am) just curious to understand what is the underlying reason of the existence of the note input mode.
In reply to << whether you call it a by frfancha
I still don't understand the distinction you are making. If clicking a note in your score sometimes does one thing and sometimes does another thing, then I don't see what difference it makes if you call that a mode or a tool - it still means you get different results from the same action. That's two different states according to any definition I know of the word state. If you know a different definition of "state", fine, then I'll invent a new word, "flizzbin", but the same argument applies - the program does different things depending on which flizzbin you are in.
As for basic reasoning behind having a separate note input mode, I wasn't around when this was being designed, so I can't really say what other options were considered. But I can observe that every single other notation I have ever used (easily at least a dozen) has multiple modes/tools/states/flizzbins for note input versus doing other things. That aside, it also seems that you don't want it to be too easy to accidental enter notes into a score when all you are really trying to do is view it or make formatting adjustments or add text or whatever else. And yet, when you *are* interested in entering notes, you want that to be incredibly easy. So it seems almost beyond question that clicking a spot in your score should do different things depending on whether your intent is to add notes or to select things, that pressing the letter "A" on your keyboard should do different things depending on whether your intent is to enter notes or text, etc. It's pretty hard for me to imagine a successful design that didn't have these properties, and these properties seem to imply different flizzbins.
In reply to I still don't understand the by Marc Sabatella
<< difference it makes if you call that a mode or a tool >>
The tool to enter notes by mouse would only be an additional, optional tool (e.g. I never input notes by mouse and could even ignore the existence of this tool)
On the contrary, the current usage of a mode, not a tool, can not be ignored: you have to continously switch in and out of this mode to do anything and the program behaves completely differently according to the selected mode.
In reply to << difference it makes if you by frfancha
OK, it's still a mode/tool/state/flizzbin then, just an optional one. And presumably you'd still have text edit mode, and chord symbol entry mode, and lyrics entry mode, and the other edit modes?
Anyhow, it's not really true that "the program behaves completely differently according to the selected mode". Many things work exactly the same. Really, only a handful of things work differently: the duration keys and letter keys most obviously. Also MIDI input - that would have to be dealt with as well (yet another optional mode that I guess, or maybe combined with the mouse input mode).
Following this thought experiment a little further:
Right now, the duration keys do indeed do something different for note input mode versus normal mode. So we'd need to choose which behavior would be used, and introduce a new set of commands - presumably ones requiring a modifier - to perform the other function. So already a step backwards in terms of usability. Hopefully it buys us something else in return, but without a specific proposal, it's hard to say what.
Right now, note input mode has a carefully managed notion of an input cursor as well as a current selection, with various commands operating on one or the other in ways designed to optimize usability. There is always guaranteed to be an input cursor so that pressing a letter key always enters a note in a predictable location, and there is always a single note or rest selected to the other commands also have a predictable effect. If there were not a note input mode, then there would not necessarily always be an input cursor (or would there?) and there would definitely be no guarantee there is a single note or rest selected, so the commands that enter notes or operate on the selection would have to be carefully defined to feel as natural as the current ones do.
So far, my gut tells me that any proposed mode-less interface would be likely to just make things more confusing, less predictable, and take more keystrokes to accomplish the same thing than the current model, but again, I'm open to specific suggestions so we can "do the math" and figure out for ourselves how various operations would work.
In reply to OK, it's still a by Marc Sabatella
<< Right now, note input mode has a carefully managed notion of an input cursor as well as a current selection, with various commands operating on one or the other in ways designed to optimize usability. There is always guaranteed to be an input cursor so that pressing a letter key always enters a note in a predictable location, and there is always a single note or rest selected to the other commands also have a predictable effect. >>
Yes, and that is excellent. In the theorical thought of getting rid of the notion of 'note input mode', these concepts would always exist.
To fix the "problem" of difference of behaviour of duration keys, it would be enough to say that they act immediately on the input cursor.
In reply to << Right now, note input mode by frfancha
Again, the devil is in the details. One way or another, you need to solve the problem of how to perform those two different functions. One function alters an existing note and that function clearly needs to be there. The other function does not alter any existing note but instead sets the stage for the next note to be entered, and that function absolutely needs to be there as well. Saying "act immediately on the input cursor" in no way makes it clear, or even gives a slight hint, as to *how* those functions would be performed.
In reply to Again, the devil is in the by Marc Sabatella
Thanks Marc for your input. The more I think about, the more I'm convinced that MuseScore without the note entry mode would be easier to discover, understand and use.
For example for these 2 functions that you see as different, as there is always "something" where the input cursor (at least a full bar rest), by altering the length of this existing "thing" that would do the job as preparation for the input of next note. Or another way to handle that would be to do nothing but prepare the length as today when the input cursor is not the selected note, and change the length when these 2 coincides. Whatever it is, there is a solution.
But as you say, the proof is in the pudding, and one day if I have the time I will finally take the plunge and work in the code myself, then I will be able to expirement with all these ideas.
In reply to Thanks Marc for your input. by frfancha
Indeed, there is a solution, but the one you provides sounds like a nightmare to me - it would make behavior seem almost random/unpredictable to most people. Constantly having to keep track for myself of whether the input cursor matches the selection? And how "discoverable" would that be? I think you'll find making things really seem to natural is *much* easier said than done, and there is most likely a good reason why virtually every notation program that has ever been created uses modes.
No need to worry about coding a proposal - first step is to just describe in detail how it would work, so we have something concrete to discuss. Then we could examine the series of keystrokes needed to accomplish various actions, consider what cues might make various specific commands discoverable, etc. No need to waste time coding a design that doesn't stand up to that sort of scrutiny.
I suppose MuseScore could work like a text editor, where there is always a blinking cursor somewhere. You would click with the mouse to move the cursor, and press keys on the keyboard to enter notes at that position. The "note input tool" would allow you to click with the mouse to enter notes instead of changing the cursor position, but pressing keyboard keys would always enter notes.
The problem with this is that sometimes I don't want to enter notes when I press the keyboard keys---either I pressed the key accidentally, or I just wanted to hear the note without entering it in the score (e.g. when deciding the next few bars of a piece I am composing). In these situations a "note entry mode" is more useful than a "note entry tool" because it allows me to entirely disable all forms input, while still allowing me to hear note sounds when I press keys.
One possibility, although it would be low-priority to me, would be to visibly change the shape of the mouse pointer in Note Input mode. (I don’t think that it does that now, does it ...?) Other aspects of the visual display already change, and I understand that in 3.0 they will change even more, to make the distinction more visually apparent yet.
I suspect that we will always have this mode, because fundamentally there are two reasons why you might be clicking in the stave area: either to select something that is now there, or to input something new. You need a very easy way to do that.
In reply to One possibility, although it by mrobinson
In note input mode the cursor shows a ghost note/rest, following theone that is to be added next, including notehead, stem, flags, or the particular rest. Stem and flags only in the current development version though.
In reply to In note input mode the cursor by Jojo-Schmitz
Wouldn't it be like redesigning Musescore from scratch if you wanted to get rid of input mode? I am not a programmer but even I can see how much depends on which mode you are in. Everyone of these details would have to be reconsidered and many more details following out from there.
I just don't think it is even worth it for the purpose of getting rid of something that is easy to use, easy to learn, easy to get used to. Anyhow in some situation Musescore changes the mode by itself, e.g. you select quarter rest in edit mode and hit G. It will enter a crotchet G and go into input mode. You don't even have to press N. I much rather keep looking forward to Musescore 3 rather than to Musescore Modeless version 1.0.
I'd also second Marc's point about protecting the notes from inadvertent actions while formatting or proofreading. The other day in a score I thought was finished I discovered a note with about 10 leger lines above the staff. No way I entered it that way. I must have inadvertently edited the pitch while formatting, adding dynamics or whatever. I suspect in a modeless Musescore this kind of thing would happen so often that you can never stop proofreading.
In reply to Wouldn't it be like by azumbrunn
I should clarify that I'm not in principle opposed to the whole idea of a modeless interface. i just think it would be very difficult to design one that didn't turn out to in fact be much less satisfactory than the current one, and frankly it's hard for me to imagine there being enough advantages (to either new or existing users) to be worth the pain of forcing existing users to re-learn what is already a very successful and well optimized interface.
But if someone comes up with a proposal that actually does provide significant (if as yet unexplained) advantage s- and manages to not suffer the various problems that *seem* to be inherent in the idea for the reasons discussed but might be avoidable with a sufficiently clever design - then I'm all for it. Until such a design is proposed, though, I'm pretty skeptical.
In reply to I should clarify that I'm not by Marc Sabatella
I think one of the biggest annoyances in this sphere for most advanced users--who almost never use the mouse for note entry--is having an inadvertant click enter an unwanted note in some unintended spot. I routinely move the cursor off the screen when in note entry mode to avoid this, but if I forget to do so, yup, sure enough, at some point I will wind up with a D96 seventy-eleven ledger lines above the cello staff....
Suppose there were a command to disable mouse-input while still in note-input mode? If that were doable, the mouse could be used for click-and-drag navigation without the need to change modes. Just brainstorming....
Thoughts?
In reply to I think one of the biggest by Recorder485
Now this would be brilliant!
In reply to I think one of the biggest by Recorder485
<< Suppose there were a command to disable mouse-input while still in note-input mode? If that were doable, the mouse could be used for click-and-drag navigation without the need to change modes. Just brainstorming....
Thoughts? >>
This would be very very useful and I would always use it.
In reply to I think one of the biggest by Recorder485
I took would enjoy the option of having the mouse disabled for note input. However, making it available for selection might be tricky. Probably only single click could be allowed, as note in our more currently has no concept of range or even list selection, and many commands would probably fail.
In reply to I took would enjoy the option by Marc Sabatella
<< However, making it available for selection might be tricky. >>
Defining the behaviour of the mouse click in this scenario could be: do what happens today if one do [ESC] - mouse click - [N]
?
In reply to << However, making it by frfancha
Yes, but we'd just need to disable (or redefine) ctrl click and shift click. We'd also need to make sure only notes or rests can be selected - not other element types. Also make sure the input cursor is handled reasonably.
In reply to Yes, but we'd just need to by Marc Sabatella
I'm not sure I understand. The program does not currently allow the user to make a selection--whether list or range--when in note entry mode. Are there plans to change that for 3.0? I can't see the usefulness of it, actually. I only need to select material that I plan to edit somehow, so I'd want/need to leave entry mode, which would put the mouse back into 'normal' operation. Hope that explanation makes sense.
I'm thinking that for the UI, a tick-box in Preferences on the Note Input tab to allow/disallow note entry by mouse-click would be the most logical way to go if this feature can be worked out.
In reply to I'm not sure I understand. by Recorder485
I was just thinking about it and indeed: instead of preventing shift-click, ctrl-click, or selection of other elements than notes and rests, just make these actions put you out of note input mode and work normally. That would enable to avoid lof of ESC.
In reply to I'm not sure I understand. by Recorder485
I was just thinking if the mouse didn't enterT notes people would probably expect it to do something else - like what it usually does. You mentioned dragging the canvas,
but I personally rarely use that. I'd be more interested in using click to make a selection - well, more to the point, to move the cursor. Like to start entering notes in a different measure, voice, staff. In any case, the pointer is if mouse doesn't do what it does now, it should do something meaningful.
In reply to I was just thinking if the by Marc Sabatella
A 'no-note-input' mouse would still be useful--virtually necessary, actually--for menu operations and those icons in the toolbar which don't have shortcuts associated with them (Pan Score; Play Repeats; Page View/Continuous View; Concert Pitch; etc.)
I don't use click-and-drag very often either, but sometimes it's a quick way to move the score a bit if one's other hand is busy turning a page or whatever. If you wanted the mouse to be used to place the cursor on an input beat without inputting an actual pitch, I can see how that could be useful if you were moving around in a score to share a melody among various instruments. Still, I think that need would occur more often in an editing context than an input context.
I would not recommend getting rid of mouse input entirely. Some children and new users feel their way with that method at first as it is entirely visual/graphic; also users who don't play piano or type very well and don't feel confident working on either a midi or computer keyboard. I just think the ability to turn that function off would make life a lot easier for the rest of us.
In reply to I was just thinking if the by Marc Sabatella
Yes, me too. Single click should just move the cursor and let you continue to be in note input mode.
Only actions which don't make sense in note input mode should put you out of note input mode and act as today, such as shift-click.
In reply to Yes, me too. Single click by frfancha
I was more thinking of it as a choice: Either it works the way we are all familiar with or else the mouse is disabled in note entry mode with all the advantages and disadvantages this has. The user's choice.
Ideally the mouse would still work everywhere on the screen except in the score itself; e.g. double click in the palettes would presumably still be attractive.
The note entry cursor can be moved with the arrow keys (up or down into another staff with alt/arrow) anyway so the mouse is not required for that; the arrow keys are faster anyway.
I am working with a touch pad and have had troubles with various softwares when inadvertently touching the pad in some manner. The fact that it is "smart" and reacts differently to two and three or four finger touches makes this even worse.
In reply to I was more thinking of it as by azumbrunn
<< the mouse would still work everywhere on the screen except in the score itself >
I disagree with this point and follow Marc's opinon:
<< if mouse doesn't do what it does now, it should do something meaningful ... move the cursor. Like to start entering notes in a different measure, voice, staff >>
In reply to << the mouse would still work by frfancha
As said above: If you work with the keyboard moving the cursor is easier with the arrow keys than with the mouse anyway (unless you need to move it a very large distance).
In reply to As said above: If you work by azumbrunn
Or even a medium-large distance. Really, for anything more than a single measure in a single staff I could see people wanting to click.
In reply to Or even a medium-large by Marc Sabatella
For moving the cursor around within a score I can see people--including me--wanting to click...but I would point out that when this sort of thing is required, the user is probably no longer in 'input mode', or shouldn't be.
Input mode is used to create new notation in a sequential manner. As soon as a user finds himself needing to jump large distances in a score, he is probably no longer doing straight input, but is more in the 'editing' mode, even if that involves some new input.
Not saying this doesn't happen; I do it myself when 'sharing' a solo melody line among players in a consort. But I'm not really doing 'input' when I get to that point. Most of what's happening then is cut-and-paste followed by necessary adjustments to take the characteristics of a particular instrument into considertion. I am in and out of actual 'input mode' every few notes under those conditions.
In reply to For moving the cursor around by Recorder485
It isn't because in your workflow you don't need it that all others don't need it.
Therefore instead of defining (in what is until now a purely theoretical discussion) the click behaviour in the score as "nothing", why would you refuse to define it as "do something meaningful ... move the cursor" as Marc proposes? Or perhaps I misunderstand and you just want to say "I don't care because personally I don't need it"?
In reply to It isn't because in your by frfancha
I don't think I ever defined the click behaviour in the score as 'nothing'. Nor would I ever say or imply that no one else needs a particular function because I don't.
I was actually agreeing with your earlier proposition that mouse actions which don't make sense in the context of input mode would take you out of that mode automatically. My point was to suggest including moving the cursor around in the score in that category which you defined. Although there are situations where a user would indeed want to stay in input mode after selecting a new cursor location, I think they are rarer than the the other sort. That's all I'm saying.
In reply to I don't think I ever defined by Recorder485
Ok thanks, I understand now.
I suppose that if this would become more a practical discussion than a theoritical one, Musescore dev team will ask the question to know what is prefered for click behaviour in note input mode:
'A'-put you out of input mode and play normal click
'B'-stay in input mode and move the cursor
Both makes senses.
And if 'A' is implemented, one can get 'B' by doing Click followed by [N], if 'B' is implemented, one can get 'A' by [ESC] followed by Click, so the difference is not really huge.
P.S.: About asking opinion of users, wouldn't it be nice if users could vote for features they want the most? Is this kind of thing existing for MuseScore?
In reply to I don't think I ever defined by Recorder485
For me it would not be rare at all. Very commonly I will be working on a score for several instruments, enter notes for a passage of several measures in one instruments, then want to jump back to the first measure of that passage for another instrument down. I can get there now via a combination of keystrokes but this is a very common case where I'd prefer to just be able to click to move the input cursor. Say, from measure 51 in a trumpet part to measure 48 in a trombone part. This sort of thing would happen dozens if not hundreds of times for every score I create.
In reply to For me it would not be rare by Marc Sabatella
Now that you mention it, I realise that I do the same thing whenever transcribing music from a score (which is about half of my input work). I set the music in the top staff until I get to the end of the page on my copystand, then go back to set the second staff, and so on until all the note input on that one page of the source edition has been done. This avoids a lot of useless page-shuffling on a desk which is never large enough (is any desk ever large enough?? ;o)
I guess the reason I never thought about staying in entry mode while mouse-clicking the cursor back to the start of the section I'm working is that as I finish each staff, I immediately save the file, turn off input mode, and then play back what I've written to check if I've made any errors. For me, because I've got a few special shortcuts programmed to the number-pad, none of this takes more than a single keystroke, except, of course, for moving the cursor back to the first measure of that section. For that, I do use the mouse. Yes, it can be done with arrow keys and alt, as has been said, but that's much slower.
For everything else, I use the number-pad or the midi-keyboard. There are four keys on my number pad which are not needed for defining duration during input--the asterisk (now programmed to start and end a slur), the slash (now programmed as the shortcut for "save file"), the minus sign (programmed to toggle in and out of entry mode), and the 'enter' key (programmed to jump to the beginning of the next measure). I almost never have to touch the computer keyboard or the mouse with this system. (It's really cool, btw, that MuseScore recognises the number pad as a separate entity when adding special shortcuts like this. Kudos to whichever developer worked that out. :o)
In any case, you've made your point, and it's a good one. I'd be perfectly happy if this new mouse behaviour allowed users to click on a new cursor location while staying in entry mode.
In reply to Now that you mention it, I by Recorder485
Cool. This is all somewhat hypothetical - I'm not really that convinced a mode to turn off mouse note input *really* is what makes most sense. But there might be other ways of achieving the desired result. For instance, what if you could customize click actions the way you can customize keyboard shortcuts? Or maybe someone really can come up with a good proposal for a more modeless interface in general.
In reply to Cool. This is all somewhat by Marc Sabatella
<< maybe someone really can come up with a good proposal for a more modeless interface >>
It is still boiling in my head every night, be patient ;-)
In reply to Cool. This is all somewhat by Marc Sabatella
Hmmm. Not sure I see disabling mouse note-entry as a distinct 'mode' (feel free to correct me on that, btw), but there is a lot of food for thought in your two additional suggestions.
First: I'm trying to conceptualise how custom click configuring could work other than by having a long list of each mouse behaviour in Preferences, or perhaps a checkbox list to enable/disable each behaviour, somewhat similar to the list one finds in the 'Advanced' tab of the Internet Options dialogue in IE, for instance. Either way could work; and it's not that diffferent from the present keyboard shortcuts menu. Double-click on an item in the list, and a dialogue opens with a field for the input of specific mouse clicks.
But creating an actual custom mouse behaviour seems more complicated. To give users the ability to define their own custom behaviours without learning to write code, would there be a need for a specialised editor of some sort, which would 'interpret' plain text and translate it into code the program can understand? I might write, "Right-click on note during entry selects the note" while another user might write 'Right click note to select in entry mode." Human beings are soooooo difficult.... ;o)
A truly modeless interface, OTOH, seems to me something that would require a different hardware configuration than what we now have. I say this because modes help the program understand what the user is asking for when he hits a particular key, and without modes we need another way to tell it...but there aren't enough keys available on current hardware to assign a unique fuction to any particular key. The keys and mouse buttons must each be capable of sending more than one command to the program. A lot of that is accomplished by using CTL and ALT and SHIFT, and combinations thereof, but if I want to set the letter A as text on the second space of a treble staff, followed by the note A (something one might need to do in a beginner's method book), I need to shift from text entry mode to note entry mode to change the function of the A key.
OTOH, if I had an integrated keyboard which offered separate keys for letter A and note A, I would only have to place the cursor on the right spot and then type one followed by the other.
I don't foresee this sort of hardware being developed, to tell you the truth. While specialty keyboards are built all the time for big users such as fast-food chains (cashier terminals), there is probably not enough market demand for any manufacturer to develop a truly efficient score-writing keyboard. It would probably have to resemble the 'dashboard' of my 1970s phototypesetting machine, which was over three feet wide and contained five separate keyboards/keypads, each dedicated to a separate 'mode' of operation.
In reply to Hmmm. Not sure I see by Recorder485
I agree with the concerns about customizing mouse clicks. In addition I want to especially point out that on MacOS there is no right click. You have to do control click--which is not nearly as convenient. (Say what you want about Microsoft but the right mouse click is their idea and it is brilliant--as is the wheel on the mouse). Apple could have taken over the right mouse button--I am sure it would be generic by now--but they have a philosophy of self sufficiency and circling the wagons, so that is not going to happen.
In reply to I agree with the concerns by azumbrunn
True. Apple is Apple is Apple. Do it their way, or get outta town. There has been, up until recently, a certain element of 'cool' in their stuff for young people, but even among them, that pales quickly enough. I make no predictions as to the future of that company.
For the record, I am NOT a fan of Bill Gates' arrogant assimilation of all that is computering, but the annoying fact remains that his stuff works more often than it does not. Sometimes, much as we might regret it, the 'Big Bad Wolf' turns out to be 'the lesser of two evils.'
Ahhh, I fondly remember the days when IBM was a real player....
this is interesting, the interface might be easier if you were always in note input mode.
then pressed a button that let you select notes.
In reply to this is interesting, the by floydbunsen
You would then have to eliminate either click to select or click to enter note, both of which are very useful.