musescore / musescore/MuseScore

Strange behavior when offsetting linked dynamics

Open
#24,805 1 comment 0 reactions 2 assignees View on GitHub

Nobody has claimed this yet.

needs review regression MS4 UX/interaction
Dominant language
C++
Stars
15.1k
Forks
3.3k
Avg merge
2d 2h
Merged PRs (30d)
91

Description

Issue type

UX/Interaction bug (incorrect behaviour)

Description with steps to reproduce

Current behavior:
Linked dynamics sometimes extremely difficult to drag/offset. Origin of the impedance unclear.

Steps:

  1. Align several consecutive dynamic &/or expression text
  2. Place a slur in notes on the same voice and staff as the attached dynamic
  3. Shift the block up to overlap with the slur.
  4. --> collisions impede the block in puzzling ways. Have to select different elements one after the other to move the block by tiny amounts before it stops and you have to find the next moveable element.

The impedance does not appear to follow any evident logic (such as -say- "the colliding dynamic is the one that is stuck").

Expected behavior
Unclear. First, I think that objects that don't normally collide with dynamics -like ordinary objects (slurs, stems..) on the same staff or in the same voice as the attached dynamic- should not collide with linked dynamics.

The desired behavior is probably unrealistic, given the auto place system and the hidden offsets. But this seems much more squirrely than before the improved-dynamics-alignment update.

Supporting files, videos and screenshots

Arbitrary illustrative task: Shift the linked dynamics upward until they touch the lower line of the upper staff.

https://github.com/user-attachments/assets/72100c0f-494d-45cd-b407-221ba7c4e491

Once I select the first object, I am tapping the keyboard up arrow ↑ rapidly, throughout. Wherever the dynamics are not moving rapidly upward, the selected object will no longer move.

File used is here.
linked dynamics.mscz.zip

Auto-place is on, but this is not a problem for any of the linked objects individually; they do not collide with the slur on the same staff.

What is the latest version of MuseScore Studio where this issue is present?

4.4.2-242570931, revision: 3130f97

Regression

Yes, this used to work in a previous version of MuseScore 4.x

Operating system

Mac OS12.6.6

Additional context

I used a narrow, reproducible example. The problem is not just slurs, but I did not identify a rule. Something like "some objects now improperly collide with linked dynamic, collision behavior puzzling" which is desperately unspecific.

"Worked in previous version" is relative. There are always small issues like this when working with autoplace but something changed in 4.4. Dense sections with busy center space can explode, movements become jerky and unpredictable, or objects just lock down and won't move anymore.

Workaround seems to be to turn auto-place off on everything and make the necessary adjustments (like adding a staff spacer to keep the non-attached staff from encroaching.

Sorry I could not be more specific.

Checklist
  • This report follows the guidelines for reporting bugs and issues
  • I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
  • I have attached all requested files and information to this report
  • I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.