Add octave shift and accidental to next note
https://musescore.org/en/node/269268#comment-820070
https://musescore.org/en/node/262412#comment-806681
On the off-chance that this takes off...
When inputting notes, it is often impossible to get the note right immediately, so after the wrong pitch is inputted and sounds, it must be modified. My suggestion is to change that, or offer another note input mode/customisation to change that. These would be controlled by buttons and shortcuts for accidentals (as already exist), and for octave shifts.
The use case here should be simple: I don't like hearing or seeing the wrong notes while inputting notes, which happens very often.
Suggestion 1: Modify the blue note input bar. At the moment, there is a blue bar that highlights the horizontal location of the next note. I suggest changing this to show where the next note will be vertically.
Suggestion 2: Include buttons and optional shortcuts for octave shifts. The functionality would be the same as Ctrl+Up/Down, except applying to the next note inputted rather than the selected note. This would cause the blue note input bar to move up/down octaves as well, providing a visual cue.
Suggestion 3: Change the function of the accidental buttons and shortcuts to apply to the next note instead of the selected note when in note input mode. This could break a lot of workflows, so there should be an option to switch the functionality back by those who don't like it. Or just have separate shortcuts for next note accidentals.
The attached image shows a very rough idea of what Suggestion 1 and Suggestion 3 would look like.
| Attachment | Size |
|---|---|
| musescore octave accidental suggestion.png | 67.42 KB |
Comments
In contrast to the augmentation dots, this would work best as something that applies only to the next inputted note and not subsequent ones.
Suggestion #1 is good, it's what we already do for tablature so some of the code exists already, and it fits in with other requests to implement an input scheme similar to some other program a few people are accustomed to (Noteworthy? I forget which).
I don't understand #2, or if I do, I don't think it would be very effective, since a good percentage of the time you don't know in advance that the note entered will be the wrong octave.
Suggestion #3 would definitely not work in the sense of changing existing behavior - far too many people are accustomed to and happy with the current workflow. And options for things like this are seldom a good idea either - it just creates more complexity and possibility for confusion. But brand new "sticky" commands for the benefit of those few who want them could be fine.
Really, though, I'd say if you are that concerned with hearing an incorrect pitch, best would be to use another input method, like the Piano Keyboard window or MIDI, or to simply turn off the sound :-)
In reply to Suggestion #1 is good, it's… by Marc Sabatella
Suggestion 1 was suggested solely to make Suggestion 2 work.
For Suggestion 2, the rules about which octave MuseScore uses are quite simple. Identical to LilyPond's relative pitch mode I think. So shifting the blue note input line around would just be to help the user keep track of which octave shifts they have pressed, and to provide reassurance that the note will sound right when inputted. I could add this to the image if that would make the suggestion clearer.
For Suggestion 3, yes this makes sense. Would you agree that, if breaking existing behaviour wasn't an issue, that accidentals in note input mode affecting the next inputted note would make more sense?
In reply to Suggestion 1 was suggested… by to7m
To me, #1 makes sense with or without #2. To me, #1 suggests a new form of note input mode in which the cursor has a vertical position and is affected by all the usual transposition commands. So, up/down would move the cursor up and down, Ctrl+Up/Down would move an octave at a time, etc. And in this mode, probably the accidental commands would also apply the next note, not current note.
For #3, no, I don't agree that in the current input mode, having accidentals behave differently than they do now would make more sense. It's different, not better or worse, just different. If one is accustomed to other programs in which accidentals work that way it might seem better, but if one is accustomed to programs in which it works the way it does now it would seem worse. All in the eye of the beholder.
Actually, in a very objective sense, the way things work now is better - it's more consistent. Duration commands always affect the cursor (hence the next note) and pitch commands always affect the current one. There are currently exceptions to worry about. Having accidentals behave differently from all other pitch commands would just be confusing. The only way it would make sense is in a brand new mode in which all the pitch commands affect the cursor (hence the next note) rather than the current one.
FWIW, coming from Finale - which works very differently from MuseScore - I found much about MuseScore foreign at first, but after a few weeks I became totally accustomed to it and now Finale seems foreign to me.
In reply to To me, #1 makes sense with… by Marc Sabatella
My only concern with the alternative note input mode is that it could add to the confusion depending on the implementation. But now I think it's the best option.
To clarify, are you suggesting merging my three suggestions here into one suggestion for an alternative note input mode? If so, should I make a feature request on the bug tracker?
Interesting perspective on Suggestion 3. I think there are irreconcilable combinations of consistencies and inconsistencies in any possible configuration. Except an alternate note input mode, that just seems to make sense unless I'm (we're) missing something.
I too am from Finale. I used it to compose and liked it. School made me use Sibelius, college made me use Logic (seriously, for notation :| ), and I still thought Finale was the best. Then MuseScore came along, beat Finale, and got me through uni. RIP Finale era.
In reply to My only concern with the… by to7m
I think it's time for the voice of another user.
As Marc indicated, there are already other input methods that will both play and display the correct note during input, either using MIDI or the on screen keyboard. I do realize that MIDI costs a little bit of money and you are talking about using a free software so you apparently don't want to spend money on that. The on screen keyboard is as slow as the mouse (which only lacks accidentals) so it is not the option I would choose. If proper playback of notes as entered were that important to me I would spend less than $100 on a sufficient MIDI device that would allow me to easily enter the exact note I want.
I think there are more important features and bugs that contributors could be working on.
In reply to I think it's time for the… by mike320
Using a MIDI controller just doesn't seem very practical to me. I've got a MIDI controller next to my computer, but then I still have to use the keyboard for aspects such as note spellings and rhythms. The on screen keyboard would be faster I think.
The cost of the software/controller is irrelevant. I'd happily sponsor my feature requests (as far as I know there isn't a way to do this) if it seemed like something other users wanted, or that developers would want to maintain.
In reply to My only concern with the… by to7m
I share mike320's concern that we really should be careful about adding yet another way of entering notes - we've got quite a few already. But having been on the forums for quite a few years now, I do tend to see certain requests come up consistently enough to be worth considering. And I do think that basically combining the various elements of your suggestions here with certain other suggestions that also come up regular could make sense as hopefully the last new note input mode we would ever need. So sure, feel free to submit an official feature request for such a mode.
But frankly, I do still question the value of this when there are already so many excellent and efficient methods. The mode being discussion is not one iota more efficient than the others, nor does it add a single capability that is currently lacking. I personally would prioritize features that actually enhance productivity, not just give yet another way to do something that can already be done equally well another way. So in that sense, something like the "scratch pad" idea that also comes up seems way more worthwhile to me. And while I usually am the first to point out that playback is secondary to notation in importance, I would say even playback is more important than yet another method of inputting notes if that method has no advantages over the current methods. So I can't see this mode being very high on the priority list.
In reply to I share mike320's concern… by Marc Sabatella
I think I won't create the feature request. If enough people have similar requests in the future they can be directed here, and provide more input for a potentially big feature so that first implementation can be the right one.