Five new keyboard shortcuts
I wish to add five new keyboard shortcuts as these are the only ones I’ve defined myself, in the interest of submitting local changes upstream. Marc Sabatella wishes to discuss them in the forum first.
I’d like to add # for ♯, = for ♮, - for ♭ to change the accidentals, ( to add parenthesēs around the current note or accidental, and ) to exclude the current note from beaming.
I believe these keys will not create problems for QWERTY, QWERTZ or AZERTY keyboard layout.
None of these keys are currently in use, none of these functions are currently mapped to any keys, and I’ve found them essential for speeding up note input.
My reasoning follows; this is copy/paste from the above GitHub pull request, so if you read it there you can stop reading at this point:
I hope the use of #, = and - is not disputed.
As for (, this is the only really mnemonic shortcut for putting parenthesēs around a note or accidental. It does not have a “closing” match, not does anything else fit for ), so why not “no beam”?
Rationale for “no beam”: When entering notes, I’ve never ever had to add extra beaming to what MuseScore did by default (from the TimeSig), only to disable beaming for some notes.
Rationale for using ) for “no beam”: I thought of binding it elsewhere, but since ( was already used by something that did not have any symmetry (“no beam” is my most recent addition) it was available IMHO. And mnemonically it also fits: it “excludes” (put outside the parenthesised group) the note from beaming.
Regarding users: As this will be a mere addition to the default shortcuts, only new users will get it by default, and any old users who already use either of the five keys for anything else will keep their old bindings. As such, it should not, no, cannot get into the way of someone.
In conclusion, I hope these five new shortcuts provide useful — I might be biased but I think it’s clearly better than not having them.
Keyboard layouts might be an issue, admittedly. I’m using US standard QWERTY, but TTBOMK there’s no conflict with DE standard QWERTZ, and from a look at Wikipedia AZERTY should also be unproblematic. UK QWERTY will not have # readily available, but that’s no reason to not bind it regardless, as it will make no difference for them, or is only a tad harder to reach.
Comments
Here are my observations, restated and expanded upon from my comments in the PR:
I do agree most of these particular commands are among the ones most deserving of having default shortcuts defined. But I can't see why we should include "no beam" but not a "beam start" or "beam middle". To me, those three go hand in hand, and if we provide a shortcut for one, we should do so for all three, and have them be logically connected in some way. Possible "auto beam" as well". So I'd suggest finding a set of three or four more related shortcuts for these commands and adding all of these together.
Of the one you list, to me parentheses is far less important than any of the others. Most people probably go hundreds of measures without needing it. So while I'm not opposed to having this, I don't want it to use up a shortcut that might be more usefully allocated elsewhere.
Just because two of us agree these are among the most important commands to add shortcuts for, doesn't mean the entire user community will agree. Some people, for example, may say adding fingering is more common than all of those put together. Other would probably prefer more articulation shortcuts, others still would vote for toggling Concert Pitch or Page / Continuous view, others the voice exchange commands, etc. There are a limited number of "simple" shortcuts still available, it is important we identify the best set of commands to allocate them to, to meet the needs of the largest number of users.
use of #, = and - for sharp, flat, and natural sounds fine in principle, but there are some issues. On US QWERTY, for example, "#" is the same as Shift+3, thus removing the possibility of reinstating Shift+n as the "enter interval below" shortcut. These were removed because it created conflict on French AZERTY I believe, but a future release may well include more locale-specific customization possibilities, and I'd rather we not use up the Shift+n shortcuts for other purposes. Same issue with "(" but this one is less of a concern to me since it is Shift+9, and "enter ninth below" is not something I care about that much. Also, I believe "=" is also Shift+something on some keyboards and potentially creates conflict.
So the bottom line for me, I like the idea of adding a few more default shortcuts, but think it is important to look at the bigger picture and get more input before jumping into this.
If it were me making suggestions for my own purposes, I would say the accidental and beam mode commands would indeed be good, next would probably be the concert pitch and view modes although those should probably be slightly harder to engage inadvertently. Given my concerns about using up any of the Shift+n shortcuts, and my desire to have the beam shortcuts all relate, here's a proposed list, which is good for QWERTY but I have no good insight into other layouts:
' sharp
- flat
= natural
, beam start
. no beam
/ beam middle
\ beam auto
Ctrl+Alt+V toggle view mode (page / continuous)
Ctrl+Alt+T toggle concert pitch mode (T for "transpose")
In reply to Here are my observations,… by Marc Sabatella
I'd like to weigh in support of having at least the top three (sharp, flat and natural) proposed shortcuts here be defaults. These are fundamental to note entry. Having no default at all results in the distraction of having to figure out what reasonable, non-conflicting options exist.
In reply to I'd like to weigh in support… by iancboswell
The "shortcut" is arrow up and arrow down... Always works (and can't even get changed)
In reply to I'd like to weigh in support… by iancboswell
Right. To be clear, you should not normally need the specific accidental commands just to enter a normal accidental - the arrow keys do that. Even to get things like Cb, you can enter the B then press J. The main time you need accidental commands is to enter courtesy accidentals - accidentals not actually needed except to improve readability.
That said, I do find these useful enough that I do often define shortcuts for them and certainly would support having them defined by default to make courtesy accidentals easier. But they aren't "fundamental" to note entry since they are not normally used at all.
In reply to Right. To be clear, you… by Marc Sabatella
Fair point! I suppose it’s not fundamental then, but I use them frequently enough in addition to the arrow key method that it seems so from my perspective.
In reply to Fair point! I suppose it’s… by iancboswell
I have accidentals defined as shortcuts, mostly because when I transcribe symphonic pieces I don't always remember the instrument I'm working on and want to make sure I don't accidentally turn an F# to a G in the key of G when I actually want a courtesy accidental. BTW, I have all accidentals defined (except the new natural+ accidentals in version 3), and use all of them most of the time.
As far as assigning shortcuts to these items is concerned, you can already define them any way you like. I have shortcuts for every item mentioned with the exception of the brackets because I rarely use them. I have beaming shortcuts for all of the options because I fix beams quite often. For example, when entering choral music, each syllable is independently beamed from other syllable. If a syllable has a melisma then normal time signature beaming is used until the end of the syllable. You neglected to mention double sharps and flats. In some pieces these are very common.
I see no reason that MuseScore needs to set a default shortcut for any of the items discussed. If a future verson of MuseScore assigned new shortcuts, I would redefine them to what I'm used to.
In reply to As far as assigning… by mike320
If you have any idea how to map double sharp and flat well, do share. I occasionally encounter them.
I don’t see why MuseScore should not set default shortcuts for the items in question, because this way, new users can just use them, and you’d not even need to redefine them because the new defaults will not become active for existing users like you, so you’d keep your current redefined shortcuts.
In reply to If you have any idea how to… by mirabilos
I use ctrl+r (for repitch) then an arrow key for each of my accidentals - up for sharp, down for flat and right for natural. I use my right thumb to press the arrows between my numeric and alpha keyboards. This allows me to keep my left hand on the notes and right hand on the numeric keyboard for durations. For doubles, I press ctrl+r ctrl-r then an arrow key. This makes sense to me, but I'm not advocating using these as the default. The main reason I did this is because S and B are used up with other shortcuts and I avoid the numbers (#) on the alpha keyboard.
In reply to I use ctrl+r (for repitch)… by mike320
Oh yeah, that reminds me, the repitch and step time commands are two more that I feel should have default shortcuts. These can probably be slightly more involved than one keystroke, but should be pretty simple as well. Now that I know this is an option (eg, since a couple of days ago) I use Ctrl+Shift+R and Ctrl+Shift+N to switch between these two sub-modes.
Something to consider regarding accidentals: in theory, it should almost never be necessary to the specific accidental commands at all. The up/down keys are in most cases all you need, and indeed, due to the subtle differences in how the information is recorded, these are usually the better way to go anyhow. The main purpose of the accidental commands is for courtesy accidentals. For these I now normally rely mostly on the excellent plugin, which I would dearly love to see incorporated into the main code. So for me personally, the accidental commands are not ones I use enough to care about shortcuts for. And a two-stroke key sequence such as you suggest works for me. But I recognize my own use is not necessarily reflective of everyone else's. Which is, again, why I'm glad we are having this discussion.
Anyhow, if we consider the possibility of key sequences, I might suggest that since Ctrl+R already has another meaning I'd rather not mess with, we might consider Shift+R as the trigger for the sequence. It's current used (in theory, probably few people even know about this) as the trigger for the individual rest commands: Shift+R, Shift+Q to enter a "quaver" rest, etc. But I'm fine with letting it double as the trigger for accidentals.
Still, I do suspect enough people will say these deserve top-level shortcuts that we will likely end up going that way, once we decide on good choices.
In reply to Oh yeah, that reminds me,… by Marc Sabatella
Oops, I use shift-R not ctrl-R. It's so automatic I just know it's down there on the keyboard somewhere and don't think about which one I'm actually pushing. I use this while transcribing scores. Because the publishers are so crazy about using courtesy accidentals, I just insert accidentals using key strokes every time. If I use the arrow key, I will invariably turn an unmarked F# to a G. When there are multiple transposing instruments it's easier to not look back at the key signature to determine if it's a courtesy or not. That is what is really nice about options, you can do it how is easiest for you and I can do what's easiest for me.
I never even realized shift-r shift-r inserts a quarter rest. I'm surprised I've never encountered a problem with getting a rest rather than an accidental. I've now cleared those shortcuts I never use to avoid problems in the future. I use the Ctrl-R feature myself from time to time and have no desire to mess with it either.
In reply to Oops, I use shift-R not ctrl… by mike320
BTW, this points out another pretty fundamental difference in use cases that can affect which commands one finds important. If one is using MuseScore to re-copy existing music, you are likely to rely on a slightly different set of commands than if you are composing new music. Accidentals are just one example of this. When composing, I normally use arrow keys because I know full well the pitch I intend for but it may change later and the subtly different semantics of how the arrow keys apply accidentals work better in that scenario. And since I don't have existing courtesy accidentals to reproduce, I can rely on the plugin to add them for me rather than concerning myself with them on the fly. But when copying existing music, the accidental keys do indeed end up getting used more, for the reasons you state. There are also other differences in likely workflows between composing and re-copying, such as when and how one adds my articulations and dynamics, that could also affect how one perceives things in terms of shortcuts.
In reply to BTW, this points out another… by Marc Sabatella
Can you point me to the explanation of this "accidental plugin"? Personally I would like a one-click function called "Add courtesty accidental". I want parentheses around my courtesies, and currently it seems to take four: select note, click accidental, select accidental, click (), whereas a "courtesy" function can work out what is needed, with a styling option for parentheses.
In reply to Can you point me to the… by Imaginatorium
Courtesy accidental plugin can be found here: https://musescore.org/en/project/add-and-remove-courtesy-accidentals
In reply to BTW, this points out another… by Marc Sabatella
Indeed: when I work with MuseScore I mostly type in existing music, so I want “that accidental right now”, sometimes (e.g. the various old C clefs) even without knowing at that point in time which note it is.
The shortcut for sharp/natural/flat should not be two keys because then it’s shorter (although slower, because it needs visual control, and not as universal, because can’t add courtesies) to use the ↑ and ↓ keys, which are suboptimal.
I’ll factor out the courtesy accidental thing into a separate feature request.
Both of you have some points, but I don’t see why that should prevent adoption of this pull request.
The new shortcuts will only be made available to new users, old users are keeping their old custom shortcuts.
In the same manner, should, at some point¹, other shortcuts become available, they will not override then-current users’. This is also valid for per-layout shortcuts, which I agree are a nice thing, but is just not here yet. They will also only apply to new users.
① Especially, the “they’re not in existence yet” point. Perhaps someone’s planning on that, but, as with all OSS work, that doesn’t mean they will materialise within any set short or mid term timeframe. MuseScore could go for several releases before replacements would be available, and therefore I believe adding these now will not hurt, but help others.
As for beaming: I never had to modify beaming except to exclude notes from it, as the per-TimeSig default already took care of anything else, which is why I don’t think they need to be added. They could, though.
As for “possibly not working for some user”: you can never make it right for everyone. For example, I cannot use most shortcuts with Alt in it because one Alt (the physical key, mapped to Mode_switch) is used in my layout to enter umlauts and other funny characters, and the other (the logical Alt mapping) is caught by my window managers’ shortcuts. Does this annoy me? It turns out: no. I could define my own to access the functionality unavailable by such keys, but they don’t hinder me. I postulate that my proposed new shortcuts, in the same vain, hinder nobody using a QWERTY (US), QWERTZ (DE) or AZERTY (FR) keyboard.
In reply to Both of you have some points… by mirabilos
Not sure why you think only new users will get the new shortcuts. They will affect all users who have not already customized their own shortcuts and/or who not do a revert to factory settings after an update to a new version. And at some point, there will be an update that forces such a revert for all users any (probably MuseScore 3). And in any case, new users well-thought out, future-proof, shortcuts just as surely existing users do. So that is why it is important to think through these issues and solve the problems identified. It would not be good to change these shortcuts now then have to re-change them for the next release based on the concerns that we could have - and do - see coming. Once we establish that a set of shortcuts for a set of commands, it becomes more painful to change them in a future release. That's why it is imperative to think about the future when deciding on things like this.
Your experience with beaming helps underscore the importance of getting input from other users. For me, I almost never need to exclude notes from beaming - that's something that probably comes up mostly for people who dealing in choral music, which is not my main focus. On the other hand, the beam start and beam middle commands I use pretty often to fiddle with beaming of complex rhythms involving sixteenths, triplets, etc - issues that probably seldom come up for choral specialists.
As I have said, there are a limited number of "simple" shortcuts available. It is important to allocate them well, by getting feedback from more users on what the most valuable use of them would be.
In reply to Not sure why you think only… by Marc Sabatella
OK, I indeed do almost exclusively choral or vocal pieces.
In reply to OK, I indeed do almost… by mirabilos
The best way to handle beaming of vocal staves is actually to disable automatic beaming entirely via the right-click Time Signature Properties (or rather make no-beam the default) and then manually add beams where needed for tied and slurred notes (melismas). The beaming rules on affect the current staff (unless you make a custom time signature in the Master Palette), so you can keep automatic beaming on for instrumental staves while disabling it for vocal staves.
In reply to The best way to handle… by shoogle
Or simply enter your score without caring about beaming and then run the Traditional Vocal Beaming plugin