Page settings unresponsive in "Page view"
See attached file:
Go into page settings and try to adjust the page margins. It's almost impossible when the score is in page view. The controls are very, very slow to respond. It seems to improve in "continuous vew".
There is some fingering added to the score. Could this be causing the bug?
Attachment | Size |
---|---|
page_settings.mscz | 49.78 KB |
Comments
Slow yes, but "unresponsive" or "almost impossible"?
I don't see an improvement when being in continuous view.
I guess that the preview is what's causing that delay.
It's as I said, very unresponsive. MuseScore 2.01. Win 7 Home premium.
Can you be more specific? I tried the top, left, and right margins and had no difficulty. Whether I typed into the box or used the spin box, the controls responded instantly and the page preview updated instantly. That was in page view. Continuous view also responded just fine, although the preview update obviously doesn't completely reflect thsoe changes.
Do you see the slow behavior only with this score>
In reply to Can you be more specific? I by Marc Sabatella
My depend on the hardware? It surely isn't instantly for me, but not unresponsive either, just slow, even pretty slow, like up to 2 seconds delay per click, sometimes less
I've seen this behavior since quite a while, when changing the space setting.
In reply to Can you be more specific? I by Marc Sabatella
It was working instantaneously for me, too.
I have only done a few scores, but I don't remember having problems with the others. Specifically the problem is that the numbers in all the page margin fields (in page view) are very slow to change whether using the spin controls or trying to click and enter numbers directly.
However in continuous view it was easier to change the side margins than the top and bottom (if I remember rightly).
Surely it makes sense to provide an option for the user to turn off "real time preview" if it does not work properly on his/her system – replacing it with a generic preview that makes minimal demands on the computer's resources?
In reply to Surely it makes sense to by geetar
At this point, I don't think we know for sure the preview is the issue, although of course it seems plausible. But the preview is just a small view of your score, and updating it should not take longer than any other update of your score. On your system, do simple edits to the score (adding a note, say, or clicking a note then pressing Up arrow to change pitch) also take a long time? If edits are fast but this dialog is slow, it's harder to see how the preview could be the problem. I guess you could try setting a very small zoom value to match the preview and then trying an edit?
I've just remembered that there is one thing different about this score to the previous ones I've created. This one has been scaled up about 10% from the factory setting. And it has fingering numbers. Perhaps I'll trying deleting fingering then scaling back the score to see if this is the problem.
Editing the score gives no problem. It's only in preview.
In reply to I've just remembered that by geetar
Looking again at the problem, it seems to effect all the scores and may not be related to magnification or actual notation. But the longer the score, and the more pages, the slower adjusting preview settings seems to be.
In reply to Looking again at the problem, by geetar
I wonder, have you tried a nightly build? It seems *possible* the problem might be caused by the font rendering in the version you are using, but this has been replaced by a new system for the current builds (and will be in 2.0.2).
In reply to I've just remembered that by geetar
What does "scaled up about 10% from the factory setting" mean? I sense an opportunity for me to learn something new.
In reply to What does "scaled up about by Isaac Weiss
Adding 10% to the default "staff space" in "page settings. Makes all the score elements larger by 10%.
In reply to Adding 10% to the default by geetar
That's what I might have assumed, but this doesn't seem to actually be the case - the staff space is still at the default of 1.764mm. Or maybe that's another symptom of the problem - that the staff space is showing as default for me but as modified for you?
In reply to That's what I might have by Marc Sabatella
I can confirm that particular score is set to the factory default stave space = 1.764.
However, the problem may, as you say, have been fixed in the nightly builds, so it may be a non-issue now.
In reply to I can confirm that particular by geetar
I'm afraid it is not...
In reply to Adding 10% to the default by geetar
Oh, that. Okay. I thought this might be something to do with one of the command line options I remembered reading about. On the other hand, I'm still a little bit puzzled, because a) as the others said (edit: and you did as well), the staff space in that score is set to the default distance, and b) staff spacing, unlike the "small staff size" which can be redefined in Style -> General… -> Sizes, is not about percentages. Or do you mean you changed the staff spacing to 1.94mm? That would be 10% over 1.764mm.
I don't find your score "very unresponsive" - no matter what page settings I tried. I'm also on Windows 7.
Your hardware resources may come into play, as MuseScore performs its various layout calculations.
With that in mind, when opening your score, I did notice two things :
1. If you include a pickup measure (anacrusis) into the total measure count, via Measure Properties, you should simply uncheck the 'Exclude from measure count' box, rather than add +1 to all the measure numbers. Look at this image of your score:
The very first measure is highlighted, yet the Properties title reads: 'Measure Properties for measure 2. Sounds confusing, yes?
So, it would be better to leave the 'Add to measure number' at 0. This way, unchecking the 'Exclude from measure count' includes the pickup the 'normal' way.
(Could mean fewer calculations for MuseScore overall --> quicker response.)
-
2. When you use linked TAB, you should be careful how you enter chordal tones. From the handbook:
'MuseScore refuses to place a second note on a string which already contains one; for this reason, it is usually better to fill chords from the highest string to the lowest.'
Looking at your score:
The treble staff fingering (at the question marks) does not conform to the TAB, or vice versa.
EDIT See:
https://musescore.org/en/handbook/tablature#inputting-new-notes
I'm not saying this is the reason for your slowdown... but, if you delete the TAB staff completely, MuseScore will definitely pick up some speed...
Regards.