Dynamics are positioned differently depending on stem direction, and horizontal offset is added on copy and paste

• May 24, 2016 - 21:28

This is definitely headed for a bug report, but I need to figure a few things out first.

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.

dynamics alignment.png

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.

dynamics alignment.gif

In the Inspector, reset the note's stem direction to "Auto."

Now, select the dynamic in the bass clef measure and decrease its vertical offset in the Inspector to -1sp.

Select that measure, copy, and paste into measure 2 in the top staff.

At this point, the dynamic suddenly has a horizontal offset of -.33sp. (Just for fun, flip the stem direction again, and the combined negative offset and changed stem direction start to push the dynamic across the barline.)

In 3.0 nightlies, the same thing happens, but there's the additional factor of the dynamic refusing to approach the barline on the left, no matter the negative offset.

3.0 alignment.png

As stated, there's definitely a bug in here. The question is how much of this behavior is problematic, and how much is by design. Help appreciated.

Comments

• May 25, 2016 - 01:13

I can't say anything about 3.0; I'm still wrapping my head around those changes.

For 2.0.3, it looks like this is by design. According to the code, for upstem chords, the dynamic is centered on the stem (with a small optical correction), but for downstem chords, it is centered on the notehead (see Dynamic::layout() in libmscore/dynamic.cpp). And it looks like this is exactly what is happening. I don't see any specific recommendation in Gould to justify this, so I'm not sure what this decision was based on, but that is the current state of things.

Reply

• May 25, 2016 - 01:41

I don't think that is a bug either. Once you manually position an element, MuseScore tries to preserve that manual positioning, and since the default position is slightly different now because of the different stem stem direction, an additional offset needs to be applied to keep the absolute position (well, relative to the measure) the same. So this too seems by design.

Of course, one could question whether *either* of these design choice are the right ones, and they can certainly be revisited.

Reply

• May 27, 2016 - 17:50

For the "second design choice," I don't think that can be right—if the Inspector specifies that the horizontal offset should be 0.00sp, or the default horizontal position, that should not turn into -0.33sp without the user's control.

Maybe the first design choice isn't a good one, either, as in multi-instrument scores it can lead to raggedy vertical alignment. But the second one is problematic for sure.

Reply

• May 27, 2016 - 18:20

It doesn't *turn into 0.33sp" - this is a new piece of music, and it might require different offsets to achieve the same physical position. The original is of course left unchanged. The question is whether you want the text in the copy to *look* the same on the page, or to *have the same numbers visible when viewed in the Inspector*. museScore chooses the former in this case, and I'd argue that's what most people would usually expect. If there weren't an Inspectoer, it wouldn't even occur to you there was any other possible result to expect.

Reply

Do you still have an unanswered question? Please log in first to post your question.