Invisible staves inappropriately factored into note spacing

• Jan 1, 2019 - 15:23
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Once
Severity
S2 - Critical
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
MuseScore
Tags
invisiblestaves

In 3.0 released (3.0.0.20137 Mac Mojave). In the enclosed test case score, the sixteenth-notes in the hidden oboe part are determining the spacing of the visible violin part. This is a regression. This not happening is one of the main reasons for hiding parts.

Attachment Size
test_spacing_hidden.mscz 5.63 KB

Comments

• Feb 20, 2019 - 16:20

This is a really serious problem for me that is preventing me from migrating a family of old scores into MS3; MS2's lack of a usable piano roll editor makes editing in MS2 not an option. Is this in queue to be fixed soon?

Reply

• Feb 20, 2019 - 16:52

There is no official queue, but the occasional bump like this doesn't hurt :-) I agree, should be high priority. With luck it won't be hard to fix, and if I'm right I'll submit a PR.

Reply

• Feb 21, 2019 - 19:51
Title MS3 Hidden parts inappropriately factored into note spacing of visible parts ⇒ Invisible staves inappropriately factored into note spacing

Unfortunately, it turns out not to be simple, at least not for me. There are several places I found where we are doing some aspect of layout on invisible staves unnecessarily and I can save some space (and time!) by not doing this, but the main culprit is the fact that we are looking all the segments one at a time and calculating the space to the next segment even though the segment might not be relevant - it might not have any notes on visible staves. We need to be smarter about which segments we look at in the first place as well as which collisions between those segments we look at, but this gets hard for me to wrap my head around fully.

A side benefit of improving this algorithm is perhaps re-allowing the partial overlap of segments that we were doing early on in 3.0 development but seem to have lost somewhere along the way. That is, the sharp in this passage really need not be forcing extra space between the notes - it is totally possible to tuck it under the previous note:

segment-overlap-2.png

Again, I feel this was working a couple of years ago, see for example the second image in https://musescore.org/en/user/101731/blog/2016/05/01/musescore-3.0-unde…

Attachment Size
segment-overlap-2.png 4.81 KB

Reply

• Feb 21, 2019 - 20:01

One of the main reasons for using invisible staves is to expand ornamentation and other textures that take up real horizontal space. This is a major regression. Given that the ornamentation system is not customizable, the need for invisible staves that have many more notes than the visible ones will persist. Yes, such staves are useful for "performance" and this is "not a performance program", but this is a big step backwards if it remains broken indefinitely.

Reply

• Mar 5, 2019 - 20:29
Status active ⇒ PR created

Might be a bit premature as the code will definitely need review, but I did manage to find a much simpler solution than I originally imagined. Doesn't address the partial overlap / "tuck under" case I showed above, because it doesn't really change that part of the code. Here's the PR to hopefully fix invisible staves:

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

Reply

• Mar 7, 2019 - 20:06
Type Graphical (UI) ⇒ Functional

Problem was measures where the first element was a clef change on an invisible staff, I've fixed that.

Layout using my code is as identical to 2.3.2 as any score ever is, and relevant to the issue at hand, it's better in a few places - measure 25 shows a weird gap in 2.3.2 not present in my version. also my spacing is better in measures 32, 33, 51, probably elsewhere too.

One glitch I still need to fix is the playback cursor jumping backwards a bit when dealing with the content on those invisible staves. Other than that I am feeling good about this.

Unfortunately, your score reports as corrupt when loading into any build based on current "master" build and that causes a few issues. Not sure if they are real corruptions missed by 3.0.4 or "phantoms" being falsely identified by the new "fraction"-based code for tuplets and very short note values. Probably good to start doing more testing of these builds on scores like this...

Reply

• Mar 7, 2019 - 21:28

Good to know the source of this, that definitely explains some things!

As for fixing corruptions, I'm guessing that whether this particular score has "real" issues or not, the nature of the changes in master means there will likely be some scores that have no real issues but are flagged as corrupt anyhow, and those are bugs we will need to fix. For the scores that do have real issues that were simply being overlooked in 3.0.4, not sure what we can do, but this is certainly an opportunity for us to try to fix them automatically.

What would help us is if people would include a nightly build and start loading scores that do not report as corrupt in 3.0.4 and let us know if they are reported as corrupt in master. We should be able to take it from there.

Meanwhile, I've updated my PR (playback cursor glitch fixed too), and included some screenshots showing how measures 23-25 look in 2.3.2 versus 3.0.4 versus with my changes:

https://github.com/musescore/MuseScore/pull/4769#issuecomment-470696092

Feel free to suggest other scores to test with.

Reply

Fix version
3.1.0