Tie command should only work if next note is exact same note
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.
Comments
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:
![chord.png]( "chord.png")
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.
AFAIK this is by design
.
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 It is indeed by design and a… 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.
Thanks...
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 I appreciate the suggestion… by Marc Sabatella
I agree Marc. The question is what to do with the case of more than two notes selected (using ctrl+click for example) and they are a) of the same spelling b) some are the same some are different. Leave it as is? That would be fine with me since it's the simplest of solutions.
Sure, why not. I'd special case only two-notes-of-same-pitch-on-same-staff and leave all else as is.
In reply to Unless I am mistaken,… 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:
tie_under_note.svg
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.
In reply to IMHO I would find it 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 I found it useful that… 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.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 ;-)
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).