Add tied note by keyboard fails when notes are already present

• Nov 24, 2018 - 15:16
Reported version
3.0
Type
Functional
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

See also: https://musescore.org/en/comment/871036

Scenario 1 OK:

Empty measure
Keyboard:
5
c
4
+
Expected result = actual result = ok = 1 quarter C tied to a 1/8 C
Scenario 2 failure:

measure with already a quarter C on beat 2, cursor on beat 1.
Keyboard exactly as scenario 1:
5
c
4
+
Expected result: same as scenario 1 (plus a 1/8 c on second part of beat 2)
Actual result: 2 tied quarter c :-(


Comments

In my opinion the current behavior comes in handy if there is just a tie missing. That is, if the second note already exists. Select the first note and press +, voila. You don't have to worry about duration of the existing subsequent note.

You can enter 5, c, +, right, 4 to get the desired result.

In reply to by tobik

Disagree: adding tie by positioning on note and + as you say must be preserved, no question about that.
I don't ask to remove this useful behaviour but to correct the incorrect one I have described where you explicitly select a note length by pressing 4 just before pressing + and this note length is ignored

You are right, my suggestion does not work in MS 2.1.3. I checked with MuseScore 3.0dev.
Instead you can press 5, c, +, q

As the person who designed this behavior, I can say it is by design, but I can also agree there is room for improvement in the design. The trick is in differentiating the cases where this is expected form those where it isn't. BTW, "undo" has nothing to do with the normal processing of note input commands, the code processing a given command has no idea which commands preceded it.

In reply to by Marc Sabatella

" The trick is in differentiating the cases where this is expected form those where it isn't. "
=> agree !
" the code processing a given command has no idea which commands preceded it "
1 - it could as MuseScore is a program and therefore completely able to remember what happened.
2 - it should to be able to behave correctly.
And if you prefer to keep code "clean" by avoiding interaction between the "processing command" code and the "previous commands" stack, you can alter the state when you select a note length to "note length just selected" and any command other than selecting note length would reset this flag.

I think tobik was mistaken about the behavior being different between version 2 and version 3. I tried his original suggestion with version 3, and I got the same result as with version 2. The design has not changed between versions. Possibly he had left note input mode before creating the tie the first time.

This does not seem to me like a very common thing to want to do. I do not see any need for MuseScore to remember that the last thing the user did was to select a duration. Whether or not a command takes the selected duration into account should not depend on how or why or when the duration was selected.

In reply to by mattmcclinch

" Whether or not a command takes the selected duration into account should not depend on how or why or when the duration was selected "
The command '+' took the selected duration into account.
Until Marc identified a legitimate case where it would be better to ignore it and implemented that.
What I say is: if the user has just selected a duration as his last action, clearly ignoring it is wrong and therefore the current code should be refined.

I don't agree. When a subsequent note already exists it is most probably desired to tie the existing note without changing it's duration.

In reply to by tobik

" I don't agree. When a subsequent note already exists it is most probably desired to tie the existing note without changing it's duration. "
??? If you don't intent to change the duration of the next note, why would you explicitely select a duration just before hitting '+' then ???

I understand that you set the duration immediatly before the tie. But is it worth changing the whole logic for this rare case?

In reply to by frfancha

By the way, I discovered this bug while rewriting parts of an existing score.
Because this is the consequence of this bug: it means that you can't rely on the keyboard to enter a score in measures already used, that you have first to delete the existing content

In reply to by frfancha

This result is inconsistent with the rest of MuseScore. If you had two quarter notes, selected the first and pressed the . you would get the same rhythm frfancha expects from adding a tie to it. You would get the same thing if you had a 1/4 rest followed by 1/4 note and added a dotted 1/4 note on the rest. Why should adding a tie be any different?

For the reasons explained (and illustrated with examples) in the post linked above - it is exactly what you expecting when adding to a chord. On the other hand, changing the behavior of the tie button to pay attention not just to the current state of things but to also somehow track the history of what lead to this state - while techically possible, that would be inconsistent, not to mention a much bigger change just for this one corner case. Which, btw, might not even always be the desired behavior - what if you were thinking, I want to change the duration of this note, maybe turn it into half note, no, scratch that, maybe into a dotted quarter, hmm, - no wait, I see there is already a note of the same pitch just to the right, I'll just tie to that. Which today works, but wouldn't if we started second guessing thing like this.

So I will say again - I can agree there might be specific cases where the current logic isn't ideal. Let's look at how to identify those cases for what they are, not how we might be able to guess intent by looking at the user's past history.

Examples of ways to distinguish the cases that don't rely on maintain addition state about the past:

  • is the note being tied from part of a chord of multiple notes?
  • is the note being tied to part of a chord of multiple notes?
  • are there other ties from the current chord?
  • are there other ties from the next chord?

etc.

In the current implementation, when a tie is added where there is an existing chord, MuseScore performs an action that can be described as "Add new tied note to existing chord". This is a very useful action, but it is not always the one that the user would like to perform. I propose that we separate this action from the regular tie function, and give it its own shortcut. Maybe Alt+, since Shift+ wouldn't work and Ctrl+ is taken.