Dynamics are positioned differently depending on stem direction, and horizontal offset is added on copy and paste
Open dynamics offset problem.mscz in 2.0.3. Everything is in its automatic position. Notice that the two dynamics in the first measure are not aligned vertically.
That, right there, is the problematic behavior. MuseScore currently moves dynamics to the left when the note's stem is down, in an effort to center relative to the stem instead of the notehead.
This is well illustrated if you click the note in the bass clef and press [X] a few times—notice that as the stem direction changes, the dynamic jumps left and right:
There doesn't seem to be any reason for this, and it causes problems—aside from the raggedy vertical alignment in a score, extra horizontal offset may get added through copy and paste (see https://musescore.org/en/node/112596), and even on a single note it does not look as pleasing to the eye.
This is in 2.0.3; in current 3.0 nightlies, the only difference is that a large buffer prevents the dynamic from approaching the barline on the left.
Proposed solution: Modify Dynamic::layout() in libmscore/dynamic.cpp so it will just be centered relative to the notehead.
Comments
Well, here we go: https://github.com/musescore/MuseScore/pull/2659
Probably best for 3.0 only.
New PR: https://github.com/musescore/MuseScore/pull/2668
For reference, here is the discussion which trigger the current behavior https://musescore.org/en/node/12488
Read in particular http://matthewmaslanka.blogspot.fr/2012/02/optimal-horizontal-dynamics-… on why stem up and stem down are different.
Very interesting. I think Werner's https://musescore.org/en/node/12488#comment-84104 is referring to https://github.com/musescore/MuseScore/commit/1805b67, which is the turning point. Certainly it was an improvement, but the one part of it that I do disagree with is the different behavior depending on stem direction.
Some background as to why I'm concerned about this:
As I wrote in my "What's wrong with MuseScore " blog post building up anticipation for MuseScore 3, I started to get really frustrated with layout problems in MuseScore 2 when I was working on my score for "Excellence March ." One particular frustration that I didn't describe in the blog was precisely this issue, except at the time I couldn't track down what was happening.
That is, I could see that the dynamics jumped left if the stem was down, and you can see at measure 5 that I gave up on attempting to line up those mf's (which is one of the problems I aim to solve). But I also just kept finding dynamics that had moved significantly further to the left, for no apparent reason, and I had to reset their positions again and again. It took me until a month ago to identify that it happened after a copy and paste .
I want to see MuseScore get smarter so I don't have to spend time struggling with the layout. This is one place where I can contribute to solve a layout issue. The refinement is very small, but in a large project the amount of trouble saved could be significant. I know it would have been for me.
OK, but I don't see this as a question of being "smart" at all. It's a simple disagreement over what the optimal position is. We do something that is recommended by some experts, you apparently prefer something recommended by other experts. Both appear to be perfectly valid choices. So no matter which we choose, some people will wish we had chosen the other.
See also #116411: regression: crash in dynamic layout, where MuseScore crashes just 2 lines below the code you propose to change
Re: Marc, I suppose the truly "smart" solution would be:
1. Fix the copy/paste issue, so no horizontal difference from default positioning is added unasked;
2. Detect whether there is more than one dynamic at the same segment on different staves;
3. If there is only one, position it as currently (centered on stem if stem down); if there are others above or below, position them all centered on their noteheads.
That would be ideal. But that's well beyond my abilities to figure out, and I would be surprised if anybody else cares enough to spend the time on it.
I agree with the interpretation of "smart" with respect to 2-3. But I don't really understand why you keep seeing #1 as a bug. If you manually adjust the position of something, then MuseScore tries very hard to preserve that manual position even as things are laid out differently in the future (eg, copy/paste). To me, that's a feature. But maybe I still don't understand your actual use case. Better to discuss that elsewhere though, as behavior of manual offset with respect to copy/paste is not specific to dynamics - MuseScore makes the same effort for all elements.
Pull request was closed.
I would also say we need clarification on the extent to which this is actually an issue. I don't see any extra offset on copy/paste in 3.4.2, and as mentioned, currently the different alignment based on stem is by design, so it could really use clarification from an established authority.