Oops, I pressed save instead of preview here are the steps to reproduce:
1) open the attached score
2) click OK
3) the tempo text has moved left, off the page
I'm noticing the following (more steps to reproduce variations of this result):
In a new score, drag a 1/4=80 from the palette to any other measure than the first measure of a system, then open/OK the Page Settings dialog, the result is not so much the tempo text moving, but the whole score scaling slightly smaller.
In a new score, drag a 1/4=80 from the palette to the first measure of the second system (the new score is a treble clef, single staff, it creates two systems in my default setup). Open/OK Page Settings, and the tempo text moves to the end of the first system.
In a new score, if I have a tempo text on the first measure and the third measure, only the first measure's tempo text is affected by this issue.
I'm not having much luck trying to debug this, the visual change happens at the very end, but the value has changed somewhere prior to that. One thing I notice is that if I stick a breakpoint inside void TempoText::layout() (line 248 tempotext.cpp), it seems to get called endlessly when repainting the page. I have to set the breakpoint while the Page Settings dialog is open, or I'm stuck.
Change Page Settings units to inch relocates tempo text
⇒
Layout relocates tempo text
Actually, pretty much any operation on this particular score causes the tempo to move. Eg, click a note hit up arrow.
You can reproduce this in any score by adding a tempo text to the first note then using the arrow key to change the pitch of that note. The tempo text shifts around, often coming back to a different position even for the same pitch.
I don't test master builds yet, but it looks more like the first note is too close to the time signature. The tempo mark seems to be keeping the same distance from the chord symbol.
Good call, Mike. We have a bunch of different settings to control various distance, including new ones for 3.0 to give more control, but there is no specific "time signature to note" setting. In 2/x, this obeyed the "Clef/key right margin" setting, but it doesn't in 3.0 - doesn't seem to obey anything in particular. Probably we should have separate settings to control distance to first note after clef, key, or time signature, but I'd settle for just honoring the existing clef/key setting as we did before.
As explained above I don't believe this belongs under #272132: [EPIC] Text positioning issues. The text is in the exact spot in relationship to the note as in previous versions. The note is in the wrong place.
Tempo relocation on layout is fixed in current master. There is also a style value for distance between system header and first note/rest and tempotext-note/rest. There was also an import bug for tuplet number alignment which you can see in above testfile which is fixed.
Comments
Oops, I pressed save instead of preview here are the steps to reproduce:
1) open the attached score
2) click OK
3) the tempo text has moved left, off the page
I'm noticing the following (more steps to reproduce variations of this result):
In a new score, drag a 1/4=80 from the palette to any other measure than the first measure of a system, then open/OK the Page Settings dialog, the result is not so much the tempo text moving, but the whole score scaling slightly smaller.
In a new score, drag a 1/4=80 from the palette to the first measure of the second system (the new score is a treble clef, single staff, it creates two systems in my default setup). Open/OK Page Settings, and the tempo text moves to the end of the first system.
In a new score, if I have a tempo text on the first measure and the third measure, only the first measure's tempo text is affected by this issue.
I'm not having much luck trying to debug this, the visual change happens at the very end, but the value has changed somewhere prior to that. One thing I notice is that if I stick a breakpoint inside void TempoText::layout() (line 248 tempotext.cpp), it seems to get called endlessly when repainting the page. I have to set the breakpoint while the Page Settings dialog is open, or I'm stuck.
Actually, pretty much any operation on this particular score causes the tempo to move. Eg, click a note hit up arrow.
You can reproduce this in any score by adding a tempo text to the first note then using the arrow key to change the pitch of that note. The tempo text shifts around, often coming back to a different position even for the same pitch.
According to the discussions in the related issues, changing placement in 3.0 is common situation, but not sure whether it is expected or not...
![MuseScore 2: mm72_1_1 2018-04-12 18-02-12.png]( "MuseScore 2: mm72_1_1 2018-04-12 18-02-12.png")
In reply to According to the discussions… by Anatoly-os
I don't test master builds yet, but it looks more like the first note is too close to the time signature. The tempo mark seems to be keeping the same distance from the chord symbol.
Good call, Mike. We have a bunch of different settings to control various distance, including new ones for 3.0 to give more control, but there is no specific "time signature to note" setting. In 2/x, this obeyed the "Clef/key right margin" setting, but it doesn't in 3.0 - doesn't seem to obey anything in particular. Probably we should have separate settings to control distance to first note after clef, key, or time signature, but I'd settle for just honoring the existing clef/key setting as we did before.
Relates to #272132: [EPIC] Text positioning issues
In reply to Relates to #272132: [EPIC]… by Anatoly-os
As explained above I don't believe this belongs under #272132: [EPIC] Text positioning issues. The text is in the exact spot in relationship to the note as in previous versions. The note is in the wrong place.
In reply to As explained above I don't… by mike320
mike320, you can specify the #272381: [EPIC] Tempotext issues directly to link the issue with the tempotext EPIC.
Tempo relocation on layout is fixed in current master. There is also a style value for distance between system header and first note/rest and tempotext-note/rest. There was also an import bug for tuplet number alignment which you can see in above testfile which is fixed.
Automatically closed -- issue fixed for 2 weeks with no activity.