Up/Down arrows skip diatonic notes for some key signatures

The Up arrow favors sharps. The Down arrow favors flats.

If you want to transpose a selection of notes, then use the transpose feature (Notes > Transpose).

Changed title to more accurately summarize bug.

similar problem

I want to have measure 3 (as notated by Vivaldi), but I got measure 6
I tried to transpose, but the Bsharp never appears.
I tried appending the sharp from the tool bar, which gave odd results when adding this sharp from the left.
So I got the result adding the sharp from the bar, beginning from the right....

To my way of thinking the Up arrow cycle should take the following form:

C,C#,D,D#,E,E#,F,F#,G,G#,A,A#,B,B#,C etc

And the down arrow:

C,Cb,B,Bb,A,Ab,G,Gb,F,Fb,E,Eb,D,Db,C

This would then cater for people working in keys with more than 3 sharps or flats!

This makes the most sense to me.

This sounds good, but I'm pretty sure it wouldn't work well. If you selected a whole passage, then hit up arrow three times to raise the passage three half steps, some notes would end up only being raised two. I suppose an exception could be made in cases where multplie notes are selected. But I'm more and more thinking the "prefer enharmonic spelling" method is really the best way to go, even though I'm sure it too would have unforeseen consequences.

Surely if you want to transpose you should use the Transpose dialogue?

Depends. I'm not talking about large scale transpositions, but rather, things like entry of sequences (CDEC, DEFD, EFGE, etc). Or writing a first trumpet line, then copying it into the second. I use arrow key transposition on short passages like that all the time; much more efficient than using the Transpose dialog. On the other hand, I almost always expect to then be adjusting notes, as it is rarely a literal transposition I want. So maybe those half step discrepancies wouldn't matter. Or the idea of the arrow behavior being different when multiple notes are selected. I guess overall, I just don't like special casing E# and Fb. All it does it lead to trouble, I find.

It might be worth copying the line first and then using the transpose function.

The real problem is that this would break the existing model, in that pressing up 7 times would not go up 7 semitones.

I think it really is important that one person's "feature" doesn't turn out to be another person's "bug". So I think there is an extremely strong case for keeping *exactly* the current system as default. What is needed is the ability to select more sharps 'n flats as required.

As soon as you have more than 5# 5b in either direction, the "semitone move" model breaks, which (probably) means that some cases of moving more than one note will go "wrong". But in practice (surely, at least in my extremely short experience) one wants to shift a particular rhythm pattern up or down, and it almost never fits exactly anyway.

So I still think that my suggestion is good: the current scheme can be called -5 +5; allow customising it to anything (-0 +14 for Scriabin op 42-5, for example).

Although breaking the current scheme seems a bad thing, there is an issue when one of the "high (>5)" sharps or flats is already in the key signature. In that case (as per 'issue') the current scheme does seem wrong. Well, I suppose automatically shifting to -0+7 for 6 or 7 sharps, and vv for flats might be a good idea, but I think the less is done automatically the easier it is to know where you are.

Brian Chandler

An alternative solution would be to add a hot key (a la Finale) which cycles through the enharmonic possibilities of a note.

That is how Finale solves the problem of these enharmonic sharps/flats.

It's simple and doesn't break the existing system.

> An alternative solution would be to add a hot key (a la Finale) which cycles
> through the enharmonic possibilities of a note.

Hmm. Yes, that's an extra feature that some might find useful. But as a way of entering E# it breaks the basic music model, because to enter an E# would require entering an F (if I've understood correctly). But an E# is a sort of E, not a sort of F.

Brian Chandler

I didn't really understand your range suggestion when you first proposed it, because I didn't think it through. So let me see I have this straight. The current scheme creates a certain set of notes on down arrow (B, Bb, Ab, Gb, E, Eb, and Db when starting from "white notes"; A, G, F, D, and C when starting from "black notes"), and you are characterizing this as "-5" because in includes 5 flats If the user changed it to "-7", he would get Cb and Fb instead of B and E. Numbers lower than "-7" would presumably allow for double flats, by making down arrow from the "black key" between G and A create Abb, presumably reagedless of whether the original was spelled G# or Ab? And similarly for sharps (current scheme produces at most 5 sharps, but this too could be customized in your proposal)?

From a technical perspective, I like this a lot. From a user perspective, though, it seems unnecessarily complex. At least, if the user is expected to mess with these settings just to get a Cb. If you make the default -7 to 7 (meaning you could get Cb, B#, Fb, and E#), but also allow overrides for those advanced users who wish it, I think that would be getting closer. Even then, I think rather than needing to set the range directly, it would be helpful to have a simple way to set the range appropriately for the key signature. I am pretty sure the "prefer diatomic spellings" mode could be obtained by setting these to values that could be derived rom a simple formula based on the key signature. "A major", for example, would translate into -2 to 7, if I am thinking this through correctly.

This line of thought suggests that the place for this setting would be in a "key signature properties" dialog. There would be two spin boxes (or whatever) for the flat and sharp settings, and they would default to -7 and 7, but you could set them to whatever you wanted. A "prefer diatomic spellings" button next to the spin boxes would automatically them to appropriate values. Perhaps also a "reset" button to return to -7 to 7.

I'm not sure all this is really worth the trouble, but I am now thinking this is the most flexible / powerful solution and could be made reasonably easy to use. But I'd still settle for just allowing Cb et al (eg, range permanently set to -7 to 7) as a first - and very good - step.

> But as a way of entering E# [a hotkey to rotate through enharmonic spellings] breaks the basic music model, because
> to enter an E# would require entering an F (if I've understood correctly). But an E# is a sort of E, not a sort of F.

I'm not sure it breaks the model so much as serve a different use case. It depends on your method of note entry. For example, if you are using mouse note entry it makes sense to enter an E and then add the sharp with a keystroke. However, if you are using MIDI note entry it makes sense to play an E sharp and then use a keystroke to rotate through enharmonic spellings as needed.

The enharmonic spellings keystroke deserves its own thread/topic because it greatly simplifies MIDI note entry. But let's focus this thread on mouse and alphabetical keyboard note entry, since MIDI note entry depends very little on the Up/Down arrows.

Brian's customization system is innovative but may be too complex for an average user (for example it took several readings of both Brian's post and Marc's post for me to understand it). If the implementation required manual customization for every piece and every key change I suspect it would be bothersome even for advanced users.

The trouble with the current Up and Down arrow method used by MuseScore is it tries to serve two related but competing purposes:
1. Move up and down the staff
2. Add sharps or flats

The current implementation (as of MuseScore 1.1) works okay for simple key signatures and pieces with only "the most common" accidentals. However the current implementation breaks down when you need to add E sharps let alone double sharps (currently E sharps, and any double sharps or flats, require mouse clicks). Adding more sharps and flats distracts from the first purpose (that is, moving up or down the staff becomes slower and requires more keypresses if more sharps and flats are added to the rotation).

Probably the second purpose is more important than the first. I would actually support a default of -14 14, to use Brian's naming scheme. For example, to get a C double sharp you would press C ↑ ↑ and likewise for a C double flat you would press C ↓ ↓.

A different approach is to separate these two purposes into two sets of keys. For example Finale and Sibelius use the Up/Down arrows exclusively for the first purpose: moving up or down the staff diatonically. Sharps and flats are added using a separate set of keys. In Finale C - - gives you a C double flat. Pressing = repeatedly on the C double flat brings you back to a single flat, then natural, then sharp, then double sharp. Although it requires four dedicated keys instead of only two, I prefer this no-compromises, no-customization-required approach most of all.

Yes I would support David's proposal.

Use arrow keys for diatonic movement, and then have a key which shifts up in semitones, one which shifts down in semitones and one for enharmonic changes.

As an ex Finale user I would support the use of the Finale keys for this purpose, but other variations are possible - [SHIFT] [CTRL] and [ALT] or combinations of them together with arrow keys could be implemented.

But given that keyboard shortcuts are customisable, getting the basic model right is the important thing.

The first of the two proposals David made - keeping the current scheme more or less as is, but allowing the range to be -14 to 14 in Brian's terminology - could be OK depending on how it worked in practice. For instance, two arrows up from C gives you Cx, but what about three? If that went on to D, then it would similar to the the current scheme but with one more keypress. One up from B would be B#, two would be Bx. If three up were to produce C#, then selecting a B and C together and doing three up would produce the same results as you would currently get with two up. As long as the algorithm produces that effect - same results as now but taking more presses of the arrow key to get there - then I think this would be fine. I would also note that this proposal is not onconsistent with the idea of eventually adding more control over the range to the key signature dialog, including providing a one-click option to restrict the range to prefer diatomic spellings. Which suggests to me that really, maybe those are the only two options we need - a -14 to 14 option (arrows include all flats and sharps as well as all double flats and double sharps), and a "prefer diatonic spellings" option. Under the hood, though, I very mich like the idea of it being represented as a range.

David's second proposal - separate keys for diatonic motion versus accidentals - I definitely like as a user. No question it would be different, requiring more documentation change thanthe first proposal, I suspect. It would some getting used to for some people, but I do think it would be worth it.

This is an interesting issue. I have given some thought to how the handling of accidentals and enharmonics for note entry could be consistent across all keys.

Firstly, I would like to propose the following design rules:

1. A note on a scale tone is always displayed without an accidental, unless either: cancelling a previous accidental in the bar, or: user forces accidental. This is already true.
2. With alpha keyboard entry, pressing a letter A-G always enters a scale tone according to the key signature in force at the point of entry. This is already true, I think.
3. Pressing up- or down-arrow always changes the pitch by a semitone, as at present; it never just changes the enharmonic spelling on the same pitch. Moving up or down to a scale tone always selects that scale tone. Moving up to a non-scale tone selects the sharpened value of the scale tone below, and moving down to a non-scale tone selects the flattened value of the scale tone above. This is currently only true for all notes when in the key signature of C major / A minor.
4. With MIDI entry, playing a scale tone enters the note according to the current key signature. Playing a non-scale tone defaults to (a) the four "nearest" accidentals, and (b) the leading note for the minor key. i.e. #1 b3 #4 #5 and b7. For example, if the key is C/Am, MIDI entry would give C,C#,D,Eb,E,F,F#,G,G#,A,Bb,B,C. This would enable correct default entry of scales for C major, A harmonic minor, A melodic minor (up and down), and would also enable correct default entry of accidentals for scales in the four nearest major keys: G, D, F and Bb. The same principle would be applied whatever the key signature.
5. Other spellings of any note can be selected if needed by pressing J to cycle through the two or three possibilities. This feature is already in 2.0.

The attached chart shows the effect of the above rules. The scale tones show the notes that would be entered by default by pressing A-G on the alpha keyboard. The notes that would be entered by default from MIDI are shown in bold. For the non-scale tones, the upper spelling is for up-arrow, and the lower spelling is for down-arrow. The b or # on scale tones is normally supplied by the key signature and is only shown explicity if it had been cancelled earlier in the same bar.

This seems to me a comprehensive solution to logical key-centred enharmonic spelling for note entry, and I would welcome comments. I am willing to have a go at implementing it.

I think my ideas are more or less unchanged since my comments above, so it might help to look at them. I have, however, discovered that this commenting system doesn't seem to indent or anything, so for clarity, I'm responding to #18 (Submitted by TonyM-softins on February 2, 2013 - 6:00am.) Also, I'm using 1.1; excuse any temporal idiosyncrasies...

Tony, I think your approach is very good: disturb things as little as possible. There are two main aims:

(Aim 1) Making the system as intuitive as possible for people using simple/conventional notation. So in particular, up to say four sharps or flats notes should automatically appear "right" almost always. You say in point 1. that notes in the scale should be "right"; but this is _not_ true at present. In three flats, select an Anatural, press Up: you get A#, not the Bb it should be. Insofar as this is a change to the present rules, I think it should be made. (Sorry, I forgot: I'm meant to be listing the Main Aims...)

(Aim 2) Making the system capable of Anything, (and Efficiently) for those with the inclination. If you are at least temporarily in D# major (as in Scriabin's wonderful Op. 42/5), then raising an E# should get you an Ex, not an F#, let alone a Gb.

I still think some kind of on-the-fly customization would be a good idea. But I'm not sure the "range" idea is so good; with a -14, +14 range is would mean that going up from E gets E#, Ex, (down a minor 3rd!) Fbb, and so on. I think preserving the "Up really moves the note up a semitone" is a good rule to keep to.

So the question is how to support "respellings". Currently I find I have to paste accidentals onto notes, and there is a curious ambiguity as to whether this is "really" changing notes or just pasting symbols. (I found a bug in the playback, where it just doesn't get accidentals right.)

A key to toggle is fine, but only for Regular users (not the same as Power users: some people want to do fancy things, but far too occasionally to remember that J stands for "respell"). It should surely be part of the note properties (so that just by right-clicking you could find out the toggle key anyway).

But here's a customization suggestion: regardless of the written key signature, you should be able to adjust a "current key" signature. This would help in entering music without a written key signature; e.g. I'm looking at Poulenc's incredibly beautiful "O magnum mysterium" which has no key signature, but is basically in Bb minor, with trips to B minor. By setting the "current key" appropriately, and switching it for the three bars in B minor, you would get almost all accidentals automatically. I envisage a key signature shown in the status area (wherever that is, exactly), not linked to the written key signature. (Aside: I put great store by the promised "non-paginated" option for input, and it just occurs to me this would be useful too in a situation where the key signature had long scrolled off the screen.)

I'm also not too clear on the comment about minor key leading notes. Do you mean that in a blank (Cmaj/Amin) key signature, you would only get G# whether up or down? Not sure this wouldn't confuse as much as it simplifies.

Now the ancillary question: there's a Wikipedia article http://en.wikipedia.org/wiki/Theoretical_key about extreme key signatures: it claims that D# major is "impossible". Well, it's obviously "impossible" if you limit yourself to the standard list of key signatures, obviously not if you don't. Web searches for "D# maj" turns up lots of misprints and confusions... Does anyone know if in fact such key signatures have ever been used by "real" composers? I suppose Scriabin and Alkan would be prime suspects...

Sorry this is a bit rambly, but hope it helps.

I agree regarding #1, which to my mind is really the only point that is really important to address. Current behavior is *not* all that intuitive with respect to the signature, and the behavior of hitting "up" on an A while in a key signature that includes Bb is precisely the issue. While I can see the value of a system where "up" always adds a sharp, I think it's more often the case we'd want it to work diatonically and produce flat or sharp as appropriate to the key. If I want an A# in the key of F, I can always use the palette accidentals of the change enharmonic spelling command.

Away from home on the iPad at the moment, so I won't reply at length. I just wanted to clarify my comment about minor key leading notes that was queried in #19. I was only applying that to MIDI note input as the default spelling for a non scale tone. So if the key signature is C / Am, pressing a G#/Ab on a MIDI keyboard would enter G#, not Ab, as the former is likely to be correct on more occasions.

Action of the Up and Down arrows is completely separate, and would in that situation still give Ab if pressing Down on an A, or G# if pressing Up on a G (if we are in C / Am).

Your idea of an invisible "current key" to govern enharmonic note interpretation, while still displaying the accidentals required by the actual key signature in force is interesting and worth further thought. I would get the proposed scheme working first, and it would then be easier to add later.

Regarding Marc's comment about pressing Up from an A in a key signature that includes a Bb, I think you are agreeing with my scheme. In such a key, the Bb is a scale tone, not a non-scale tone, so would always be shown as Bb when moving up or down, and to get a A# you would either use a palette accidental, or else cycle throught the enharmonics using J.

I'm agreeing with what I think you are porposing, but disagreeing with your statement that "this is already true". Waht we are pointing out is that this is *not* already true.

Regarding #18 / 2
With alpha keyboard entry, pressing a letter A-G always enters a scale tone according to the key signature in force at the point of entry. This is already true, I think.
It's almost true. The correct statement would be.
With alpha keyboard entry, pressing a letter A-G always enters a scale tone according to the key signature in force at the point of entry, and according to the previous accidentals in the measure

Some remarks:

• I'm not a fan of the "temporary invisible key signature approach" from a usability point of view. Same for the
• Adding the concept of major/minor/non standard to a key signature is something that could benefit several parts of MuseScore currently or in the future, note entry, chordnames, musicxml import/export etc... So it could be considered

Regarding lasconics's comment just above. In case you are scatching your head wondering about it, thinking "no, it always enters a scale tone regardless of a previous accidental" - this is something that changed for 2.0 a while back. 1.2 always entered a scale tone, but 2.0 will honor previous accidentals.

Thanks, I hadn't got to that bit yet. I have first been studying the relationships between pitch and tpc in pitchspelling.cpp. I also looked up the original paper referenced there - very interesting. The tpc sequence from Fbb to Bx is amazingly elegant, and should make my proposal very easy to implement, as it is possible to define which non-scale tones to use just by setting the position of a 12-note window relative to the key in force at the current tick.

For example, in C major, for up-arrow, we can use the tpc window:
F C G D A E B F# C# G# D# A# (13 to 24)
for down-arrow we just shift the window along to:
Gb Db Ab Eb Bb F C G D A E B (8 to 19)
for MIDI note input, to get the most common accidentals, we use a window midway between the two:
Eb Bb F C G D A E B F# C# G# (11 to 22)

Then to get the same relative key-centred behaviour in other keys, we just move the windows by the value of key (-7 to +7).

Fix coming soon...

I have uploaded a branch to github for review:

https://github.com/softins/MuseScore/tree/7510-key-based-enharmonics

It works well for me and provides consistent key-centred upDown movement, chromatically and diatonically, and key-based default choice of accidentals when entering MIDI notes.

I would appreciate comments or testing by others before making it a pull request.

https://github.com/musescore/MuseScore/pull/214

Merged. d846e3d0d3 d846e3d0d3

Rather cc27372

Automatically closed -- issue fixed for 2 weeks with no activity.