You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I usually keep a separate file for my Piano sketches and my full orchestrations, and what I usually do is paste in the piano sketch from the file into a template files I keep for orchestrating. However on doing it this time, some bars either had ridiculously fat ties or insanely long ones (I have been unable to reproduce the fat ones). This happens only when pasting from one file into another file with multiple instruments. Saving, closing, then opening it again apparently fixes the issue.
Seems to relate to the fact that the destination has a different time signature than the source, causing new ties to be created across barlines. The problematic ties are those on chords with arpeggio symbols attached.
I can thus reproduce the problem in a much simpler case:
new score, treble staff, 4/4
enter dotted half note chord: C-E-G
add arpeggio symbol
copy / paste the chord to the rest on beat 4
Result: even in page view, there is too much space, and one of the ties is drawn backwards.
Issue type
Engraving bug (incorrect score rendering)
Bug description
So I usually keep a separate file for my Piano sketches and my full orchestrations, and what I usually do is paste in the piano sketch from the file into a template files I keep for orchestrating. However on doing it this time, some bars either had ridiculously fat ties or insanely long ones (I have been unable to reproduce the fat ones). This happens only when pasting from one file into another file with multiple instruments. Saving, closing, then opening it again apparently fixes the issue.
Steps to reproduce
Screenshots/Screen recordings
Screen.Recording.mp4
MuseScore Version
4.3.0
Regression
Yes, this used to work in a previous version of MuseScore 4.x
Operating system
macOS Sonoma 14.3.1 (23D60)
Additional context
The bars in question appear to be 96, 102, 110 in the file attached above.
It did not appear to have this issue in 4.2.1
The text was updated successfully, but these errors were encountered: