musescore / MuseScore

MuseScore is an open source and free music notation software. For support, contribution, bug reports, visit MuseScore.org. Fork and make pull requests!
https://musescore.org
Other
12.31k stars 2.66k forks source link

[MU4 Issue] Key signatures not properly applied on newly inserted instruments/staves #15007

Closed cgpqci closed 1 year ago

cgpqci commented 1 year ago

Describe the bug Key signature assigned on score are not applied on staves/instruments inserted after score creation.

To Reproduce Steps to reproduce the behavior:

  1. Create score as of liking
  2. Insert an additional stave on an instrument OR insert another instrument after the score is created
  3. See error

Expected behavior Assigned key signature should also be applied on newly inserted staves.

Video Demonstration

https://user-images.githubusercontent.com/90231404/206094168-dc310cee-4ab9-4e88-8589-b85513493f94.mp4

Platform information

oktophonie commented 1 year ago

Don't seem to be able to reproduce this one (regardless of whether creating from template or not, adding key sig at score creation stage or after, having concert pitch on or off, etc).

MarcSabatella commented 1 year ago

The key is probably something having to do with the current status of the top score in the staff. If it's percussion, or otherwise has a non-standard key signature, that could affect this. Although I wasn't able to reproduce that way either.

But also, I note that is not the RC build. Could be a bug fixed already.

oktophonie commented 1 year ago

I tried this in various builds (RC, latest nightly) and couldn't reproduce it anywhere. The problem sounds suspiciously like https://github.com/musescore/MuseScore/issues/14675 but the PR fixing that issue isn't merged yet so that should have no bearing.

cgpqci commented 1 year ago

Yes, to clarify, I am using the latest nightly build (2022.12.07).

After further testing, I suppose the bug might have to do something about the size of instrumentation(?)

Here's a video creating a score from scratch which reproduces the bug. The following score is with a big instrumentation.

https://user-images.githubusercontent.com/90231404/206229689-d2b12a5a-b10b-4a5a-9fb9-7c6abc1206e3.mp4

Here's the file for this one if it may help. sample_bug.zip

Then here's with a smaller one.

https://user-images.githubusercontent.com/90231404/206231229-c48335f5-610a-420a-b21f-9f6600dcb85e.mp4

And also, weirdly, I cannot reproduce the bug in the score in the video above one more time. Perhaps reopening it or anyways modifying it afterwards might have a bear with it?

MarcSabatella commented 1 year ago

Could be. Could you try using the RC and see if you can find steps to reproduce the problem there? That’s where we are all supposed to be focusing all of our testing on right now.

cgpqci commented 1 year ago

Trying the RC right now. Did all the procedure I did on my previous comment and the bug's still present.

image image

OS: Windows 10 Version 2009, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-223362132, revision: github-musescore-musescore-d050fb0

cgpqci commented 1 year ago

Did another round of testing.

The key is probably something having to do with the current status of the top score in the staff. If it's percussion, or otherwise has a non-standard key signature, that could affect this.

Uhh...now that I've come to this point, this may be the case. However, considering my other previous tests, it seems like it only happens at some extent.

Here's another example where new staves are assigned in Bb major when the score's set in C major. You may note the presence of the transposing Bb clarinet in the score.

https://user-images.githubusercontent.com/90231404/206395720-6d1ca11e-fee7-47ef-a0b6-e34ac1a9606a.mp4

mike-spa commented 1 year ago

I believe this problem was fixed in PR #14849, specifically in this commit -> ff302dcfd82531adf9b706d2fbfdbb7af66596ab . The PR was merged to master yesterday, so @cgpqci it'd be great if you could build the latest master (or grab the latest nightly build from the top of the list list here) and confirm if the issue is indeed gone. @Tantacrul @vpereverzev if we confirm that the issue is fixed in master (and assuming we want to fix it for release), then we would need merge commit ff302dcfd82531adf9b706d2fbfdbb7af66596ab into RC (atm, it has only been merged into master).

cgpqci commented 1 year ago

Testing from the latest nightly build, I can confirm the bug seems to be fixed.

Tantacrul commented 1 year ago

Closing