Note entry using Shift+letter appears unpredictable

How did you enter the 2nd half note? Using Shift 'note name', or Shift 'interval' (below) / Alt 'interval' (above)
I assume the former, and indeed it seems to get added an octave higher that you wanted.
Ctrl-down moves it where you want it. Shift+3 would have put it to the right spot directly.

We used to take the nearest note, not sure why here/now that doesn't happen.

The algorithm has been tweaked a couple of times, I think. The current berhavior is not a bug per se - no matter what we do by default, it's right for some cases, wrong for others, and there will be cases where you need to do the shift. But without remembering the reasons for the changes, I do like the "closest note" algorithm better than "choose same octave", which seems to be what we do now.

The comment in the code suggests the change was supposed to always add *above* the top note of the chord, which would make sense to allow large chords to be built bottom-up. The same code, BTW, works both in and out of note input mode, so it can't completely depend on the idea of the "most recently added note".

But in any case, this isn't working as it is apparently supposed to. There are cases where it adds above, cases where it adds below; cases where the note added is the closest, cases where it isn't; case where it is the same octave, case where it isn't.

I think sorting out a clear statement of what the expected resulted show be - both in cases where we just entered a note to use as reference but also in the cases where we are adding the note later to an existing chord that may already contain several notes - would be helpful.

Timing of this was interesting as I had just starting to look into this myself. What I am finding is that a numebr of aspects of the code really assume you probably want to build chords bottom up. As mentioend, the comment in the code for Shift+letter says it is trying to add above the top note; it just gets this wrong sometimes. But also, the code for just plain A-G (without shift) tries to find the pitch closest to the *bottom* note of the previous chord, regardless of what note is currently selected.

Together, those two algorithms definitely seem to expect chords to be built bottom-up when using Shift+letter. So maybe the best thing is to simply fix Shift+letter to actually do this.

The following code change would accomplish this:

https://github.com/MarcSabatella/MuseScore/compare/45171-shift-letter-o…

I could still see a case being made for using "closest to most recently-added note" instead as it would allow chords to be entered top-down just as easily as bottom-up, but given that the *next* chord you enter would start off with the bottom note by default, I'm not sure you'd really gain anything. I think the best things is to just get used to entering chords bottom up, or else switching to Shift+interval instead of Shift+letter.

Shift intervall adds Bbelow, shift letter above, seems inkonsistent to me.
Alt intervall adds above, what about alt letter?
Would better be made konsistent, even it that means to swap the Intervall shortcuts

Alt+letter is reserved for opening the menu; that's standard behavior across applications you don't mess with. If we wanted to add a command to add a note by letter below, it would have to be somethng else, like Shift+Alt+Letter.

But consider, that command would be exactly the same as simply entering the note above then dropping it an octave via Ctrl+Down. Whereas you cannot do the same with intervals - Alt+3 is not the same as Shift+3 followed by Ctrl+Down. So there is more of a "need" to have separate shortcuts for intervals than letters.

Reversing Shift+interval and Alt+interval is possible to make it more consistent with the intended behavior of Shift+letter, but I suspect there would be screams from existing users who are used to it the way it is. On the other hand, no one else has been complaining about the change in Shift+letter...

Just a comment on building from the bottom: I wonder if it shouldn't be build down from the top? I usually tend to do both, but it seems to me that more often than not, I am building down from the melody.

What do you think?

To be clear - we are only talking about building *chords* here, not sequential notes. Sequential notes *do* use the closest note. When building chords, it is *always* possible to enter them either bottom up or top down; doesn't matter what type of music it is. So either bottom up or top down would work just fine if you actually entered the notes in that order consistently. In fact, the more I think a out it, the more I realize "closest" is actually inferior to either bittom up or top down as an algorithm, because you can't simply enter your chords consistently the same way and expect it to work. With a "closest" algorithm, any time there is a gap of a fifth or more, you will *always* have to use the octave shift regardless of which note you enter first. With either top down or bottom up, you'd never need to need to use the octave shift if you wnter you chord in the correct order. "Closest" will therefore always be less efficient than either bottom up or top down.

So really, it is just a question of which to use - bottom up or top down. I can see it either. Sometimes I am indeed thinking about the melody first and entering notes below. But when I spell chords or voicings, I almost invariably do it bottom up, and so does virtually everyone else I know. So there is clearly a sense in which that is more natural.

Right now, then, I'm inclined to fix it so the bottom up algorithm actually works as advertised - there are cases where it does not.

I too use down/up for that.
:)

What do you mean by "classic notes"? As I said, the bottom-up algorithm is *only* for chords. When entering notes sequentially, it already uses the closest note. So I don't understand what you are saying. Can you post an example showing what you are talking about? Your original example shows chords - chords of two notes - that could be entered bottom up perfectly well.

I still don't understand what you mean by "classic notes" here. What *specifically* are you talking about here in this example? Again, when entering the notes *sequentially*, MuseScore already uses the closest note. It's only when entering the *chords* - in this case, all two note chords with thirds - that the bottom up algorithm would kick in. And if you enter them bottom up, it would work just fine. You could enter this whole passage without ever once needing Ctrl+Up or Ctrl+Down. Although FWIW, it could be entered even more efficiently by first entering the melody in the top staff, then copying to the second staff, then pressing Shift+3 to double the line a third lower, and then copying that to the the bottom staff and using Ctrl+Down once to drop the whole line an octave.

Still, if entering the notes via note entry, I don't see a single spot in here where entering the chords bottom up would not work perfectly. What am I missing?

I'd argue for closest note too, but for different reasons:

- next note (actually next chord) uses closest note, so why should add note to chord behave differently?
- shift-interval adds below, so why should shift-notename add above. Even if we can't have Alt-notename to add above (maybe Shift-Alt for that?).

Ultimately we may want to have a new preferences setting, with all 3 options, Closest, Bottom Up and Top Down, in Edit → Preferences... → Note Entry

Fixed in c68c35c549

At first I was thinking that clsoest would make sense for emntering chords too, for considtency, but then I realized the flaw in that. i tried to explain it above, but I guess I failed.

Consider the following example:

Always following the "closest" algorithm would approximately double the amount of work required to enter this using Shift+letter shortcuts versus what would be required with the current algorithm.

Currently, you enter that very simply:

G Shift+E A Shift+E B Shift+G C Shift+G

As I said, no presses of Ctrl+Up or Ctrl+Down are ever needed. Simply enter the chords bottom up, and it works the same whether the chords are closely or widely space.

Whereas if everything changed to a "closest" algorithm, that same sequence becomes quite a mess to enter. After entering the G, Shift+E would enter the wrong E - and changing the order of entry wouldn't fix it. So either way, you need the octave shift afterwards. If you choose to enter it as G Shift+E Ctrl+Up, this leaves focus on the E, meaning if you then choose to enter the next chord the same way - bottom up - then when you then type "A" to enter the next note, you'd get the wrong A as well, meaning another octave shift to enter it, followed by yet another octave shift after the Shift+E, etc. You end up needing an extra octave shift on virtually every single note.

So I do think there can be no doubt the current system is more efficient; it just perhaps requires a slight adjustment if you are expecting the old behavior.

As for the last example enter the two E's followed by an F, yes, of course if enters the lower F - it expects you to enter the chords bottom up, as I said, so it chooses the closest pitch to the *bottom* note of the previous chord. That is part of the whole "bottom up" expectation that allows this algorithm to be so efficient. If you always enter your chords bottom up. it almost always does the most efficient thing possible, and there is almsot never a need for an octave shift.

FWIW, I do agree about octaves being more common than unisons - at least for the type of music I write - but this has come up before and it has so far been decided to leave this behavior alone. For guitar and percussion in particular, unisons are not all that uncommon. See #11001: Can add same note to chord many times for some previous discussion that touched on this. In fact, that discussion seems to imply it might have been changed (so Shift+letter entered an octave), then apparently changed back.

I'm not at all opposed to changing this, but would want to hear more discussion first.

In guitar, unisons are very common! :)

unisons in the same voice?

Yes, it would happen in any number of common chord voicings, a single strum. But whether they are "common" or not isn't really the issue. Whether they are *more* common than octaves would be the question. I'm not talking about eliminating the ability to create unisons. It's just that right now, it takes one step to enter a unison using Shift+letter, but two to enter an octave (although of course Alt+8 does it in one). We're juist talking about whether it makes sense to reverse this: so instead of needing two steps to enter an octave (unless you use Alt+8), it would take two steps to enter the unison (unless you use Alt+1).

To me, it's a win, as single-voice octaves are more common than single-voice unisons for "most" instruments as well, I think, as when writing for voice. For guitar it might be the other way around, but even so, I wonder if it really is - surely octaves are common for guitar as well?

Fixed in e2eb0cb0dd

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