Flipping slurs
Has anyone else noticed that in large scores it takes an awful long time to flip a slur using the x shortcut?
Do you still have an unanswered question? Please log in first to post your question.
Has anyone else noticed that in large scores it takes an awful long time to flip a slur using the x shortcut?
Do you still have an unanswered question? Please log in first to post your question.
Comments
Page or continuous view? In continuous view, operations involving Lines will generally require a complete layout, because lines are laid out relative to the system, and there is just one big system. The improvements I made in 3.1 (?) to try to optimize continuous view performance still leave cases involving lines where full layout is needed. It's conceivable there could be a further tweak to try to get just the right range of measures for some Line operations.
In reply to Page or continuous view? In… by Marc Sabatella
Since we sat down for a couple of days and you did all of that fixing and me all of that testing I almost never use continuous view any more. I got used to page view while I was waiting for continuous view to get fixed and haven't looked back. I know we found something at some point that was way too slow in page view and you fixed that. I know the slurs in https://musescore.com/user/6105546/scores/6234062 are good examples that take a long time to respond. Everything else is almost instantaneous.
In reply to Since we sat down for a… by mike320
OK, thanks for the info! Yes, every once in a while we continue to find some random operation that triggers a full layout unnecessarily. Here's another I found a couple of weeks ago while implementing the automatic spacing for lyrics in continuous view: hitting up or down to move between verses. Probably we should build a list.
In reply to OK, thanks for the info! … by Marc Sabatella
I'll start an issue like: Certain actions cause unnecessary complete layout and we can add to that issue as we find them, or do a separate issue for each and put them into an epic issue. That way they will be linked but have the ability to have individual PR's since their code is probably all over the program.
In reply to I'll start an issue like:… by mike320
Whichever is easier for you, but the individual issues with epic is, I suppose, best. For me seeing them all listed in one place is good, and the epic does that. But it could well be some end up being easier to fix than others, so having them separate is good too. I’m also fine with using tags, or just having a spreadsheet or whatever.
In reply to Whichever is easier for you,… by Marc Sabatella
Added #308965: [EPIC] Items that cause entire score to be redrawn for tracking all issues and #308966: Flipping slurs causes entire score to be redrawn for this specific issue.
FWIW (probably not much since the [EPIC] link was posted), after reading this question I've noticed that flipping a hairpin in a large score I didn't notice any slow down, but lo!, flipping a slur gave me about a 3 second pause before the operation completed.
In reply to FWIW, after reading this… by worldwideweary
I think you misunderstand what I was trying to say and it's probably my fault. Flipping the slur takes a long time, once the slur is flipped everything is back to normal. The longer the score, the more noticeable the pause so my suspicion before I ever posted this issue was that everything was being redrawn since I've encountered this before. Marc explained the root problem back then and fixed it for that item.
In reply to I think you misunderstand… by mike320
Not sure. At least I thought you were making sense. It takes me about 3 seconds to flip a slur on a ~55page score, reproducing the problem in some sense on my system. As an aside comparison, same score didn't provide a noticable lag flipping a hairpin-line in page-view (as opposed to continuous view mentioned by Marc)
In reply to Not sure. At least I thought… by worldwideweary
I realize it is necessary to handle page view and continuous view differently since continuous view is a single system, though I think it should be rethought to make it better. Those of us used to seeing 55 page scores see the slowdowns more often and better than people who write piano and guitar solo pieces so we're the ones that need to report these slowdowns. Marc says he knows of a few more slowdowns but he didn't mention them to me. They may be things I don't normally use like chord symbols or tablature.
In reply to I realize it is necessary to… by mike320
I hadn't noticed any slowdown when flipping slurs until I read this thread. I looked at my transcription of the Mozart Clarinet Concerto, all 811 bars and 228 pages of it to see how it would behave. Yes, I noticed a slight lag between pressing x and seeing the slur move, but nothing that would be an inconvenience and I doubt I would have noticed anything untoward if I hadn't been prompted to investigate; certainly nothing like a 3 second lag. This was with just the score (I have been using MuseScore as my backing group). Then I created the parts (9 of them) and, it was somewhat laggier than with just the score, but again if I hadn't been looking for it I doubt I would have noticed. It is much the same with my Weber Clarinet Concerto No. 2 1st mvt (256 bars. 85 pages, 12 parts). Does the number of parts have a more pronounced effect than the number of pages/bars/notes? I don't have any long and highly instrumented scores to test further.
In reply to I hadn't noticed any… by SteveBlower
A combination of measures and instruments goes into the time it takes to redraw the entire score. The score I linked to has 1642 measures and 19 instruments which means a total of over 31,000 measures. This is probably the best measure for how long it takes to draw the score. I chose it because the delay was very obvious. I also extracted all of the parts (in actuality I entered the parts to create the score) and I think this slows down operations that redraw everything. The scores you refer to have far fewer total measures. While I was transcribing the Kalliwoda score the delay wasn't so noticeable because it became gradually greater with each new measure. I really didn't notice the slow down until I started another project and went back to look at Kalliwoda and the delay couldn't be missed.