Shortcuts and their implementation
In compiling a small list of desirable shortcuts that are not currently implemented, the first set are as follows:
-
Transpose up/down (of current selection rather than the entire score).
-
Diatonic pitch up/down (with the addition of retaining accidentals like how the option is provided in the transpose dialogue).
-
Cycle between the page views of: Page-Width, Whole page, Two-pages.
-
A new set of shortcuts to apply accidentals afterwards that don't 'toggle'.
...and slightly different since it's not a shortcut but a fix:
+ Apply currently toggled accidental to interval functions (add interval [x] below/above)
Some open issues are in the tracker for these, but not much of a discussion or feedback has been active about them, so I figured I'd take a look at the code to see if it would be easy enough to implement, as these would be useful for me personally.
In researching, I've found something quite strange. One request that hasn't been implemented yet is to apply the currently toggled accidental to the [add interval] functions. Since MuseScore changed the way the user is to apply accidentals (must be toggled before-hand rather than applied afterwards), the ability to appropriately add intervals to a chord has been broken since the user can't apply an accidental afterwards during note-entry, and so alternatively semi-tone pitching up/down or exiting note entry to apply an accidental becomes required.
While looking at Master branch of MS3 code, mscore/shortcuts.h & cpp states in the comments:
1) sc[], an array of Shortcut: contains the default, built-in data for each shortcut
except the key sequences; it is initialized at startup (code at the beginning of
mscore/actions.cpp)
yet there is no mscore/actions.cpp file. What is found is cmd.cpp which contains a mapping between the shortcut names and their actual c++ function calls (the above mentioned comment is probably outdated or something). The weird thing here is that, for instance with the interval shortcuts, in mscore/shortcuts.cpp is defined "interval1", "interval2"... and "interval-1", "interval-2" as above and below intervals respectively, yet the cmd.cpp file doesn't contain the mapping between these shortcut names and the actual functions! It does for most of the other shortcuts, but not these.
And so I tried a global project search for "interval1" for example, and, to my surprise, there is not one other instance of these interval shortcut names (e.g. "interval2") except their declaration in the shortcuts.cpp file! How is this possible? It makes no sense to me how it works, as it seems logical that there must be some mapping of these shortcut names like "interval-1" somewhere to initiate an actual function call, but I can't find it even after doing an entire project search for the tokens such as "interval1" and "interval-1". If anyone knows some information about this, it would be much appreciated.
Comments
Not sure what you mean by some of these - aren't there already transpose commands? And what would the point of a "diatonic" transposition that also includes accidentals? Seems a contradiction. Also, there is an outstanding PR already for accidentals add interval - see https://github.com/musescore/MuseScore/pull/5511. I do like the idea of a shortcut to get me to "page width", but I'm not sure making it cycle through other sizes makes sense really.
As I've mentioned elsewhere, I kind of thing one new command to "apply current accidental retroactively" beats five new ones to apply them separately (eg, apply flat retroactively, apply sharp retroactively, apply double-flat retroactively, etc). And there is a PR for that - https://github.com/musescore/MuseScore/pull/5505
BTW, for the interval commannd, instead of searching for "interval1", try without the "1" - we actually compare the string for startsWith("interval"). You'll find the command gets parsed in scoreview.cpp then handled by cmdAddInterval() in cmd.cpp
In reply to Not sure what you mean by… by Marc Sabatella
Thanks for responding, Marc.
The latter [transpose up/down] performs a transpose (augmentation/diminishment) up/down upon the entire score and changes the key signature not at any one selection, but at the beginning of the score and at any explicit key signature changes throughout. I desire the functionality of the transposing up and down action but only upon a range selection with the key-signature change at the beginning of the selection without having to enter into the dialogue area.
will keep the "spelling" untouched, useful especially for personal experimentation of intervals and chord spelling. The functionality already exists in the transpose dialogue as shown, which means it should be fairly easy to implement. It would be decent to be able to switch, e.g., a chord like A-C-E-G# to B-D-F-A# by using a quick shortcut.
And finally, thanks for the tip. It's the parsing that didn't get seen from looking at the shortcut.cpp and cmd.cpp files. Obviously there has to be something like parsing going on, but I didn't find it upon first attempt! scoreview.cpp indeed contains the function, but it looks like if there's a P.R. for applying the toggled accidental to an interval then I don't need to spend time anymore time trying to understand and implement it (except for some fun I'll further check how the code is doing what it's doing). Thanks for the link.
It sounds like the only thing worth pursuing on this side for my purposes is the key transpose functionality + the diatonic transpose with accidentals. 'Later.
In reply to Thanks for responding, Marc… by worldwideweary
Oh, and as for the retroactive application... I see how one command would be useful and re-enforce the default toggle method. Now that I think of it, I'm not sure it would be a bad idea to have this be a preference setting instead of any new commands at all. Like, have a preference that read such like [Accidental behavior: Toggle / Apply]. That way, no new shortcuts would need to be defined, MuseScore could be kept as default with toggling accidentals, and if for some reason someone wanted to apply accidentals after note entries like with the older versions, they could switch it. I can't imagine someone wanting to have toggle ability but then on occasion want to also add accidentals afterwards. It feels like a "one or the other/all or nothing" preferential difference, as you mentioned slightly in the sense that the PR is for the "realizing too late" aspect of retroaction rather than a particular style of input.
In reply to Oh, and as for the… by worldwideweary
In general, MuseScore tries to avoid having the same command do different things depending on a preference -separate commands are usually preferred. For good reason, I think. Simplifies support, simplifies documentation, and make things more flexible as both behaviors are available to all.
In reply to Thanks for responding, Marc… by worldwideweary
Oh, so you're saying you want to leave Transpose alone, but to improve Transpose Up/Down to work on a selection? That's presumably a simple enough change - probably a matter of deleting the cmdSelectAll() within transposeSemitone(). Apparently that's been there since day one, maybe there was no underlying support for partial transposition back in the day, but I imagine it would work fine now.
I'm still not really understanding your use case for the transpose while preserving accidentals. So, in the key of C major, taking a chord E-G#-B up will yield F-A#-C, and this is something you do often enough to want a shortcut for?
In reply to Oh, so you're saying you… by Marc Sabatella
Right, with the additional specification to have the key-signature also be affected if it's part or at beginning measure of the range selection. It seems slightly backwards in my opinion as it is right now: i.e., the dialogue should be used for a full score change or range selection, and the shortcuts up and down should be for range selection only. It's a big 'change' to use a shortcut and have an entire score's key be shifted, but again, just my opinion.
As for diatonic transposition, the phrase the dialogue-box uses is: "Preserve degree alterations". I think that might be more correct than what I initially termed "keep the accidentals". No, this isn't something done often so that now I'd like a shortcut for it, but I would use it if I had it. It's more true to say I've "thought about it often" more than actually doing it.
Update:
Got the [transpose up/down] to work as desired. Marc was right about the cmdSelectAll() needing to be removed, with the addition that the else clause be also removed due to its deselecting after transposition, which isn't to be desired when dealing with a user-defined range selection.
Got a [diatonic pitch up/down + retain degree alterations] implemented as shortcuts. This one was a little weirder to implement but not too bad.
Got the Page-width shortcut working also.
Maybe should create pull-requests for these soon, as they're simple enough yet could be useful, especially the [Page-width] option for the general user.
Now about the "aftermath" accidentals ... not sure if we should stick with Marc's retroactive single applicator or an alternative [5]-action set? In a sense I don't even care once the P.R. for application of accidentals upon intervals is implemented since I'm getting used to the toggle-mode :)
In reply to Update: Got the [transpose… by worldwideweary
Excellent! Regarding the selection during transpose up/down, probably best if you keep the select all and the deselect for the case when nothing was selected to begin with. You'll see a number of other commands do similarly.
I'd recommend submitting these as separate PR's (so, on separate branches) so they can be considered separately.
I personally still use the arrow keys mostly for accidentals, and use the plugin for courtesy accidentals, so I don't really have strong feelings about the best way to improve the toolbar experience. But I do also like the suggestion of a single key to calculate and add an accidental to the current note. So if you're in the key of D and you just entered an "F" (meaning it's really F#), hitting the shortcut would add a sharp. But hitting it with an actual F selected would add a natural. I doubt that's hard to implement either but would require maybe a little more knowledge of the internals to pull off.
In reply to Excellent! Regarding the… by Marc Sabatella
Hey Marc,
I have mixed-emotions about the command to affect the full score transposition by a semitone up or down. You're right that many commands in the code do this (select the whole score if nothing is selected), but related to actual keyboard shortcuts, this isn't something usual based on my experience. I'm trying to think of some other shortcuts that affect the entire score if nothing is selected... and after seeing how this works well with just a range selection, I get a little cautious about this being score-wide as a function, even though I realize this is how it has been for so long since I've seen the shortcut as available, I've never actually used it that way and only resorted to the dialogue box when doing so.
I wonder if anyone would be willing to give any opinions or observations about this? Haha, maybe we're the only ones viewing this thread. Either way, code wise it's really easy to choose one or the other, so it's not difficult to implement, but I'm curious to know if anyone would have any "two-cents" about this. I don't like the idea that I can accidentally not have a range selection due to clicking the mouse or something and then have a score-wide semi-tone transition through a shortcut, but maybe I'm just being a little overly-cautious, and I'm a little biased because I never used these shortcuts for a score-wide semi-tone transposition.
If no more feedback is given by others, I suppose I'll just do a P.R. with the full score version also working if nothing is selected, but currently my personal opinion is to keep the shortcut to be confined to local user selection, but it's merely my personal preference.
In reply to Hey Marc, I have mixed… by worldwideweary
Also, it should be noted that the reason there is no longer a default shortcut for these commands is too many people were hitting the key accidentally. But anyhow, lots of commands that are accessible by keyboard do this select-all, including the main transpose command, the explode/implode commands, the add/remove system breaks command, etc. So in principle this is no different. But those examples are dialog-based, so you have an out.
In reply to Also, it should be noted… by Marc Sabatella
Yeah, the main transpose and add/remove system breaks for example open a dialogue. The implode/explode tool looks like it requires a user selection. I just tried it without anything selected and nothing happened, but it of course works when the user has a range selection active.
Oh by the way, not attempting to be argumentative of course, but as per toggling ability related to Page-width/Whole Page/Two Pages instead of page-width as a single command, I also have mixed emotions. On the one hand, keep it simple so that it looks to the user as another option like the [zoom to 100%], i.e., [zoom to Page Width]. Yet, on the other, there is a toggle shortcut for Page view and continuous view that cycles between the two called [Toggle 'View Mode']. It's the existence of this shortcut that seems to me to slightly justify the idea behind having something like a [Toggle Page Width / Whole Page / Two Pages] command. It would be easy to implement, but if it is against any sort of ideology or trends, I don't want to attempt to integrate it if it wouldn't fit right. Unfortunately, the forum doesn't seem to be filled with many opinions about these things to base the choice off anything. It's probably just a safe bet to have it as a single command.
P.S. Was unaware that there was a time where the transpose commands had default keys. Probably before version 2.0.3 (I think that was when I began getting into notation).
In reply to Yeah, the main transpose and… by worldwideweary
Weird that explode/implode don't work without a selection, I thought that was there, but now I see they return immediately. I guess that makes sense, it's unlikely to do what you'd want/expect anyhow.
My reservation with the "toggle" on the zoom settings is that it's only a "partial" toggle, going between three of many options in the dropdown. Even though I totally get why these three are "special", somehow it still doesn't feel right. I'd feel better about a toggle between "page width" and some given fixed size - either the last-used size, or maybe 100%. In fact, here's a though - what if Ctrl+0 were that toggle? It already takes you from anything else to 100%, it could conceivably take you to Page Width if already on 100%. Or not, just a thought.
I forget how long ago the transpose shortcuts were removed (they were F2 and Shift+F2), it's been a few years for sure but I might have thought it was post-2.0.3.
In reply to Weird that explode/implode… by Marc Sabatella
I really like that idea of toggling the last-used size, since that means the user could toggle back and forth between page-width and a zoom size that the user was using previously when zoomed-in. If a user zooms in to comfortably work on some close-up details, having the ability to jump back to page-width and then later back to that zoom level immediately the next time such a close-up is desired would be really slick, all with the same shortcut. It would be easier though to make the 100% be a toggle, and it also seems logical enough. Many options, all having their strong points...
Maybe some aspects of this topic should be brought over to the general forum or something in hopes that some users would give their opinions.