response time using large scores
Hello everyone.
I'm getting a lag during input of notes on the score for a very large score. It doesn't happen with small scores.
Thanks for a great piece of software. Not only the features, but the beautiful interface and open source features including issue tracking and code repositories. Great stuff.
I'm starting a large project -- full symphony with about 60 pages16x24 inch written by hand 100 years ago. I've gotten about 17 pages into it and have learned a lot about music and music notation. But I've also noticed that the response is getting slower. When I open a smaller score I get new notes instantly. With the large score, there is about a 1 second lag between entering the note and having it play and appear in the staff. I've tried turning off the play-while-inputting feature and I've looked for other options that might speed the response, but I haven't found a magic fix. I'm using a Mac (latest 10.6 update) and I've tried MuseScore versions 1.0 and 1.1.
I'm beginning to suspect that adding a note changes a data structure somewhere in a way that takes time dependent on the size of the data structure. This leads me to two questions:
1) Have other users dealt with very large scores? What workarounds have you used to keep response fast? Has anyone used a very large score without this issue?
2) Can anyone point to parts of the code that might be causing a lag when a note is added or removed from a very large score? It'd be cool to understand what's going on there.
Thanks in advance for any help,
Dan
Comments
...I have no magic help to offer, but I have experienced the same effect.
The best trick I found so far is to break the score into several shorter parts. For instance, in the case of a symphony, I would suggest to make different files, one for each of its movements. The page numbering of each file can be set with the "Layout | Page settings", "First page no." command, to keep them in sequence.
I cannot pinpoint a particular kind of mark (say, dynamics or articulation, ...) as specifically inducing the lag; the more stuff, the slower the response (lyrics seem to be particularly 'heavy', but they do not apply to your symphony, I expect).
A part from the aforementioned splitting, there little else I can think of; I suspect this is an aspect where MuseScore could be improved.
M.
It's a known issue indeed, the more objects in your scores, the slower. Currently, the only simple way to avoid this is to get a more powerful hardware...
Regarding your why question, every time you add a note or element in the score, MuseScore will add in a structure to be able to find it again when you click on it, it will also relayout the *entire* score to see if the note you just entered will influence the music layout in some way.
In reply to It's a known issue indeed, by [DELETED] 5
I assume it's the layout that is the biggest culprint here? If so, that might be another incentive to pursue adding a "scroll view" mode. In such a mode, there are no distinctions of systems and pages. So there is nothing that editing a note in one measure can ever affect except the portion of the score currently being displayed. Thus, no need to run the full score layout.
In reply to I assume it's the layout that by Marc Sabatella
This performance issue is being tackled for MuseScore 2.0, so it will improve.
In reply to Tackled by Thomas
I have same problems in version 2.0.3 ...
In reply to I have same problems in by tomvd
Indeed, while there are some minor differences compared to the versions being discussed here in 2011, 2.0.3 still struggles with very large scores. Best to split them into smaller files and join them up later.
Meanwhile, more significant improvements *are* being worked on for 3.0
In reply to Indeed, while there are some by Marc Sabatella
Isaac Weiss has written an excellent blog post about this improvement in 3.0:
https://musescore.org/en/user/101731/blog/2016/06/02/developing-musesco…
Thanks for the information and the workaround!
Also for the description of why and how the trouble is caused. If I understand correctly the issue is that local changes may have global formatting implications. If that is true, it sounds like a long term fix could be a system to identify which local changes might change things globally. Perhaps that is part of the "scrolling view" you guys mention.
I'm willing to take a look at potential fixes if that would be helpful. Meanwhile I'll use the workaround of splitting the file for entry and then cut/paste to put together when ready.
Thanks again!
Dan
In reply to Thanks for the information by dschult
In many cases, you probably do not even need to finally cut and paste from the separate files into a single file: just locate suitable points for the splittings (between movements or other major segments of the work), start the pagination of each file in sequence ("Layout | Page settings", "First page no." setting) and keep them separate.
If you need a single file for distribution, you may export each file to PDF and then 'glue' them together in a single PDF using tools like PDFsam . The whole process can be automated with a .bat (Win) or script (Linux) file.
M.
I am transcribing an early 19th c opera manuscript and I'm splitting it into a different file for each aria. I find this a lot more manageable than having one big file, and it would also avoid the problem that you are experiencing. I would also he very curious to know what are you transcribing this manuscript for :)
Best of luck,
Raffaele
In reply to I am transcribing an early by raffazizzi_
This symphony was written by a family member (great aunt) and my mother has talked to the Albany Symphony about looking at it. They said they would need to have it transcribed before they could look at it.
It's fair to say that we are also interested in hearing what it might sound like via the computer--though its not the same as the real thing. So playback is also an important feature too. Its quite an investment of time, but we're all enjoying it. :)
Dan
In reply to What I am transcribing this manuscript for by dschult
On your project.
Regards,
In reply to What I am transcribing this manuscript for by dschult
That's beautiful. Good luck!
Raffaele
One thing that just helped me is by pressing the f12 key which takes away the navigator but frees up the lag. Don't ask me how but it worked for me. hope this helps :)
In reply to One thing that just helped me by MasterCoy
I can confirm!!! Thanks!
Hello.
For Musescore 2 just switch to Continuous view and it solves it.
I experience the lag problem all the time with big scores. The first symptom is that when I click on the arrows used in the Inspector for incremeting things like vertical offset, the incrementer increments by two steps instead of one. Shortly afterwards, everything starts slowing down. I expect this because it's an expected side effect of WYSIWYG layout programs.
What I don't expect, and what's truly problematic, is that Save operations can take up to a minute or longer, including Save As (the record so far is 2 minutes and 30 seconds). Surely this is a bug, since I can do a Save As at the command line while the file is open in Musescore (cp file.mscz file-new.mscz) in a split second.
In reply to I experience the lag problem by Peter Schaffter
Well, "cp" from the command line is nowhere near the same as a save as - cp is just a file copy. Save As has to do a whole lot of processing. But you are right that it shouldn't normally take a minute. As per usual, in order to investigate, we'd need to see the score in question, have precise steps to reproduce the issue .
But yes, large scores are slow to layout, that's known. Should be a lot better in 3.0, when that comes out eventually, because layout gets smart enough to only layout the portion of the score that actually changes on any given edit operation.
In reply to Well, "cp" from the command by Marc Sabatella
Sorry, I should have written "Save a Copy..." rather than "Save As...". In other words, a simple duplication of the file, identical to what 'cp' at the command line does. And yes, "Save a Copy..." takes way longer than a simple cp, even though, surely, there's no additional processing required. It makes no sense for there to be additional processing; the proof is that a simple cp of the .mscz/x file while it's still open (and has been saved) in MuseScore results in a copy of the file that's identical to the original.
I'm attaching a sample, fairly large score. Open it, make a trivial change, and do a Save. (On my system, ca. 30 sec. wait). Then do a Save a Copy. (Again, a long wait.)
In reply to Sorry, I should have written by Peter Schaffter
Save a Copy is just like Save As internally, which is to say it is doing *way* more than an OS-level file copy operation. Save, Save As, and Save a Copy all do the same thing - go through your score element by element writing it out, calculating various values that need writing, possibly involving looping through lists of information - lots and lots of processing beyond just the time to write the file. The only difference betwene Save As and Save a Copy is that the former makes the new file the current score whereas the latter does not.
So again, no surprise that a slow Save means a slow Save a Copy as well as a slow Save As.
That said, I have no particular insight at this time into why your score takes so long to save. it is pretty large, but a save shouldn't normally (?) be that much slower than the relayout that happens on each edit.