Elongated note stems by moving beamed note before predecessor (using horizontal offset of *chord*)

• Feb 25, 2016 - 11:05
Reported version
3.0
Type
Functional
Severity
S4 - Minor
Status
closed
Regression
No
Workaround
No
Project
MuseScore

Nightly acf6580 on Win 7 / MS 2.0.2 on Win 10

This is not an operation that a user would normally carry out, but I'm reporting it anyway because it may have some bearing on other similar issues.

Open "my first score", say. Anywhere on the score create two consecutive beamed 1/8 notes. Select the 2nd note of the pair and move it in front of the first note (using horizontal offset in the Inspector). This produces note stems that elongate to the page boundary.

Other similar issues (?):

Long Stems on Beams in ARM
Enormously Long Stems when Using Beams in GNU/Linux ARM
Arch linux ARMv7-A: extremely long stems on beamed notes
Infinitely long stems

Comments

• Feb 25, 2016 - 23:11

Yes you can removed those first 3 issues, they're definately unrelated.

Let me see if I understand your bug report. If I start with:

beamed-0offset.png

Then move the 2nd 8th note left using -3 offset:

beamed-3offset.png

Then using -10 offset:

beamed-10offset.png

Then using -100 offset:

beamed-100offset.png

I'm actually unable to move the beam note before its predecessor, it just gets keeps shifting the beam and stem further right. That's what I see on latest git e666061 on Windows 8.1 x86-64, at least. Is that your issue?

Reply

• Feb 26, 2016 - 11:39
Title Elongated note stems by moving beamed note before predecessor ⇒ Elongated note stems by moving beamed note before predecessor (using horizontal offset of *chord*)

AHA, I can verify bug by adjusting the horizontal offset of the *chord* (not just the notehead element):

infinite_beam.png

Reply

• Feb 26, 2016 - 12:40

I'm thinking about what the "Expected" behavior should be. I think that it is meaningless to have a later chord be displayed visually before an earlier chord. When it gets printed, there is no way to distinguish from the ink what is "really" the earlier chord and what is the later chord. I'm brainstorming how musescore should handle this sitaution...maybe one or both of the following ways:

  1. Prevent the user from adjusting the chords's horizontal offset to be before previous chord. This is problematic, though, because a measure's stretch can be adjusted, and style settings can be adjusted, which would change the threshold. The position of the note head is only determined during layout time. So maybe one of the following are better:
  2. at layout time, if determine that any notehead is going to be before it's predecessor, simply prevent it from being drawn left of predecessor (so at worst, it gets rendered at same xpos of predecessor).
  3. go ahead and display the chord before its predecessor, but log a warnig somewhere or otherwise draw user's attention to the fact that there is something wrong (maybe color it bright red with a warning/error message to console.)
  4. simply don't stem in such a situation
  5. fix stems so have "proper" length, but I still think user should be alerted somehow.

Reply

• Feb 26, 2016 - 12:59

moving chords to before the previous chord in the same voice or behind the following chord in the same voice should probably be prohibited, maybe we can restrict that to beamed notes.

Reply

• Feb 26, 2016 - 13:27

FYI, I've tried out PR #2144, and I still experience the long stem on the moved chord:

pr_2144.png

(unrelated but I get a crash with that PR when I press the musescore screenshot button in ScoreView::updateGrips() line 1246)

Reply