Score Bar is drawn off
Hi. Please see the attached file. The bar here is drawn wrong.
| Attachment | Size |
|---|---|
| baroff.mscz | 19.48 KB |
| Screebshot.png | 50.56 KB |
Do you still have an unanswered question? Please log in first to post your question.
Hi. Please see the attached file. The bar here is drawn wrong.
| Attachment | Size |
|---|---|
| baroff.mscz | 19.48 KB |
| Screebshot.png | 50.56 KB |
Do you still have an unanswered question? Please log in first to post your question.
Comments
Probably one of the multiple cross staff notation issues, see #285233: [EPIC] Cross-staff notation issues
Hmm this one seems a regression in 3.1 Beta 2 and latest master vs. 3.0.5
In reply to Probably one of the multiple… by Jojo-Schmitz
Yes. There are realy a lot of problems concerning multiple staffs. I'm trying to get a quite complicated score done to work with musescore 3.x, but I'm bumping into problems all the time, ending up readjusting things over and over again. I'm not sure if 3.x is already good for production. And I got a slight premonition, that when things are fixed in the software, all the placing and adjusting I do has to be done again. The score was fine, in Musescore 2.3.
In reply to Yes. There are realy a lot… by Allthetones
I am able to reproduce the issue in this score, thanks for reporting. Can you please file an official issue report while I investigate a fix?
In reply to I am able to reproduce the… by Marc Sabatella
So far I can say that the underlying problem here is similar to the one with slurs, in what we are making a decision (on horizontal position of notes and thus the length of beams) at a point where we don't yet know the final stem directions. Even though this specific case worked correctly in 3.0.5 and 2.3.2, I can construct similar cases that fail in those versions. But I'll see to what extent I can figure out a way around it.
Meanwhile, workaround is to take the guesswork away from MuseScore and set the stem/beam direction for cross-staff notes explicitly when you see glitches arise (as opposed to leaving them on auto).
I've seen this, and even made comments about it in the forums. I don't know if there is a bug report for this but I can't recreate it on demand so I haven't made a bug report because it will just be put in the useless "Needs info" status.
In reply to I've seen this, and even… by mike320
FWIW, while it's true we don't tend to look at "needs info" bugs much after ascertaining we in fact need info, it can still be useful to have them, because you never know when someone else will be searching for info on a similar problem they are having and they may be that much more likely to add a comment to an existing issue requesting information that to file a new issue themselves. Sometimes having several people each provide a little bit of info ends up eventually adding up.
In reply to FWIW, while it's true we don… by Marc Sabatella
If I introduce an unreproducible issue, I put it into the forum in hopes that someone else can reproduce it and the issue can be reported. This bug, as I remember, someone else reported. I could reproduce the issue using their score on demand and nothing happened with it. I don't remember if this was in the issue tracker (which I think it was) or in the forum.
I looked but wasn't able to find the issue. It was from sometime after the first 3.1 beta was released, though it could have been much more recent (like mid April).
In reply to If I introduce an… by mike320
Do let me know if you find it. Obviously, I monitor the forums pretty diligently, but I don't always see everything, and if there isn't an an open/active issue, it's easy for things to fall through the cracks.
As it is, I can certainly reproduce this case here, and verify it's connected to the cross-staff beam and the fact that stem directions aren't finalized until after the point where it would have been more helpful. Probably there are other specific cases where you can trigger similar glitches, and with a similar workaround. But it's not guaranteed that whatever solution I come up with for this (assuming I do come up with one, which itself isn't a given) will apply to all such cases. So more test cases would be welcome.
Here's an example, BTW, of a similar situation I was able to make fail on 2.3.2, but it works in 3.05 as well as current 3.1 builds:
It just comes down, when we don't know the final beam position, we'll guess wrong and do bad things, but different versions might guess wrong for different specific cases. The basic reason the wrong case hasn't changed, though - cross-staff beaming works by putting off the layout until much later in the process than would be required to get all of these cases right all the time.
In reply to Do let me know if you find… by Marc Sabatella
I'm not sure we're seeing the same issue.
In the first picture posted here, the 16th notes have a beam that hang off the start of the group of notes. This is very similar to the issue I was talking about. The picture you attached my be the same issue.
When I see this in my scores, I can fix this by reapplying the start beam to the first note of the group, but at some point after that, the distortion returns.
Edit: I almost forgot, there are no grand staves in the scores I've worked on recently and seen this problem, so they are probably different problems.
In reply to I'm not sure we're seeing… by mike320
For the record, my picture is the same basic issue as the original. Both are cases where we calculate the beam length incorrectly (too long, too short - it's incorrect either way) because we guess wrong on the first layout pass about the stem direction of the cross-staff chord and thus make incorrect assumptions about the horizontal positions of the chords.
There are cases other than cross-staff beams, however, where there can be similar discrepancies betwene an initial guess about stem direction and the final decision. One has to do with cases where you manually adjust a beam to be between two notes:
Another is beaming across barlines, which does speak to the possibility that applying "start beam" could be relevant:
My change here does not affect either of those cases; it deals with cross-staff beams only. But I wouldn't doubt there are bugs in either or both of those areas - again, across all versions.
See #289492: [Regression] Bad layout of slurs in presence of cross-staff beams. A fix will be 3.1. It's not ideal, in that really there is no way to both get the proper offsetting of overlapping chords and correct beam drawing in all cases. It's a case of guessing beam direction before the facts are in, and sometimes we guess right, other times wrong, in MuseScore 3 and 2. So, my fix for this involves disabling the automatic offseting of chords in the cases where cross-staff beams mean we have no confidence of guessing right. I see you already applied a manual offset to the chords in this example, which is exactly what you'll need to do in these cases, but at least the beam will draw correctly.