Don't move anchor points when hairpin ends are moved
One of the long awaited improvements in version 3.5 is that when a user drags the endpoint of a slur or hairpin, the anchor point now moves to the closest note of MuseScore's choosing. Previously when the user dragged the endpoint 4 measures away there was a red line across the score on screen leading back to the anchor point and the slur did strange things when a system break was entered in the middle of the slur. We've spent years here in the forums trying to explain that dragging is not the way to do it. Finally, dragging works as the USER expects it to!
There are flaws in the implementation though. I wanted to move the endpoint of a hairpin just a little across the bar line to be even with a whole note in the next measure and the anchor point jumped to the end of the measure. I immediately remembered that you could use ctrl+ arrows to adjust the endpoint, so I dragged the end back and used ctrl+the right arrow and the anchor once again jumped to the end of the measure. All of my attempts to adjust the hairpins display failed.
I finally got what I wanted by using invisible rests in voice 2 and extending the endpoint to the 8th rest I put on beat 1. As an aside, this is so much easier than it was before version 3.5. The invisible rests automatically centered themselves on the staff and it didn't matter if the rests matched up with voice 1 rests or notes. It was as though they didn't exist except I could now move the anchor point there. Another fine improvement in version 3.5.
I suggest the user have two options to fine tune the end point of a hairpin or slur (or any of the other things this now affects). I suggest the user be allowed to use ctrl+arrows (as was the case in previous versions) or press ctrl while using the mouse to drag the endpoint without changing the anchor point. The user needs some freedom to adjust the display and a user who will read the manual to learn how to do this isn't likely to misuse it and leave the anchor point 4 measures away.
Comments
I agree, and would go further - I don't think the anchor adjustment should happen by default when using Left/Right keys to adjust. We should revert Left/Right to what they did before, Shift+Left/Right can continue to change anchor.
Also, I feel that when we change anchors using drag, we should somehow try to "snap" to the correct location relative to the new anchor, just as we do with Shift+Left/Right. Otherwise, it's still not something I could recommend d anyone actually do, Shift+Left/Right is more precise. On the other hand, someone inclined to drag hairpin endpoints likely drags other things as well, and we don't snap most other things.
Regarding modifiers to use with drag, one thing to be aware of is Ctrl+drag normally means constrain horizontally, Shift+drag is constrain vertically. So Ctrl+drag to extend a line does, luckily, happen to not cause conflict with that.
In reply to I agree, and would go… by Marc Sabatella
I think ctrl+arrows and shift+arrows should continue to work the way they used to. Shift did what you want a drag to do, snap the end point to match the anchor (which I'll think out loud on in a moment) and ctrl+arrows should only adjust the endpoint regardless of where the anchor is.
Give the user total freedom to shoot themselves in the foot if they want to. There may be a rare case where it would make sense to place the anchor a couple of measures from the hairpin. Actually as I think about it, I've seen some hairpins that span only within a measure, but the rest of the instruments have a long crescendo line that started before and extends the crescendo a couple of measures down the road. I don't think the intention is for the one instrument (who is not a soloist) should stop his crescendo before everyone else.
Should the endpoint and anchor match if the user drags the hairpin? I'm torn, the sudden jump will be unexpected until the user gets used to it. The programmer also needs to keep the mouse on the grab box of the item, so that will be a challenge for the programmer. I'm not sure jumps like this are good. A possible way to handle this is that the endpoint doesn't move until the mouse is released, and then it will line up with the anchor.
On the other hand, in the proposal, a user will have the freedom to move the endpoint without affecting the anchor so it's not terrible for the anchor and endpoint to match after they simply drag it but leaving it where the user released the mouse is probably the more expected option.
In reply to I think ctrl+arrows and… by mike320
Mike, some probably unimportant random thoughts. I can think of maybe three reasons to drag hairpins to a particular position. As an aside, I never use "cresc" in notation software.
No. 3 is interesting because while dynamics in the part serve as a guide for players, the conductor is the final arbiter of when those markings begin and end. Personally, I find that one score can't do all three things above. For example, I might have to add all kinds of things to a score to try and get musical
In reply to Mike, some probably… by bobjp
No one uses every feature of a program, but anchors and end points apply to items other than dynamic change lines, such as almost every element except the ambitus found in the lines palette. I can't imagine anyone not using at least one of the elements in the full palette.
'#3 is of course the main reason for placing a notation on any piece of paper. My example of why I would put a hairpin under a single note with the anchor a couple of measures is covered in #2. This is common for people like me who transcribe PDFs so the scores can be used for other purposes. I like to make them look like the PDF, but the playback to be tolerable, which to date is the best I hope for when doing a transcription. #1 is practically the same as #3 (IMHO).
However, the reasons for using lines and slurs is secondary to what results the user gets in a given situation, and that is the reason I started this thread at Marc's request. This is software that people use.
Having watched the forums since the days of 2.0.3 (I guess that's around 4 years now) one of the most common things people have done wrong in the past is to drag the endpoint of a dynamic or slur to make them look right but never getting proper playback, especially from hairpins. This was only wrong because of programming decisions and the problems it caused at times. In version 3.5 those many users have finally won a victory and can now drag the endpoints to their hearts content and the bad side effects are now gone. However, there are flaws in the implementation, which is what I initially described. In my last response I was thinking out loud, brainstorming with myself and hopefully others interested in this issue, about how to fix the flaws in the implementation. Marc, and the other programmers want feedback so they can make informed decisions. Unfortunately, I'll be surprised if more than 3 people give opinions on how to fix this. Marc and I have already given opinions - that's 2.
To be honest, most of the programmers use the program but not as much as the average user. They understand how the program decides where to place the anchor but may not use the features to fine tune a hairpin's placement like I do. If they did, they wouldn't have implemented it the way they did. I did no pre-release testing, so I didn't catch it until I started using 3.5. This is actually the main flaw that inspired me to return to the forums.
In reply to No one uses every feature of… by mike320
I try not to drag anything. But I just ran into something where I have to. I can't go back to 3.4 to check, but here is what is happening in 3.5. I have a 4/4 measure with a dotted half note followed by (and tied to) a quarter note. I have a "p" under the quarter note. I select the dotted half and select the diminuendo hairpin from the palette. What I expect is for the hairpin to appear under the Dotted half and end at the "p". What I get is the hairpin under the entire measure. I now have to drag the anchor back so the hairpin ends at the "p". I notice that if I drag too far, then the starting anchor moves also. I don't know if all this has always been the case. Or does it have to do with a number of beats for one note dynamics?
In reply to I try not to drag anything… by bobjp
Lines (generically speaking) with a single note selected have been applied from the selected note to the end of the measure as long as I can remember. Hairpins are an exception.
When you drag the endpoint, do you mean you drag the right endpoint (that's under the p due to auto placement)? I tried this and dragged the right endpoint and it stopped moving when I got to the start of the longer note. The anchors stayed where they are. I dragged the middle grab box and the anchors moved.
In reply to Lines (generically speaking)… by mike320
If I wasn't careful while dragging the right anchor, the left anchor would move also. So one measure is the default smallest setting for hairpins.
In reply to If I wasn't careful while… by bobjp
I suspect that you missed the grab box and was dragging the line itself. The line can be as short as the shortest note you put it on. To apply the line to only one note, select the note then press ctrl+click the next note then apply the line.
In reply to I suspect that you missed… by mike320
And that little tidbit is not in the manual in the hairpin section. It is in the section on Lines. I have not read the manual front to back. I read sections as I need them. However in this case it would have helped. It is still interesting to me that by default the hair pin wants to spread across the entire measure unless I define it first. Sure, for longer hairpins I set a range. I just didn't expect to need to in order to apply something to a single note.
In reply to And that little tidbit is… by bobjp
Some lines are usually applied from a note to at least the end of the measure, making the the rule for all lines is not a good idea in my opinion but I'm used to it so I've not ever given it much thought. Perhaps this merits a suggestion (feature request) at https://musescore.org/en/node/add/project_issue?pid=1236
In reply to Some lines are usually… by mike320
P.S. Aside: I was thinking that an attribute for hairpins to end either at the [end-edge of a notehead]/[stem]/[the whole segment of duration (as it is currently by default)] would be nice to have. That way you could do Select all Similar and change groups of hairpins accordingly, or the entire score.
In reply to P.S. I was thinking that an… by worldwideweary
I'd have to understand better how that would work. It would be kind of nice to be able to easily make every hairpin seem to start 1/2 a beat after where it's entered. This seems to be a rather common way I see in older scores. I think this is what you mean. There would be some similar option on the end point though this doesn't seem to be as consistent in scores I've seen.
In reply to I'd have to understand… by mike320
Yeah, I was rather thinking about the end position of a hairpin as a setting rather than manual offsets. Something like the following image:
![hairpinoptions.png]( "hairpinoptions.png")
But also some beginning options would be nice too like [beginning edge of note(as it is by default it seems)/ending edge of note/some user-defined offset]
In reply to Yeah, I was rather thinking… by worldwideweary
You made me remember something I see a lot. The end of the hairpin ends with the note, but it's clear the intention is not to crescendo only the first beat of a whole note like
It's not the best example but it shows the idea of a hairpin that stops at the end of a note rather than immediately before the next note or rest.
In reply to Some lines are usually… by mike320
"Some lines are usually applied from a note to at least the end of the measure, making the the rule for all lines is not a good idea in my opinion"
Yes, it's about what we are used to. And now that I know about it, it helps. But I think that the only line that it might mostly apply to might be Voltas. Which is a totally new term for a US music ed major from the 70's. In that case you have to remember to apply it differently if the ending is more than a measure long. Slurs aren't automatically to the end of a measure, either. I'm not sure there can be a universal rule for lines going to the end of a measure. Unless the universal rule is to define the start and end point of all lines. Which can be done now. However, it can be done two different ways that can yield two different results. For long hairpins , that is. But for my example above, only ctrl+click works. All I'm really saying is that for those who don't do a lot of word processing and/or use keyboard short cuts (or do note input with a mouse, Gasp! No judgement.) it takes some getting used to. Not a complaint, just an observation.
This was a surprise for me. I actually like dragging everything I can, and prefer to keep hands away from the keyboard when I create. I often work on a windows tablet with a stylus and without a keyboard, and I try to do everything from there.
Slurs work perfectly for me - they only change their anchors when you really drag them INTO the noteheads. I won't mind having a (barely?) similar behavior for hairpins and other lines.
As you say, these are too eager to snap on the next segment's end. Maybe they should have a bigger tolerance before deciding you really want to change the attachment (for example, you really need to push it to the END of the chordrest segment). And of course ctrl-arrows should not snap it at all.
In my case, it's a line problem. I am working on a cutaway score, but I want a dotted horizontal line to 'connect' the visible measures (as seen on some contemporary pieces) so I'm doing this by hand - But since the dotted line always wants to snap to the closest segment, as soon as I get closer to the measures barlines, the line ends up with either the start or end anchor points inside an invisible measure and the line turns invisible itself. I expected to be able to ctrl-arrow the tips but it doesn't work anymore.
On other dragging-related issue, I kinda like how you can drag dynamics around and they snap to chords but, is it really necessary that they attach themselves to other staves? I can't see another element that acts like this, and IMHO this gets in the way more than it helps. Unless a lot of people does have an use to jump their dynamics across staves...
In reply to This was a surprise for me… by elerouxx
All but the dynamics has been covered already, so I'll let what I said about lines stand. As for dynamics, it is strange that they want to attach themselves to other staves since this is almost never what you would want. It happens too easily. Perhaps a solution similar to the 75% move for adding notes (@Marc Sabatela) could be applied to dynamics as well. One problem with the dynamic dragging is getting them to a voice besides 1. I do use this to purposely move notes to voice because I can but I would like to be able to drag the dynamic to another voice at times.
The manual (updated for 3.5) specifically states that the arrow keys alone or with [Ctrl/Cmd] are NOT supposed to move the anchor and that using Shift or the mouse is supposed to move the anchor. This is not what happens currently. This sounds to me like it's a bug instead of a new feature.
In reply to The manual specifically says… by EricHVela
I sure thought I had added an issue for this. I have now created #310018: Adjusting endpoints on lines always move anchors which is now linked back to this discussion.
In reply to I sure thought I had added… by mike320
Someone else added it at #309368: Lines: when end handles are adjusted with keyboard arrows, anchor point also shifts
In reply to I sure thought I had added… by mike320
. duplicate