Regression with dynamics

• Nov 4, 2014 - 01:10
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

The following bugs seem to be a regression with a very recent build (tested with MuseScore cf50003 on Xubuntu 14.10).

Bug 1 of 2

Create a piano score and add dynamics. You'll see that dynamics are positioned way too low and shifted left or right.

Example with dynamic f applied to the first note (quarter note) of the score. It's too low and shifted left:

dynamics-1.png

Example with dynamic mp applied to a whole note. It's too low and shifted right:

dynamics-2.png

Bug 2 of 2

Some dynamics let a trace on the screen when they are dragged. Example with dynamic f:

dynamics-3.png

Attachment Size
dynamics-1.png 7.32 KB
dynamics-2.png 1.92 KB
dynamics-3.png 10.36 KB

Comments

• Nov 4, 2014 - 01:18

The position issue only occurs with drag & drop, BTW. Double click still works normally.

The trail issue is probably system dependent - relating to how Qt does font calculations. I don't see it on Linux FWIW.

Reply

• Nov 4, 2014 - 01:24

I have the trail issue on Linux (Xubuntu 14.10), bit it's very recent. I didn't have this problem until today.

Reply

• Nov 4, 2014 - 02:58

See the trail now with fff only.

Regarding the positioning, this is "sort of" by design, I think. I don't totally understand the issue for #37881: Images jumps down when dragging from a palette, but the fix basically consisted of making sure when you do a drag and drop, the position at which you dropped gets honored (it becomes the user offset, so you can see it in the Insepctor)). This same code applies to a few other element types - symbols, dynamics, fret diagrams, chord symbols. So dynamics now honor the drop position too, but the text style for dynamics applies an 8sp offset (that's how far below the top of the staff dynamics normally appear) on top of the drop position. Similarly, dragging fret diagrams now honors the drop position but adds the fret diagram vertical position style setting. Chord symbols are no longer found on the palette by default, but if they were present, they'd have the same behavior.

I think what makes sense is to honor the drop position for images and symbols only, but let the regular positioning work for dynamics, fret diagrams, and chord symbols. I propose changing this accordingly and will submit a PR soon.

Reply

• Nov 4, 2014 - 03:51
Status (old) active ⇒ patch (ready to commit)

The trail issue is unrelated as far as I can tell, and should probably be filed separately. It's probably not particularly new; I don't really see any relevant changes.

Here is a PR for the positioning issue:

https://github.com/musescore/MuseScore/pull/1431

Drop position is honored for images & symbols but not dynamics, fret diagrams, or chord symbols.

Reply

• Nov 4, 2014 - 04:02

The trail issue is unrelated as far as I can tell, and should probably be filed separately. It's probably not particularly new; I don't really see any relevant changes.

So it's probably a duplicate of #13879: Dragging glissando and tremolo from palette produces trail effect. I have the trail problem with glissando for a long time, but what's weird is that the trail problem with dynamics (only fz, fp, fff, ff and f) is very recent. I noticed it today at the same time as the positioning problem.

Reply

• Nov 4, 2014 - 04:30

I almost never use drag & drop for dynamics - there is no reason to normally. And the problem is only "sometimes" visible - I can reproduce it only dragging certain dynamics in certain directions on certain systems. That plus the fact that really have not been any relevant changes lately (certainly none in the last week or so, none I can think of for quite a bit longer) is what makes me suspect it's been lurking unnonticed for longer.

As far as I know, the trail is usually caused by faulty calculation of the bbox() for an element. And in some cases, the fault is with Qt not reporting sizes of objects accurately. When I run with the "-d" option to see the bbox()'s for elementsa, I can see it is off for dynamics starting with "f" - the "hook" at the bottom extends outside the box. Probably the glyph itself has this extending outside the box, to allow it to overlap itself when combined into "ff" and "fff" without needing to rely on kerning. And somehow I guess that is not being acocunted for properly.

Reply

• Nov 4, 2014 - 07:33

For " the trail problem with dynamics (only fz, fp, fff, ff and f)" : it appeared on October 22 between this commit, correct
- https://github.com/musescore/MuseScore/commit/75d9e76576a601598c5466f7f…
and this one, with the trail issue:

- https://github.com/musescore/MuseScore/commit/8019c2846ccd5b79f279f469b…

There were three other commits between the two mentioned above. So, it is related with the second cited commit, or more probably with this one?:

- https://github.com/musescore/MuseScore/commit/aa6b0c8e636a2f5ffeae2a549…

Thanks to open a new issue if necessary.

Reply

• Nov 4, 2014 - 19:39

This fixes the position issue. For the drag trail issue, that *could* be considered a duplicate of the same issue for gliss, but the cause is obviously a bit different, so it probably does make sense to have them separate.

BTW, this could be my imagination, but I think the text change that caused the drag trail issue may have fixed an issue I would consider more serious: #25922: Right aligned text does not align correctly. At least, I cannot currently reproduce on a machine on which I formerly could.

Reply