Tie command should only work if next note is exact same note

• Jun 24, 2018 - 02:18
Reported version
S5 - Suggestion

When you select any note in a score and tie it by e.g. pressing "+", MuseScore will step through the notes in the staff until a note of the exact same pitch and spelling is encountered. The note you selected will then be tied to this note. If the note you selected is immediately followed by a note of the exact same pitch and spelling, everything works fine, you get your normal, sensible tie.

If the note is followed, however, by different note(s), the tie-drawing function still continues looking for a note of the same pitch and spelling. This is a startling behaviour for a newcomer to notation software (trust me, I was one just less than a year ago). It is also not quite musically legitimate... in fact, it is completely wrong :-)

Steps to reproduce

"Untitled" score
Enter e.g. c d e c in quavers in the first bar
Leave note entering mode and select the first c
Type "+"

My analysis and ideas

Currently the program would do something like this after e.g. "+" was typed (pseudocode):

Get current note's pitch and spelling;
Get the next note's pitch and spelling;
if ((current pitch == next pitch) AND (current spelling == next spelling))
draw tie;
else move current 1 note on and repeat;

I would propose to make this

Get current note's pitch and spelling;
Get the next note's pitch and spelling;
if ((current pitch == next pitch) AND (current spelling == next spelling))
draw tie;
else give error message "no note on the same pitch found directly adjacent. Please select the first note of the tie";

I am willing to try to see how the code works and try to get a fix out, but don't hold back in fixing it yourself. I would like to try this fix since it seems so easy, but I am still learning C++ and qt form what I remember from high school Delphi programming, from which I dropped out to get more time to spend with music.

PS: under which version should I report? I remember it since 2.1 and everything else is affected.


Score::cmdAddTie(), which can be found in libmscore/edit.cpp, uses the function searchTieNote(), from libmscore/utils.cpp, to find a note to complete the tie. Unless I am mistaken, searchTieNote() works the way it does in order to allow something like this:
I am not sure that this is actually correct notation, but it does look nice. Even so, there are probably ways in which the function could be improved.

It has been proposed elsewhere to change this behavior and allow the "tie over note" only when two notes of the same pitch are selected and the tie command is used. When a single note is selected, then it would tie only to adjacent note with the same pitch. This seems reasonable to me.

It is indeed by design and a good feature to have, but I agree it should require a more explicit action to create these extended ties. I would be OK with requiring the user to select both pitches before pressing the tie button. A possible complication is that right now, we do allow the tie on list selections, it just starts a tie on each selected note. And that's quite useful behavior in some cases. So we wouldn't want to break that. One way to accomplish this would to be careful to only modify the case of exactly two notes selected, same staff, same pitch.

In reply to by Marc Sabatella

I already made a suggestion in the initial thread, in which I posted my initial question, because I felt I had to thank the people that replied.

Since this one is now a dedicate thread, it's a good idea to post my suggestion here for further discussion.

My suggestion is that this behavior could perhaps be a setting in the preferences. I can see how some users might prefer to just select one note and press the + key, to work faster. Other users might prefer to select 2 notes and not worry about an extra tie being added by the software.

I know very little about programming, so I don't even know how complicated it would be to do it that way.


I appreciate the suggestion. To me, though, the need for extended ties is infrequent enough situation I don't think people using it would mind needing to select both notes. And because of that, it doesn't seem worth cluttering up the UI with more preferences. I'd rather just see the behavior changed so that with two notes of the same pitch selected, it ties them, regardless of whether the notes are adjacent or not. Seems that would work for everyone.

In reply to by mattmcclinch

I haven't seen this kind of notation, so if somebody can provide me with an example in a published score, it would be nice. I have seen this, though, but only once in five years of piano studies:
The difference is that the eighth notes are grace notes here.
EDIT: I replied to mattmcclinch's first post, but seems as though something went wrong with the placement of the post in the thread ;-)

The score in which I encountered the grace note broken chord tied to a chord was Arabesque Op. 12 no. 4 by G Karganoff. EDIT: Start of measure 25

IMHO I would find it to complicated to notate such measures with the changes of this request in case by using different voices (if I understand the request correct). (from Mendelssohn-Bartholdy "Three Motets" (op. 39)):


In such a case it should differ between voices.

Attachment Size
tiednotes.png 26.87 KB

In reply to by kuwitt

There should be no change in the behaviour of the program when notating something like that with the change I am proposing. I don't plan on touching existing functionality for tying notes in different voices (except if what you are trying to tell me is that it will be broken if I do what I plan).

I found it useful that typing + will auto-create the next note during note input, but irritating that it would only do so if the entire rest of the stave is empty, and tie wildly otherwise.

If we’re going to have different ways of making ties work, I propose the following:

+ during note input will copy the previously entred (or currently selected, if none) note to the current insert position, with the length selected in the toolbar, and tie it; it will always insert and never tie to an existing note
+ otherwise, if one note is selected, will tie the current note to the adjacent one on the right if they match (I’d suggest that voices don’t matter here, even though for some they might)
• if multiple notes are selected (and match), they are just tied (no matter the voices, or even grand staff?)
• if no match is found, an error message to use slurs, not ties, for different notes is shown (helps newcomers)

This proposal is up for discussion, dismantling, etc. of course, it is just a first draft of how I’d have expected ties to work when I first ran into the… interesting behaviour, combined with those extra/complex ties I’ve seen (and only now realise are probably expansions for using a piano pedal).

In reply to by mirabilos

I propose special casing the situation where exactly two notes are selected with no changes to any other situation. The current behavior is quite acceptable with the exception of when you select two notes and press the + key and get the two selected notes tied, plus a tie from the second note selected to some note later in the score that could be several measures away. All other uses of the + key are what I expect and don't see a reason to change them.

@Louis Cloete: You're right, my example wouldn't be affect from your request. I had in mind, that I could transcribe it in different ways, inside the note input mode and using different voices for the final measure and the measure before, and on the other hand using for the final measure the same voice and tying the notes (of different voices) outside the note input mode.

Both should be possible with your suggestion in this example.

But regardless of this there is still the question, how to handle tied arpeggios. I didn't find much resources, one is: https://archive.org/stream/EssentialDictionaryOfMusicNotation_201303/Es… (for tied arpeggios see page 148)

As other have said, this behaviour is by-design, but I would be happy with the solution where you have to click two notes to form a tie over a "gap".

An alternative solution would be to stop the search at the end of the measure, perhaps also checking the first chord in the next measure, but nothing beyond that.

I get the proposed change when working with multiple items selected.
But just to make sure I can still enter an arpeggiated chord easily: With the proposed change -if I understand it correctly- I would no longer be able to enter the buildup notes and a final chord, select them all and press "tie". It would require me to ctrl-click each pair of a buildup note with its matching chord note to be able to tie them? That seems like a lot of extra and tedious work.

Alternatively, would it be possible to select just the buildup note and then issue a tie command? Perhaps a repeated keystroke of + would then work? Just anything that minimizes mouse interaction.

Ok, after a good night's rest, my thoughts are clearer. So, as I understand the issue, there is only two cases/places where a tie is legal: from a note to a note directly adjacent (in the same voice or otherwise), or to notate an arpeggiated chord.

Thus, I see two possible solutions:

  1. Make the searchTieNote() function smart so that it only works in the following cases:

1.1 If there is a note of the same pitch directly adjacent to the selected note in the same staff.
1.2If the selected note could be tied to a chord AND all the notes between the selected note and the chord also appears in the chord

But this would be complex, tedious and difficult ;-)

  1. Implement shoogle's second/alternative option (to solve my concern of removing the possibility of tying a note to another note six measures further on and jeetee's concern of conserving the one-click workflow) This option gets my vote.

Yes, making one of these arpeggiated chords becomes more tedious if we implement what people are msotly agreeing on. But is this really so common as to be a significant hardship?

I wonder if the people who select both notes to tie generally do so using list selection (eg, Ctrl+click) or range selection (with blue rectangle)? Because another half-baked suggestion would be to handle these cases differently, and in the range case, only create extended tie "within" the selection. So the arpeggiated chord could still be handle using a range selection, and if users trying to select both notes of a tie also use range, they are good too. And we could also do the special case for a list selection consisting of two notes of the same pitch on same staff.

I'm not sure if MuseScore should change anything in that.
The current behaviour allows to easily make what we need.
The only drawback that some see in it is that it allows notation that could be considered as incorrect.
And then? Should we really need to consider MuseScore as a classical music teacher?
Should we really drop simplicity and ease of use to implement a notation controller?
I don't think so, I highly prefer simplicity and consistency (one easy way to enter tie, not several ways depending on the situation).