Stems of grace notes protrude beam if quarter is present
1. Open attached score (produced in 1.3).
Result: The stems of the grace notes protrude the beam.
Note: The first three grace notes are 16ths and the fourth is a quarter.
Using MuseScore 2.0 Nightly Build (aeb28a7) - Mac 10.7.5.
Attachment | Size |
---|---|
Stems of grace notes protrude beam if quarter is present.mscz | 1.79 KB |
Stems of grace notes protrude beam if quarter is present.png | 43.31 KB |
Comments
I don't know if this is related?
1. Open attached score (produced in 1.3).
Result: The stem of the quarter grace note is infinite.
Using MuseScore 2.0 Nightly Build (aeb28a7) - Mac 10.7.5.
I think this belongs here?:
1. Open attached score (produced in 1.3).
2. Select a grace note.
3. Change the value to a quarter, or higher.
Result: The stem becomes infinite.
Using MuseScore 2.0 Nightly Build (72d2a5e) - Mac 10.7.5.
The issues in #1 and #3 should be fixed.
I have problems in importing the file in the original report.
The beam of grace note presents in the original file (extracted from the mscz) these parameters:
<Beam id="2">
<StemDirection>down</StemDirection>
<y1>5.63917</y1>
<y2>4.89237</y2>
</Beam>
The y1 and y2 parameters are squeezing the grace notes against the main note in current revision ( f5cfb12dc ). If, after import, you select one the crossed note and press "flip" the layout is correct (and becomes squeezed once again if you re-flip the stems).
By starting ex novo in nightly-2.0 or in 1.3 I can't see the problems of this file.
How were these y1 and y2 defined? Did you customize something in the beaming of these grace notes?
The protruding stems are actually user-defined in the original file by the lines:
<Stem>
<userLen>-0.617608</userLen>
</Stem>
So the bug would be there if they did *not* protrude.
If you (after the "flipping" trick of above) select the stems of grace note and reset with Ctrl+R the stems do not protrude any more.
(Edit: I corrected the > and < for html parsing, now it should appear correctly)
Can we put this issue on fixed?
There is still the bug of positioning/beaming of grace notes when the beam position is customized (but this is a bug different from the one reported here).
The problem seems to lie in
layoutChords1
, which resets the horizontal position of grace notes.The import of this file can be fixed by commenting lines 402,405 and 408 of beam.cpp (as was done for normal chords), so that
foreach(ChordRest* cr, _elements)
cr->setUp(_up);
are always executed. BUT, if then one of the positioning handles of the grace note beam is vertically moved past the notes (so that a flipped mirrored stem is needed), the "squeeze" happens again (because line 1476 of beam.cpp, containing layoutChords1 is executed).
Suppressing the execution of this line for grace notes determines a wrong lateral size of the beam (by which it does not connect to the stems).
Last week I tried to understand where grace notes are horizontally positioned in the code, but I could not find the specific point. In function
Score::doLayout()
this horizontal positioning seems to happen at instructionlayoutSystems()
, which happens afterlayoutStage3()
(which callslayoutChords1
on notes and grace notes), but introducing alayoutSystems()
after line 1476 of beam.cpp// guess was wrong, have to relayout
score()->layoutChords1(c->segment(), c->staffIdx());
does not seem to restore the horizontal positioning of grace cords.
I am at a stall in trying to fix the custom beaming of grace notes. Can someone with more knowledge of the code (Nicolas, Werner) please point me to the lines where the horizontal positioning of grace notes is set?
I can tell you where horizontal position of grace notes is set: in chord.cpp, Chord::layoutPitched(). Here's how the code code looks after a couple of small tweaks I just made (not merged yet as of this writing):