When a score becomes large the interface is sluggish
I know this has been commented in earlier posts. When a score reaches certain size, be it because of the number of measures or the number of staves (or both), the interface starts to be sluggish. For instance, a simple task as selecting a note may have a delay of a couple of seconds. Even if version 3.1 is way better than previous ones, it's still a problem and eventually one has to split the score into two or more parts and only when it is complete, join them toghether. Does anybody know what may be happening? Or,in other word, what are the processes running in the background that depend on the size of the score? Are all of them necessary?
Comments
Are you in continuous mode or page view? While continuous mode is far superior to what it was in 3.0.x, it still slows down after a while. I haven't had 3.1 slow down significantly on me noticeably in page view in version 3.1 and I did a cello concerto with 20 staves and 354 measures. That was the longest movement. I still enter movements in their own files.
In reply to Are you in continuous mode… by mike320
You are correct, I am in continuous mode, the one I've found better for composing for large groups, since one needs to see several measures before. Paginating an orchestral work often means that there are barely a couple of measures visible and much space used for margins, instrument names and page separation. So I leave page adjustment as the final process.
Anyway, as I said above, I'm curious why this is happening, since an action such as selecting shouldn't modify anything and still it lags. Also, adding new notes should not modify anything backwards. So, except if changing something way back from the last edited measure, performance shouldn't be affected as there isn't massive reformatting.
I'm just curious. If the reason is pinpointed, maybe some action can be taken to improve performance.
In reply to You are correct, I am in… by fmiyara
You have brought up many issues that have been discussed concerning speeding up continuous view and I've done many scores that cannot realistically be entered initially in page view, so I do understand what you are saying. The issue of improving continuous view speed is not dead, and posts like this will keep the subject alive. I don't think continuous view will ever match page view in speed, but no doubt it will continue to be improved. Allegedly version 3.1 is faster than 2.x in continuous view, but it feels about the same to me.
In reply to You are correct, I am in… by fmiyara
It's easier to investigate if you attach your score.
Having implemented the continuous view performance optimizations for 3.1 - plus some additional optimizations that kind of came for free with some bug fixes for 3.2 - I can say that some commands will trigger the "partial relayout" (only recalculating the measures that changed, and then simply applying an offset to measures after that), but other commands for various reasons trigger a full relayout. If there is a partial layout only, it should be quite fast - in fact, in some cases it can be even faster than page mode, because we can literally stop aafter the changed measure and don't have to finish laying out the system, or worry about whether this change pushing a measure to next system and causes that system to need to be laid out again, etc. But, in another important respect, it will often be slower, because some portions of the layout do still need to be applied to entire score (well, the whole system, but there is only one system), like layout of "Lines".
In reply to It's easier to investigate… by Marc Sabatella
Thanks for the explanation about commands triggering relayout.
Regarding the requested sample score, It is not a particular score, any score will eventually present the problem if sufficiently large (I guess the total number of notes may be the relevant parameter here). I attach an example that has been generated from a MIDI file downloaded from the Internet. However, the problem not necessarily is present right after opening the file but after working on it a for while, for instance copying measures and pasting them into other staves, inputting notes and hairpins, correcting notes. Actions that should not imply any relayout, such as selecting notes or changing a velocity in the inspector, sometimes take several seconds. Even entering or getting out of the note input mode will have a lag. The response to the play button, either engaging or releasing it, may take some seconds as well. This is confusing, since the lack of inmediate feedback can lead one to repeat the command, making the playback to stop and immediately restart, for instance.
That said, I acknowledge the performance is much better than 3.0.5, but intuition tells me there must be another problem that hopefully could be fixed. Why? First because actions such as the commented ones shouldn't cause any layout change. Second, because there is no need to repaginate anything in the continuous view, there is a just a single system all of whose staves are visible (i.e., no one is hidden because of being empty). Common edit types that would require massive relayout would be a change of time signature, key signature or clef in the middle of the score and one could live with some lag in such cases.
In reply to Thanks for the explanation… by fmiyara
Can you then post a score that already has the problem? I get that's it's a not any particular score, but I've never encountered one so large that it's still noticeably sluggish in 3.1.
In reply to Can you then post a score… by Marc Sabatella
The problem is not in the score itself (except that it usually happens, as I've said, with large scores). Normally it arises after working a while with it. It's nearly impossible for me to recreate one sequence of operations that lead to the problem in a reproducible way because I should keep track of every note I added or change made. But I'm pretty sure that doing some edit actions in the middle of the Rossini's example eventually lead to the sluggishness I and other people have suffered even with 3.1. (in continuous view at least)
I don't think the size, whatever huge (within the available memory) should influence the response time of an action with the mouse such as note selection, activating note entry, or starting or stopping playback. That's why I think there must be something, may be memory occupancy, that accumulates during creating the score.
Other example: moving the currently visible tab to a different position when multiple scores are open in different tabs takes several seconds, when there is no change at all in what is presented (the same score). Only the tab moves.
In reply to The problem is not in the… by fmiyara
We don't need a set of steps to get a score into that state. We just need a score that is already in that state. So that we can simply load that score, and do the simple things yo mention - selecting a note, etc - and see if it is slow for us, and then debug why. Because currently, I simply cannot reproduce what you describe - all operations that should be fast are fast, on each and every score I have tested.
In reply to We don't need a set of steps… by Marc Sabatella
I insist, any large score eventually reaches that state after working on it for a while. No score is in that state per se. You will not notice the problem if you just open it. Take for instance the Rossini example I've provided earlier and engage continuous view. Just play it until you start to listen artifacts (which, I presume, are due to the fast tempo and large number of notes per unit time). I suggest such limit because it is there when memory problems seem to start manifesting. Play around with the play panel reducing the tempo and continue playing (hopefully the sound improves, for instance, at 30 % speed). Then stop, select several measures from the string (for instance from 141 to 161) and raise them an octave. Play the measures. Then undo. These actions were able to trigger the pronblem on my system (Windows 7, i7 laptop with 6 Gb RAM).
Try actions like moving the score with the mouse, or engaging play. You'll see it takes about 4 s. Stop. It will take another 4 s to respond.
In reply to I insist, any large score… by fmiyara
I see, so it's not in fact "when a score becomes large" (as the title of the thread says) that the problem occurs for you, but rather "when the system starts to run low on memory" perhaps?
In reply to I see, so it's not in fact … by Marc Sabatella
I have a very largs score (Marc might remember my huge album, basically more than 400 1.x 1-2 page scores cobbled together with 2.x's album feature) which works much better in 3.x as it did in 2.x, but there are some operations that are still very slow.
(Yes, I know, I need to be much more explicit about that some, and will, when working on it next time)
In reply to I see, so it's not in fact … by Marc Sabatella
Yes, it is when it becomes large. I've never had this problem with smaller pieces, such as a piano sonata (even in 2.x), nor had it during the the edit, say, of an up to 50 measure orchestral work. That's why splitting the score into smaller parts helps. What happens internally, for instance running out of memory, I cannot know but only presume. Anyway, on second thought, it doesn't seem the case. With a score so far of about 40 measures and the Rossini score loaded, the task manager is indicating right now a total usage of 700 Mb by MuseScore, and I have 6000 Mb from which 3000 are completely free. (*)
Probably there are bottlenecks, not necessarily because of lack of memory or processsor overloading, since CPU usage is about 30 % at most.
I guess there may be some background processes running inside MuseScore (since I only have very few programs open and the sluggishness also happens) that don't allow other services to be completed untilthey finish (such as responding instantly to a playback or stop request). I don't mean processes such as a massive relayout, in which case it would be acceptable.
(*) I ran this experiment: I closed all scores, then closed MuseScore, then ran it again. It used 141Mb. Then I opened an orchestral score about 50 measures long. Memory usage rised to about 180 Mb. Then it started to grow steadily up to 561 Mb. I guess it was loading the HQ sounfont. Anyway it s far from running out of memory , but I start having playback artifacts in passages with many notes (for instance 16th note scales duplicated in several instruments). I still don't have sluggishness because it is not so long so far.
In reply to Yes, it is when it becomes… by fmiyara
OK, but it's not "when it becomes large", but some point after it becomes large, in a way that makes it harder for anyone else to reproduce.
Anyhow, if you get it down to a specific score and specifics steps to reproduce the problem on any system, please do let us know.
In reply to OK, but it's not "when it… by Marc Sabatella
What you say is a which-came-first-the-egg-or-the-chicken case: I cannot tell if it became large and then it became sluggish or it became sluggish during the growth processs. Anyway, the distinction is purely academic. The fact is that when writing a piece with many instruments and many notes at a certain point you become aware that the response lags too much and too frequently. And when you analyze it, you see that the score is large.
I'm not dreaming, I promise. Other users agree that this happens.
To be sure, version 3.1 has improved a lot, but there is still a problem.
The case mentioned in my earlier post (https://musescore.org/en/node/291211#comment-929700) I think is exactly what you are asking for. I followed those steps and MuseScore became sluggish.
In reply to What you say is a which-came… by fmiyara
No one ever suggested you were dreaming. The reason we constantly ask for score and steps to reproduce isn't so that we will believe you; it's so we can investigate and actually do something about the problem. And the reason it is important to ascertain whether the problem you see on your system is inherent in the score or is instead something about your usage of MuseScore is because that that will be an important clue in understanding the cause and therefore solution. If it's something that happens instantly the moment you load a large score, then we know it is about the layout of the score and we can look there. If it's something that only happens gradually over time, then it suggests a resource usage issue.
So far everything is pointing to the resource usage issue - the fact that it doesn't happen right away for you, the fact that no one else seems to be experiencing anything similar (you say others agree but I do not recall a single such report since the release of 3.1), and the fact that I cannot reproduce any problem after attempting to following the rather vague steps you provided (starting with the fact that I never heard any artifacts, continuing to the fact that nothing I did ever cause response time of, say, Ctrl+Up to ever take more than an immeasurably small fraction of a second).
So, if you come up with a precise series of steps to follow that are guaranteed to reproduce the problem, please let us know. We certainly want to do what we can to improve performance even further, but there is simply no way to do so without a way to reproduce the problem you are hearing on your system.
In reply to No one ever suggested you… by Marc Sabatella
A few posts above Jojo-Schmitz acknowledges he finds that some operations are very slow (which he will try to report when he experiences them again), and mike320, without being specific, also acknowledges that it "slows down after a while" and forecasts that continuous view will never match the speed of page view. They are the other users I was referring to.
Regarding the fact that you cannot reproduce my observations (for instance the artifacts during playback), the only thing I can think is that you have a much better processor (or you are not using the HQ soundfont).
I'm afraid I cannot provide precise steps that guarantee reproducibility of the problem since it seems evident that it is very system-dependent. I can guarantee that on my computer the steps indicated lead to the reported behavior, but I cannot guarantee the same will happen in your computer. On the other hand, the behavior is statistical and not deterministic. It is not all the time nor always on the same note.
In reply to A few posts above Jojo… by fmiyara
To be clear, "some operations" are known to be slow on large scores - those that force a full relayout. So for instance toggling concert pitch is always slow on large scores, etc. But this will be 100% repeatable on a given score independently of your system load or what other steps you took previously. The steps to reproduce that are simple: 1) load score, 2) press Concert Pitch. mike320 has submitted reports with exactly that level of specificity, most recently involving adding articulations, and I made a fix that is already in 3.2.
So far anything reported by anyone else is more in those category. Yours is the only report I have seen of someone explicitly saying they are seeing slowdown that has to do with length of time they've been working on a score, not something inherent in the score itself. Again, I say this not to suggest I don't believe you, but to impress upon you the importance of your taking some initiative and trying to find a reproducible scenario if you want to see anything done about this, because right now, you seem to be the one who has a score, workflow, and system that reproduce this issue in way no one else seems to be able to.
In reply to To be clear, "some… by Marc Sabatella
Paradoxically, toggling concert pitch in my case takes 5 seconds (for the Rossini score), but some operations such as play o go to the beginning may take 7 s (but not consistently), even if no edit has been yet performed.
I know your request is important, but I don't know how to reproduce in your computer something that happens on mine.
In reply to Paradoxically, toggling… by fmiyara
Step one is to at least get precise steps that are 100% reproducible for you. Then others can more easily treat whether they can reproduce. As it is, I'll never really know if my computer is immune to this (because I have 8GB RAM, say) or if it's just something specific you are doing that I simply won't think to try without precise step step by step instructions telling me exactly how you triggered the problem
In reply to Step one is to at least get… by Marc Sabatella
My steps are 100 % reproducible for me, but in a statistical, not deterministic, way. I get this is annoying and useless for you (and probably for anyone trying to fix a piece of software), but it's all I have, sorry. I cannot discard the possibility that my computer/operating system is the culprit.
If I happen to come across some more clear procedure, I'll post it here.
In reply to My steps are 100 %… by fmiyara
I'm not necessarily suggesting your system is the "culprit", but more that something about your particular setup is perhaps the trigger. Like, there is some bug in MuseScore that is only encountered if something is true about, I don't know, your particular audio driver. Since most the steps you involve have seemed to involve playback (can you reproduce a problem if you never start playback?) I wonder about audio drivers but also, your synthesizer settings, soundfonts used, etc. Knowing if you can reproduce an issue in page view would also be interesting info. Also, once the problem starts to occur, does it go away if you close then immediately reopen the score? Quit then immediately restart MuseScore?
In reply to My steps are 100 %… by fmiyara
I'm not necessarily suggesting your system is the "culprit", but more that something about your particular setup is perhaps the trigger. Like, there is some bug in MuseScore that is only encountered if something is true about, I don't know, your particular audio driver. Since most the steps you involve have seemed to involve playback (can you reproduce a problem if you never start playback?) I wonder about audio drivers but also, your synthesizer settings, soundfonts used, etc. Knowing if you can reproduce an issue in page view would also be interesting info. Also, once the problem starts to occur, does it go away if you close then immediately reopen the score? Quit then immediately restart MuseScore?
The point for me is, the sorts of things I know about and have worked would be expected to show their effects in a 100% deterministic way: a given score & a given series of steps would always executed exactly the same code and thus would always produce the same results and take about the same amount of time on any given system. Non-deterministic results do suggest some sort of resource usage issue perhaps, or an interaction with something else on your system. That's unlikely to have anything to do with code I am familiar with, and unlikely to be related to any deterministic problems encountered by others.
The issue I mentioned that @mike320 raised regarding articulations is a good example, BTW, worth knowing about. It was discovered that we were doing a full relayout every time you added an articulation (both continuous and page view), and when I discovered the reason for this, the fix actually applies to a number of other operations involving symbols being added that really shoudn't have needed a full relayout. This fix went into 3.2 along with a few others that helped refine things in terms of what exactly gets laid out, and this should have a small but noticeable effect on the overall feel of working with large scores.
Rewind, BTW, appears to be an operation that does require a full relayout, and it takes roughly the same amount of time as toggling concert pitch on my system. Ctrl+Home, on the other hand, does not - it's instant. And so is selecting the first note/rest of the score. This is completely deterministic. So, if your goal is to go the beginning of the score then start playback, better to use Ctrl+Home then select rather than Rewind. Why does Rewind need to do that? Not clear to me, but anyhow, it's maybe useful info.
In reply to I'm not necessarily… by Marc Sabatella
I appreciate your dedication to trying to disentangle this mistery.
I have only yesterday installed 3.2, so I haven't had enough time to test it, but I can confirm that the playback artifacts are present when using the MuseScore General HQ and are not present when using MuseScore General (to which I have reverted since HQ is only slightly better in the sounds I'm using and I prefer some quality degradation if I can prevent the annoying glitches). My audio driver is Realtek high definition audio, I have all effects disabled, and I see now that I have set Fs = 48000 Hz and 24 bit, which is really unnecessary. I'll test later if the glitches disappear with 44100 Hz, 16 bit.
I can also confirm that the sluggishness persists, though it may have improved somewhat since it doesn't seem so invasive (but it is also true that I split my scores and the fragment I'm working on hasn't grown to the critical point where the sluggishness becomes a true pain in the neck) .
It may be very difficult to test relevant actions with the software without involving the use of the audio driver, since the operation of selecting a note plays the note. The Synthesizer has the following settings:
<Synthesizer>
<master>
<val id="0">Zita1</val>
<val id="1">NoEffect</val>
<val id="2">0.1</val>
<val id="3">440</val>
<val id="4">1</val>
<val id="5">1</val>
</master>
<Fluid>
<val id="0">MuseScore_General_HQ.sf3</val>
<val id="0">MuseScore_General.sf3</val>
<val id="0">Sonatina Percussion - Cymbals & Tamtam.sf2</val>
</Fluid>
<Zerberus>
</Zerberus>
<Zita1>
<val id="0">0.25</val>
<val id="1">0.462756</val>
<val id="2">0.161809</val>
<val id="3">0.333333</val>
<val id="4">0.25</val>
<val id="5">0.335245</val>
<val id="6">0.5</val>
<val id="7">0.664755</val>
<val id="8">0.5</val>
<val id="9">0.33</val>
</Zita1>
I'll try later to do some testing as you suggest.
Ctrl+Home doesn't seem to work for me. The status bar indicates Measure 1 Beat 1 but when pressing play it starts elsewhere. I don't understand what you refer to when saying "then select". If I select all, playback starts at the beginning, but this happens even without Ctrl+Home. To select the first measure the focus should have moved to the beginning.
Rewind should not need any relayout (or at most only of the beginning) since it is not an edit action. Only edit actions potentially affecting all the score (for instance, select all and raise an octave) should trigger a full relayout.
Also it would be interesting that layout changes not affecting earlier material were performed during iddle time, giving priority to any action by the user, such as select, change pitch, play, stop.
Is there any known background process in MS?
In reply to I appreciate your dedication… by fmiyara
Ctrl+Home indeed doens't change the playback point, that's why I said you would then select the first note or rest - that sets the playback point. Not sure what wasn't clear about that, so I don't know how to put it differently, but how about:
1) press Ctrl+Home to reposition scoreview
2) click first note/rest to select it
3) press Play
Results should be the same as hitting Rewind then Play, but faster because no full layout is required.
It's true that in theory Rewind might not need to layout all, but it does some re-initializing of some synth stuff apparently that ends up triggering this. This is code I know little about so I can't say more about why.
There is for all practical purposes no background processing. Before we had the partial relayout we now enjoy, I did try to implement something of that so that a change to a score would kick off layout of parts in the background, but that's not my area of expertise either so I was unable to get anywhere with it, and it's mostly moot now anyhow.
In reply to Ctrl+Home indeed doens't… by Marc Sabatella
First time I tried Ctrl+Home it didn't change the position. Moreover, after moving several times (either applying rewind or as a result of playback/stop) it went to the same position but different from measure 1 (that's why I didn't understand). Now after having shut down the system and started it again, it works fine! Unfortunately (or fortunately!), I cannot reproduce that behavior.
As I said, may be my system is not working properly, so I should test in another computer or may be reinstall my Windows, but unfortunately it will have to be in August because it takes some time and right now I'm working in strict schedule to comply with a deadline. I'll be in touch to report any finding.
Thank you so much for your patience.
In reply to A few posts above Jojo… by fmiyara
For me the slowness as got nothing to do with continuous mode which I virtually never use...
In reply to Nothing to with continues… by Jojo-Schmitz
As I use much MuseScore for composing, I use mainly the continuous view, and use page view to do the final formatting.
In reply to As I use much MuseScore for… by fmiyara
I'm just transscribing, so I set up system- and page breaks in advance, to easier keep track of where I am