Right notehead bracket incorrectly positioned

• Jun 20, 2014 - 17:57
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

Ubuntu Studio 14.04, GIT commit: b4066a7

1) new score
2) add a note
3) click note
4) double click notehead bracket in palette to add bracket
5) double click right bracket
6) left 3 clicks
7) save
8) close
9) reload

Result: bracket has moved much too far away.

Before save/reload:
notehead-bracket-before.png

After save/reload:
notehead-bracket-after.png

This only affects the right bracket, not the left, and only if a manual adjustment is applied.

BTW, I encountered this because I needed a manual adjustment to avoid a ledger line. Might be nice to take ledger lines into account automatically...

Attachment Size
notehead-bracket-before.png 896 bytes
notehead-bracket-after.png 858 bytes

Comments

• Jun 30, 2014 - 04:48

This is basically the same cause as #23990: Dynamics with offset move right after save - call to adjustReadPos() occurring too early in the layout, causing the user adjustment to be applied twice. The problem is on the read, not the write.

Unfortunately, Symbol has no layout1() to allow us to use the same fix employed for 23390, and it would take a little refactoring to make this happen. But maybe that's what we should do.

Or, we could try another approach. I have no confidence this won't cause problems elsewhere, but I do have another fix that seems to work for the cases I've tried:

https://github.com/MarcSabatella/MuseScore/compare/26586-bracket-pos?ex…

The idea is to move the layout() call for the right paren a little later, but also adjust ElementLayout::layout() to not clobber an existing pos() (if I don't do this, then applying the parens to a notehead does not offset the right paren).

Seems though we should probably have a general solution to this sort of problem. Eventually we may wish to do more of this sort of automatic position of elements ("magnetic layout", etc), and the same issue will probably crop every time.

Reply

• Jun 30, 2014 - 16:49
Status (old) fixed ⇒ active

Sorry, but that doesn't really work. It fixes the problem for right parens that have a user offset applied, but it breaks the automatic positioning of the right paren. That's because moving the layout() call after the automatic positioning resets pos() to zero. Specifically, it's the ElementLayout::layout() call that resets pos(). That's why my proposed fix above also changes ElementLayout::layout() to incorporate the existing pos(), although as I said, I have no idea if this is actually safe or not. It also works to simply comment the call to ElementLayout::layout() from Symbol::layout(), but I don't know that this is safe either. I don't know under what circumstances a symbol would actually have any of those properties set.

I could of course submit the failure of the automatic positioning as a separate bug, but I figured it was easier to just reopen this.

Reply

• Jul 15, 2014 - 14:12
Status (old) active ⇒ fixed

I hope its fixed now. I used a somewhat different solution than your proposal. Layout() should by definition set the position and the bounding rectangle of an element. Problem is if that position is changed later as adjustReadPos() must be applied after setting the final layout position.

Reply

• Jul 16, 2014 - 16:29
Status (old) fixed ⇒ active

I don't see any change. User offsets are correctly interpreted as they were in the previous fix, but adding notehead brackets to a note still does not offset the right bracket, so both brackets appear to the left of the note. That is, the initial positioning of the bracket is broken.

1) new score
2) add a note
3) exit note input mode
4) click the note
5) double click bracket icon in Note Heads palette

Result: both brackets appear to left of note

Reply