Multiple Issues With a Score in 3.0.5.5992
Hello,
I've been trying to get a score and parts ready for tomorrow and spent most of my night dealing with multiple bugs affecting all sorts of aspect that I have largely been unable to fix and have resorted to just living with. That being said, I would like to be able to continue working with this file past tomorrow and really don't want to keep running into all of these problems, so I'm hoping someone might be able to help address at least some of them.
1) The score will no longer play back from around measure 77 on. It will either play some odd collection of notes for a moment and then stop, stay frozen on those notes, or skip ahead a seemingly random number of measures before playing and potentially freexing. Based on what I've read, I assume this has something to do with all of the time signature changes between 77 and 98, but attempts to change them, or remove and re-enter the entire section have failed. I reverted to factory defaults and rebooted my computer, neither of which helped. I also tried exporting the entire thing as a music xml file and restarting with that, but after working for a while to fix all the formatting changes, I found it had the same problem. At this point, I've just stopped trying to listen to the score without starting from the beginning.
2) The system crashes when changing the height of a vertical frame at the start of the score. Specifically, I think it occurs once the height drops to a low enough value that the first system would be moved onto the same page. I was trying to remove the cover page images and extra text for my score before creating the individual parts, but could not get the frame to a reasonable height without MuseScore crashing. Ultimately, I deleted the entire system, created a new system at the default height, re-entered the title and composer info, and then generated my parts.
3) At some point, editing any sort of text in the score became a very slow process that would make MuseScore not respond for as much as 20-30 seconds at a time as it caught up to my typing. This was before I generated parts, I couldn't find any issues with a bunch of duplicate items (like dynamic markings) layered on one another, it's not a particularly large score, and reboots had no effect. Also, it seems to only be a small number of processes, editing text is the one I know for sure, that slow everything down. It also seems to be specific to this file.
4) Every new hairpin I add automatically formats itself for the line thickness to be 0.40 spaces despite the fact that in my style settings, it's set as the typical default of 0.13. I saw that someone else had the same basic issue, but the response was to change the style setting and there was no follow up from the person who posted the issue stating whether or not this was the problem.
5) I'm now dealing with duplicate time and key signatures. For instance, in the bass trombone part I attached, I had to add a break after measure 97, because it was forcing courtesy time and key signatures in the middle of the line. I really don't want to turn courtesy time/key signatures off (I'm not even sure how) as it's a valuable tool for players. I tried inserting a new measure with the time and key changes and deleting the original with the duplicates, but the new measure just generated its own duplicates. I'm not sure if this helps, but when the part was generated, before I expanded the spacing to fill the two pages, measure 98 started on a new system, which may have generated the duplicates in the first place.
6) Finally, I just want to say that despite all these issues and what has been an incredibly frustrating past 24 hours, I love MuseScore and it has become a huge part of my life. It is, overall, an incredible piece of software and I am so grateful for the community responsible for creating, maintaining, fixing, and upgrading it. This cannot be overstated.
I've attached the version of the score I created for the generation of parts and the bass trombone part, which I saved as a separate file to speed up the reformatting process.
Thanks.
| Attachment | Size |
|---|---|
| Avengers Encore - Final Draft (Parts).mscz | 370.14 KB |
| Avengers Encore - Bass_Trombone.mscz | 25.74 KB |
Comments
I don't see the problem of playback. I just tried to insert a vertical frame for the cover and resize the one of the title. I don't think it'll solve anything for you, but still...
Be patient and there will be a better answer.
In reply to I don't see the problem of… by Shoichi
Just a little consideration: I'm on Mint (32 bit), who is less resource-hungry.
In reply to Just a little consideration:… by Shoichi
Thanks for checking it out.
1) Some people have reported strange issues with playback jumping around in continuous view. If that's what you were using, try page view and see if it helps. I couldn't reproduce a problem, though.
2) I increased the frame size all the way to the bottom of the page with no crash in 3.0.5 can you give precise steps to reproduce this problem?
3) Can you give precise steps to reproduce the extremely slow editing? I tried editing a rehearsal mark and while it was a little laggy in continuous view, we're talking a fraction of a second, not 20 seconds. And it was pretty much instantaneous in page view.
4) It seems then when using small staff sizes, hairpins and other don't automatically scale in certain cases. I recently submitted a fix for this that will hopefully be in a coming update. Meanwhile, it fixes itself if you press Ctrl+R to reset, or if you add using drag&drop or keyboard shortcut instead of double-click, or you select a single note instead of a rest before double-clicking.
5) We recently tracked down a problem with multimeasure rests that can lead to these extra time signatures. A workaround to get rid of them is to temporarily turn off courtesy time signatures globally in Format / Style / Page (and use Apply to all Parts), save, reload, then turn them back on. Do this after you're done messing with turning multimeasure rests on and off, though, or you may need to do it again. You can also just disable the courtesy for the double time signatures individually using the Inspector - the first one actually is a courtesy that somehow became permanent.
6) Thank you! :-)
In reply to 1) Some people have reported… by Marc Sabatella
Note to self: Once I realize I can't find answers for an issue in pre-existing forum posts, don't delay. ASK THE QUESTION MYSELF. Your response was far quicker and more complete than I could have hoped for.
1) I need to apparently spend more time in page view, because it plays fine that way. I arrange so many pieces for large ensembles, that it can be challenging working outside of continuous view with all those staves, but apparently that view creates a lot of behind the scenes issues.
SOLVED (essentially)
2) My bad on my choice of files to upload. I'm uploading the original file of the score with a pre-existing vertical frame that included images and text. That's the one that created the crash.
I followed these steps: Deleted the 4 images, deleted the 3 subtitles, edited the title to read "AVENGERS (line break) - ENCORE" and returned the y offset to 0, re-formatted the composer text to the more standard right justified with bottom edge as reference point and returned the y offset to 0, and then tried to re-size the frame. It seemed to be okay until it got to what I believe would be a size small enough for the first page of music to merge with the page of the vertical frame and that's when MuseScore immediately crashed.
I've worked around it for now, but I just tested it out again (with the right version of the file this time) and it still occurs. Hopefully the example can help you with future debugging.
SOLVED (essentially)
3) Once again, page view completely cleared up the issue. It's not necessarily ideal for how I normally arrange, but I can adjust now that I know the workaround.
For reference, the worst offender was when in continuous view, I added instrument change text and edited the text to show the new instrument name. Specifically, I added the text by highlighting an element and double clicking the Instrument text from my palette. Next, I would double click the new text item and use Ctrl+A to select the entire word. Up to this point, it was slow, but not awful. It was when I would proceed to type the new text in that the application would stop responding and freeze up for a while.
SOLVED (essentially)
4) Ctrl+R is a great shortcut to learn, thank you. I did just figure out that when adding the hairpin (de)crescendo to a single element, it worked as expected. It's when I select a range by clicking on one element and then holding down shift when clicking on a second that it seems to create the morbidly obese hairpin. Perhaps that detail will help you in your fix.
SOLVED
5) It sounds like you're aware of the issue with a future fix to come and your workarounds will be greatly helpful in the meantime.
SOLVED
Thank you so much. I'm not sure I could find the words that would do justice to just how grateful I am.
In reply to Note to self: Once I realize… by Daniel O'Meara
We're always happy to help!
Could you explain what you find difficult about page view for large ensembles? Someone else was expressing this recently but didn't provide more details on why. To me, it's small ensembles - ones where you might otherwise fit multiple systems on a single page - for which continuous view is especially nice. To me it seems 6/half-dozen for large ensembles scores, and given there are inherent limitations to continuous view, it just seems easier overall to stick to page except for those small ensemble scores.
Regarding the crash, thanks for the updated file and the detailed steps. They seem clear enough, but no crash for me. Could have something to do with the state the score was in at the moment in terms of previous operations you had done, hard to say. I also tried adding instrument text and saw what I did before - sure, it's a little laggy in continuous view, but nothing extreme.
The too-thick hairpin issue is fully understood, I already submitted my fix - see #285923: Lines from palette added by double-click with range selection ignore score style settings. For the duplicate time signatures I understand the problem but yet have a great solution, still, I expect to have it sorted out soon. These reports have been bugging me for some time so I am thrilled to finally have the information I needed to get to the bottom of it (thanks to cadiz1's excellent investigation in #286794: Permanent double time signature/key signature after style changed then save/reload.
In reply to We're always happy to help! … by Marc Sabatella
The issue for me with large ensembles in page view is that it gets to a point where it can be difficult to comfortably fit all the staves on a page, even using a paper format with a larger height. It's not uncommon for me to start with 40 or more staves like I did with this one before combining some of the individual percussion instruments into parts with instrument changes. Then, if you don't leave enough room between each staff, instruments like tubas, violins, and others that routinely play well above or below their staff start running into one another.
It feels like it takes a whole lot of manipulation of scaling, spacing, etc. to get it to show on the single page comfortably. Then, I'd have to do all of that over again to make a readable score for printing. When I'm finally done editing the content itself, I jump over to page view and reformat things, implode some parts, make it readable, etc. Before then, however, I much prefer the continuous view for giving me unlimited space in all directions and no page breaks.
The only time I ever really do the bulk of my work in page view is when I'm working with a single instrument for a transcription or something similar. I'll also do it for a small ensemble on occasion. It's a little less intuitive maybe than having the continuous view, having to keep skipping down to the next line, but it's preferable to looking at it in continuous view. Something about all that empty space above and below a piece with only a handful of instruments makes my brain very uncomfortable and zooming in to remove it means only being able to look at a couple measures at a time.
I hope that explains the preference. I agree it's probably very personal from one person to the next.
Thanks again. Keep up the great work.
In reply to The issue for me with large… by Daniel O'Meara
I'm in total agreement.
In reply to The issue for me with large… by Daniel O'Meara
Thanks for the explanation!
What I still don't understand is in your very first sentence where you say it's hard "even using a paper with larger height". That's what I don't get - what exactly.are.the problem you run into simply choosing a very large page format? No change to scaling, no worry about making it look nice (we're not printing this way), just spend a few seconds choosing a page size big enough to fit everything with room to spare - say, with a bottom margin of around half the system height to be safe.
You've both indicated this is somehow an issue, but it it isn't clear how. I'd love it if someone could expain exactly what goes wrong, using this or some other score as an example, and giving precise steps to demonstrate the problem.
I don't ask this to imply we have no intention ever improving continuous view. But it just seems to me the advantages of page view for this situation are so obvious, I wonder what I missing. In particular, you mention instruments that routinely play above or below the staff - adding space autamatically is one of the many advantages of page view here.
In reply to Thanks for the explanation! … by Marc Sabatella
Essentially, until now, I had no idea that any of the problems I have faced were related to my use of continuous view. From the beginning of my time with MuseScore, I've gravitated to continuous view because it gave me exactly what I wanted without having to make any changes whatsoever. No paper selection, no visual breaks between pages, no visual distractions, no time spent formatting from the start... I could see everything I was working on, could easily navigate through the score, and I could put off all but the most pressing formatting issues until I locked the arrangement and was working on generating sheet music.
Had I never run into these problems and posted to the forum, I would have been none the wiser to the role continuous view plays in those problems. Now that I'm aware of the issues and have at least one score that has generated so many problems, perhaps I'll learn to use page view for everything and end up preferring it. I kind of doubt it, but I'm open to the possibility.
I realize it may sound silly complaining about paper selecting, but when I'm starting to arrange something, the last thing on my mind is figuring our what type of paper is longer than legal or A4, which are the only formats with expanded length that I'm already familiar with. It's not that this would be an hours-long process. It's just that I had no reason to bother until now.
When it comes to using software for creative projects, I tend to develop very specific habits. I like to have a logically arranged and visually appealing interface and want to be able to manipulate my work as quickly and efficiently as possible to try and keep up with whatever creative decisions I'm making. Because I started with continuous view, it's how my brain operates when using MuseScore. I've got the muscle memory, I know where to find everything, and my eyes know where to go.
You've effectively laid out why you prefer page view. You refer specifically to benefits, but I see things a bit differently. Each view offers features that are specific to them, but those features aren't necessarily benefits for all users. In fact, some of the features that you seem to love in page view feel more like drawbacks to me, based on my own technique, and vice-versa. The one tipping point will likely be the errors, crashes, etc. that seem limited to continuous view.
I hope that better explains it.
In reply to Essentially, until now, I… by Daniel O'Meara
I have used continuous view as long as I've used MuseScore also. I have a workflow that works for me, and I don't intend to change it. I prefer to have the benefit of using version 3's automatic place (I don't understand why anyone wants to turn it all off, but I digress). If I have a choice of a bug ridden version 3 that slows down to a crippling speed or version 2 where I have to adjust every hairpin I'll settle for version 2.
I'm aware that there is work in progress to improve continuous view and perhaps a huge breakthrough occurred last night with the speed issue. In all of my criticism of version 3, I've said I will do what I can to help make version 3 better, because I WANT to use it. Most of the issues that prevent it from being useful are known bugs and the slow speed. Once it gets to the point it's not painful to use, I'll start using version 3 for everything and then I'll be better able to contribute bug reports to fix the minor things that will pop up until version 4 gets released in several years.
In reply to Essentially, until now, I… by Daniel O'Meara
No doubt, in theory continuous view is very nice, and I don't mean to say people shouldn't use it when it makes sense. But it is good to understand the tradeoffs so you can really make the best choice for the situation.
The advantage of continuous view are, I suppose, obvious to anyone to anyone who chooses to use it, so I needn't repeat those. But the downsides are the following:
It's slower, sometimes by a little, sometimes by a lot. This may improve some day, but for now, it's how it is.
Automatic adjustment of staff distance is not performed, so notes and markings above or below the staff can collide with content on other staves. This may change some day, but then the downside would be, even one measure where a lot of extra space is required would force it to be required for the entire score, rather than for just that system as in page view.
Any manual adjustments you make are likely to be wrong once you switch to page view, because you're making them on incorrect information about measure widths, staff spacing, etc. This is inherent in the whole idea of continuous view.
Because it is the less commonly used view overall, it doesn't get as much testing by users and hence tends to be a bit buggier. This too is just a reality that I don't see changing, unless everyone in the world starts switching to it so it actually gets more testing.
Conversely, page view is faster, has automatic staff spacing, manual adjustments work correctly, and it's less buggy overall. I don't really think you'd say any of those advantages are actually disadvantages to you?
So, again, it is good to know what the tradeoffs actually are so you can make the best choice for what you are trying to do.
As for choosing paper size, realize you are not limited to preset size. You can simply increase the length until the preview shows you that everything fits. So it really doesn't require a lot of thought. That said, I actually find it simpler to use the preset sizes, and know that A0 > A1 > A2 > A3 > A4. With your score, you could have left the staff size at the default but selected A0 as the page size and all would work perfectly. That's what I would probably have done in your shoes. Or, if you started with a template that already had the staff size scaled, I'd have chosen whichever "A" sized worked best. Or, start in continuous view until you reach a point where the slowdown is intolerable, then switch to page view and make the choice then. Lots of options, really.
In reply to No doubt, in theory… by Marc Sabatella
You've got to remember that until this week, I did not know that the slowing down and errors were at all connected to continuous view, so they had nothing to do with my preference.
As for staff distance, I still find the need to add spacers on a regular basis in page view, so I don't find automatic spacing to be 100% effective and in continuous view, I can easily just increase the spacing manually.
As for other manual adjustments, I don't make any until I'm done working on the music itself unless it's absolutely necessary. I wait until the arrangement is essentially locked and then generate parts, check for errors, format each part for printing, and finish up with a printable score. Until things are locked, I find even small changes can force formatting to react.
Obviously, I'm going to have to revisit my process now that I'm aware of the problems inherent with continuous view. There's no warning for new users about those problems, so I've established a routine based on the assumption that it works. Sure, maybe I'll be able to develop an entirely new routine, and I might even end up preferring it, but it wouldn't be necessary if continuous view functioned properly. Like I said early on, I have deep affection for MuseScore and am impressed with how well it works and the dedication of the community that maintains and improves it. If continuous view is used so infrequently that it's not worth the time and effort to fix, I can understand it. Perhaps there should just be a pop-up the first time you switch to the view warning that it's unstable.
In reply to You've got to remember that… by Daniel O'Meara
I don't want to give the impression that continuous view is so unstable as to be useless - that's a pessimistic, and inaccurate assessment. But it does have the disadvantages I stated. Just as page view has disadvantages that hardly make it useless. Both are fine tools, and once you learn the tradeoffs, you can make best decisions.
If you're finding the need to add spacers, that could indicate a problem, so feel free to start a new thread and attach your score and explain the problem.