New shortcut to add tied notes to a previously tied chord
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 In my opinion the present… 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
In reply to Disagree: adding tie by… by frfancha
MS does not know if the duration got changed just before the tie or earlier. Both commands are not linked together. The duration will just be ignored if there already exists a note behind the tie.
In reply to MS does not know if the … by tobik
Of course it knows what you have just done.
It is a program.
Just try ctrl-z to check.
In reply to In my opinion the present… by tobik
5, c, +, right, 4
as you suggest does not give the expected result at all.
5 c 4 c left left +
does it, but is 7 keys instead of the expected 4 keys sequence
5 c 4 +
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
This is by design. See https://github.com/musescore/MuseScore/pull/2179#issuecomment-135482602.
so let's mark as such?
In reply to so let's mark as such? by Jojo-Schmitz
No.
It is not by design.
The referenced post described indeed a legitimate case to ignore the selected duration when hitting the '+' key.
But that case is NOT the same as this present case where one has just explicitly selected a duration.
In reply to You are right, my suggestion… by tobik
Hi Tobik,
Do you mean that the behaviour is different between version 2 and version 3?
Fred
Yes, it is
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 As the person who designed… 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.
In reply to As the person who designed… by Marc Sabatella
" I can say it is by design "
According to Tobik, the behaviour is different in version 3.
The design has changed between version 2 and version 3 then?
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 I think tobik was mistaken… by mattmcclinch
mtmcclinch is totaly right. I rechecked the behaviour in 3.0-dev again and it is the same as in 2.3.2. He is even right in that I have to left input mode to get my described behaviour.
In reply to This does not seem to me… 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.
In reply to " Whether or not a command… by frfancha
I agree. Since it makes no sense to turn this into a chord, ignoring the duration makes less sense.
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 I don't agree. When a… 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 " I don't agree. When a… 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
You don't have to delete, just change. I told you how.
In reply to By the way, I discovered… 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?
Adding a . is a bad example. It's only purpose is changing durations. Adding a tie is 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:
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.
In reply to In the current… by mattmcclinch
@matt,
Great idea. Entering scores, either option is possible.
See https://github.com/musescore/MuseScore/pull/4232.
Fixed in branch master, commit adc9c59bf0
fix #278752: Add tied note by keyboard fails when notes are already present
Fixed in branch master, commit b43fad096f
Merge pull request #4232 from mattmcclinch/278752-chord-tie
fix #278752: Add tied note by keyboard fails when notes are already present
Automatically closed -- issue fixed for 2 weeks with no activity.
Just to summarise. A new shortcut, [Alt] [+] has been added to allow users to add more tied notes to an existing tied chord. For example:
Select any of the notes in the first chord in note input mode, and apply [Alt] [+]: