Musescore became very buggy in general
Hello. Ever since the last update, Musescore went from being a pleasure to use to being too buggy to use at all. Primarily, I am hindered by input and playback issues too numerous to list. Does anybody have any ideas as to why the program could be completely unhinged? Thank you.
Comments
I recommend not to use the musesound playback if your computer is below the recommendations. In that case playback is "buggy". I have not discovered any bugs while doing input.
In reply to I recommend not to use the… by azumbrunn
About system requirements, see: https://musescore.org/en/download#System-requirements
Hmm, the last update was 4.2.1, and it only fixed a few bugs, shouldn't have made any major changes. We'd like to help understand what is going on with your particular system and/or your particular score to trigger problems, but in order for us to do so, you'll have to describe the problem in more detail. best to attach a score and give precise steps to reproduce the problem. Y0uu allude to their being multiple problems; best to start separate threads for each.
I did not have a problem with 4.2 but I just updated to the new version (4.4.1-242490810, revision: 0b3dd00) and it is a nightmare of bugs and new problems. I'm happy to be patient as they get resolved but I just wanted to check in that it's not just me and I need to redownload:
Hairpin height does not save. Opening a file, saving in new version, closing file resets the height of all hairpins. Adjusting them in new version is no use. This information is simply not saved.
Slurs go crazy when I make random edits. I have to check the score after every edit, unclick and reclick "auto-place". Some parts of the score seem fine. Others, different slurs jump around for every edit no matter how small.
dynamics DO allow horizontal placement by time value (yay!) but linked dynamics even harder to manipulate than before. To shift up or down, I shuffle between all the linked dynamics, as it shifts by a tiny amount for each and then locks, and has to be shifted by another of the linked dynamics.
Tuplet numbers no longer movable by themselves when brackets are turned off. Grabbing a tuplet number and attempting to move it results in totally bonkers behavior that doesn't respond to Undo. Even when they work, manipulating the numbers from the endpoints of the invisible bracket is draconian; just getting the endpoints to select is tough.
Stems for cross-staff notation (and -rarely- ordinary notation) highly prone to vanishing.
Some note blocks randomly rebeamed (it happened to me only twice in 150 pages, but I have no idea why).
In some multivoice situations, the direction of slurs (above or below) was flipped.
I waited to update to the new version because i was in the middle of a project: a rehearsal score for a virtually unobtainable ballet, for IMSLP. I kept backups which I removed for each file after I had opened it, done the next round of edits, and found the results satisfactory. I didn't scour the score for strange additions and changes, and the backups are gone. But also, since the behavior seems unavoidable, it's unclear what I could do other than wait even if I still had them.
In reply to I did not have a problem… by rkhirst
Just a couple of examples:
I want to hide the "5" of the tuplet
![before hide 5.png]( "before hide 5.png")
![after hide 5.png]( "after hide 5.png")
Whoops!
Here, I was just lucky the slur that went nuts was in the visible screen so I didn't miss it. Also, there's only one slur over those notes, so.....?
Flipped slurs:
![flipped slurs.png]( "flipped slurs.png")
This poses a dilemma. I fixed them. Will I have to flip them again, when the bug is fixed?
In reply to I did not have a problem… by rkhirst
I can’t confirm much of this without being able to access your score and having precise steps to reproduce each problem. If your line developers to investigate, please open separate GitHub issues for each potential bug and be sure to ZIP and attach your score and give precise steps to reproduce each problem.
In reply to I can’t confirm much of this… by Marc Sabatella
While I've got you, are you not having any of these problems? For me, it's every file, everywhere. For example, the hairpins: I can no longer save the height of a hairpin, ever. The steps to verify are obvious. Create a file, add a hairpin, change the height, save, reopen.
The jumpy slurs, it's all the time. Ever since the update, slurs jump out of place virtually every time I touch a tightly packed line. Same with linked dynamics. There are no special steps. Every linked dynamic has to be shifted first by nudging one of the two, and then -when it inexplicably stops- nudging the other.. until IT stops... then back to the first. Same with the tuplet numbers. With brackets turned off, you could freely move the numbers like any other symbol. Now, they are latched to an invisible bracket. Every single one.
In reply to While I've got you, are you… by rkhirst
No, I've never noticed these things, but it could be I just hadn't run into those cases. I had not recently tried customizing the height of a hairpin, but I just tried it and can confirm that. So please be sure to open an issue so it can be fixed. Might be too late for 4.4.2 but they are planning a 4.4.3. I have used plenty of slurs and dynamics and haven't seen problems, but presumably there is something unique about your score or the things you are doing with them or the exact steps you are following, so again, please open issues (one per problem) and provide enough info to allow developers to reproduce the problems. Don't assume that others will understand a one-sentence description - precise steps (and/or a screen recording) are the key to successful bug reports.
In reply to I can’t confirm much of this… by Marc Sabatella
I'll of course do the due diligence for anything that's not been reported or turns out to be peculiar to me; I'm just a little antsy to understand what's happening with the new build. I put a two month project up on IMSLP and just directed the ex balletmaster of the Boshoi to it to get an idea of my work, only to discover that -after meticulously hand-setting every single page- it now houses a number of clumsy to bizarre changes introduced by a Musescore update, some of which I cannot undo. Is no one else having trouble?
In reply to I'll of course do the due… by rkhirst
Overall most people find 4.4 to be a huge improvement over previous versions, but sure. bug reports have been filed, and they are being fixed. Already some fixed for 4.4.1, more for 4.4.2 that will probably come out in a few days, and more still for 4.4.3 that will be a bit later. But I'm not aware of any reports that describe any major changes to the appearance of scores, which is why I'm guessing it will turn out to be something unique about your score(s) and/or workflow.
In reply to Overall most people find 4.4… by Marc Sabatella
Here's a test file. I made a few triplets, and a dynamic.
The height of that hairpin should be something like 2.05.
[Has it been reset to default? If it has, will you please check if all your hairpin heights are erased on close in the new version? For me, there is nothing about workflow. I can create a blank file, add only a hairpin, adjust the height, close the file. Reopen... and the height is reset.]
Click on the first triplet "3", flip it to the above position with "x" and now drag it. If it goes crazy, try using "undo"
[If it goes crazy for you, too, there are three issues here:
1. A needlessly complexified workflow for tuplet numbers:
In previous versions, when brackets were turned off, the tuplet number could be freely dragged without any reference to a phantom bracket and its endpoints. The number never collided, so dragging was perfectly natural.
2. Dragging is completely bonkers
3. Undo does not work properly]
In reply to Here's a test file. I made… by rkhirst
As I said, I was able to reproduce the hairpin height issue. So, just open the issue and include the precise steps to reproduce the problem. Based on this file, I can also confirm the issue with dragging tuplets. Soi this too is ready to submit as an issue. Workaround, BTW - use the offsets in the Properties panel.
The other issues are less clear what you mean. But if you are sure they are bugs and reproducible, just open new issues for those also (one per problem) and for each, attach the score and give precise steps to reproduce the problem. The sooner the better if these seem like they'd be important to fix in 4.4.3.
In reply to As I said, I was able to… by Marc Sabatella
Having trouble tracking this one down for a report. Loaded up an early version of one file, and hacked it down to two pages: squirrely noteheads.mscz.zip That's a 4.3 file.
Opening in 4.4, I get this on the second page:
![squirrely noteheads.png]( "squirrely noteheads.png")
That's just an ordinary block of sixteenths. It exports and prints that way, too. Giving it a nudge (even just "x" twice) fixes it, but the trouble is that it's happening in the first place. If you look closely, the notehead is also backward. This is not a one-off; I've caught several so far.
Trimming more measures off the score makes the problem disappear, so I was not able to isolate it. Thoughts?
In reply to Having trouble tracking this… by rkhirst
Looks like you customized the beam that grouping, and resetting it fixes the stem. Not sure what the intent of your customization was - it's actually too steep the way you have it. The default was better. But something about the customization causes a temporary glitch on initial layout. It fixes itself the next time the system is laid out (like if for instance if you just double click the text at the beginning of it and then immediately hit Esc). These bugs that fixes themselves on first relayout are often tricky to pin down but definitely worth reporting.
It's quite likely this particular bug isn't new but triggered by something about the calculation of the measure width or beam angle that just happens to be subtly different in 4.4 than 4.3. That's just a guess though.
In reply to Looks like you customized… by Marc Sabatella
That helps. I never have once had problems like this on an update. However inconvenient, changes to scores were not themselves layout errors, simply different layout interpretations. As I said, almost any fiddling fixes it (like "x" twice), the problem is combing through scores looking for them. I'll report it and hope it doesn't get closed for lack of specificity.
The steeper beams are an exceptionally common layout technique. You say "too steep" but the tilt is clearly an engraver's preference. There are a number of reasons to use more slanted beams than Musescore does, and they are virtually ubiquitous in the era of master engraving of piano music, and of course still quite common today, but this hardly seems the place.
This particular score was a monstrosity, but I always find it best to spend some time duplicating it stroke for stroke, to learn enough to be able to imitate it, even the bad ones. Also, I find it fastest to convert a score to digital by first copying the measure layout exactly, so that for note and symbol entry i'm looking at exactly the same thing in both windows. No hunting or measure counting; rapid entry. I occasionally made a half-hearted efforts to massage the layout, but the score was so bad, and Musescore is so unforgiving about hand set symbols while there are still layout changes to be made, I'm actually a bit surprised I even tried there. The final version, the beams are mostly hand-set.
In reply to That helps. I never have… by rkhirst
I’m glad you have had the good fortune to have never noticed any engraving g hugs before. Realistically every update fixes a few dozen but along the way accidentally introduces one or two new ones - such is the nature of software development. Overall, 3.4 has been no better and no worse than average based on reports thus far. Way more fixes than new bugs, as usual.
As for beam angle, if you have expertise and know what you are doing, engraving by all means, you’re welcome to make the adjustment. But presumably you also have enough expertise to know that the modern standards call for beams to be limited to no more than a staff space or two. I had no way of know how much expertise you have or what special requirements you are operating under. so I was just providing information to be helpful, in case you - like the vast majority of musicians - were not familiar with the conventions.
In reply to Overall most people find 4.4… by Marc Sabatella
I had to install a parallel previous version to test the other things, because they were changes that occurred on opening the files in the new version. Here is the next. I'm confident that since the first went for you as they do for me, that all the rest will, too.
Here is an eight-bar passage from Adam's Le corsaire, done in 4.2. Slur flip test.mscz.zip
![Multivoice slurs v4.2.png]( "Multivoice slurs v4.2.png")
![multivoice slurs v4.4.png]( "multivoice slurs v4.4.png")
It looks like this:
But, opened in 4.4 whenever the alto comes down to the bass clef, the slurs face the wrong direction.
Obviously this can create widespread monstrosities in a dense score, and does not depend on any personal preference of workflow.
In reply to I had to install a parallel… by rkhirst
Again, if you have steps to reproduce problems, open issues on GitHub and include the scores and steps. Posting here isn’t needed if you are confident the score and steps you provide are sufficiently clear and will allow others to reproduce the problem. Not sure what you mean about workflow - steps are steps, if the steps you provide lead to a bug, then thats what the developers will need.
In reply to I had to install a parallel… by rkhirst
The rule here is something like "when an inner voice is shifted up/down to the staff above/below, the slurs are improperly flipped". everything has been reported except three I'm still tracking down. Like the backward notepad with no stem above.
I'm just blowing off a bit of steam but I posted a bug report about the flipped slurs and was told it was my fault for not turning off auto-direction. This seems to me a worrying misunderstanding of how an application works from the point of view of the user, compared to the developer. I use the tools available to obtain the layout that I want. the auto-direction of slurs is generally quite good, and i use it. When I want a different direction, i flip it.
There is no need to turn off auto direction, because the final direction is always perfectly specified.
That simple statement could be the beginning and end of the matter. If the underlying behavior has been changed in the new version unintentionally, it will be fixed. If the new behavior is intentional it can be made compatible with all previous versions -for all time- by a simple check for affected slurs in a score imported from a version prior to the change. Assuming the new behavior is intentional, the new and old rules are known right now, and the check can be written without any difficulty. Result: seamless transition to new slur behavior for inner voices, without altering older scores.
But I was told it was my fault. This seems childish. Whether the developers intend the change or not, the effect for the end user is identical. If I write down on a piece of paper a secret "yes" or "no" that you could not possibly guess, and you come to me and say "here is a bug" and I say "oh yes indeed it is, but only if this piece of paper that I turn over says "yes"", something has gone wrong.
I also deeply resent being made responsible for outthinking auto behavior in Musescore, which is virtually impossible. Do the developers not realize that auto-placement behaviors dominate every aspect of the program? That auto parameters turn themselves back on arbitrarily on recalculations and there is literally nothing I can do to stop it? Virtually anything I want to adjust involves fighting against or turning off some kind of auto behavior, and at the same time, I cannot stop it from being turned back on.
Correcting these resets are so time consuming, I have adapted my entire workflow to avoid them. First, i break up scores into smaller blocks because resets are more likely on longer scores. But then, whenever I need to make significant edits on one of these blocks, I break it up into even smaller chunks. I make the edits on these reduced sections so that only a small number of symbols are affected if there is a reset. Then I apply the edits to the original master in the following order:
1. I apply the broad layout changes resulting from the edits, to the master.
[If everything resets that's ok:]
2. Once the measure and frame layout is updated, I paste the contents of each reduced section (where the correct placement has been preserved) back into the master.
3. Certain adjustments (like leading spaces before barlines) are not preserved under copy/paste. Do these last, in a final editing round.
The file has now been updated without losing all my hand placements to auto behavior. And now relying on auto-place is my fault?
I'm still trying to figure out why automatically including fixes that conform old files to new behavior changes so they can open in newer versions as a fully functional new-version file but with the original engraving preserved... is a silly utopian idea. Isn't it a good idea? If the changes are new, intentional, and affect fundamental behavior, they have to be documented anyway, so why would documenting them in code be bad or too much work?
(some code) \fix beams in previous versions affected by new behavior (version #)
It's better to leave the change undocumented? Refusing to conform versions across the boundary of a change makes for better code that's easier to manage? I find this impossible to believe.
Rant over.
In reply to I'm just blowing off a bit… by rkhirst
obviously for fine adjustments where the difference between old and new behavior is not easily defined or quantifiable, and the means of effecting a reverse placement not simple, that's a different story. But here there literally just needs to be a single boolean toggled on the affected slurs -which are perfectly defined- applied to files of a version preceding the change.
In reply to I'm just blowing off a bit… by rkhirst
I think you misunderstood. Yes, if you want to specify a particular direction for for a particular slur that realistically could go either way, and you want to be sure that this is preserved in future versions that might legitimately change the default in those cases, you should set the direction for that specific slur. So the vast majority would be left at auto, but just the ambiguous ones should be locked in place if you have special reason to care which way it goes even though it could legitimately go either way. That's just good common sense "defensive engraving".
So for the vast majority of slurs, this doesn't apply, because either the correct direction is unambiguous, or in cases where it is ambiguous, either position will work in your score. You only need to watch out for the cases where it's ambiguous and you have an unusual special reason to need it to be one way or the other.
This isn't "outthinking" automatic positioning, it's accepting that in the vast majority of cases,you can safely ignore this entirely and let MuseScore do it's job. Only in the cases where you specifically want to do something unusual would you need to think, and it's as simp[le as pressing "X" twice. If you miss an opportunity and later see that the layout has changed, just do it then, if you find the new default doesn't wioork for you for some reason. Again, the default is only going to change in cases where either is acceptable, so it shouldn't normally matter.
If for some reason you don't feel like picking which slurs you have an unusual special reason to lock, you could simply lock all slurs into their current position, by selecting them all (right-click one, Select / Similar) and pressing "X" twice (once to reverse them all, again to set them back. This is a useful trick to know.
BTW, in your common on GitHub you mentioned something about disabling autoplace, but that shouldn't have been needed here at all. You can flip slurs without disabling autoplace.
But anyhow, bottom line: each and every update to MuseScor potentially changes some default aspect of engraving, to improve the overall layout. usually this just silently improves your score. but if you encounter a relatively unusual situation where a change that imrpvoess most scores happens to be a step backwards for some reason in some particular measure of some particular score of yours, just fix it. Again, this happens each and every update and is part of the price of progress.
And yes, imagining that it is technically feasible to support each and every variation in the layout algorithms for all of eternity, so scores created in 1.3 continue to look the same even in 2.3.2 or 3.1 or 3.6.2 or 4.2.1 or 4.3.2 or 4.4.2 is a silly utopian idea. No piece of software works that way; it would be entirely unmanageable for further development. You need ti accept that engraving improvements will mean existing layouts will change, 9i9.99% of the time the changes are for the better but for those few measure sin those few scores where it isn't, you can override the new defaults. Or just keep using the older version for that particular score.
In reply to I think you misunderstood. … by Marc Sabatella
No. with all due respect, several slurs in that image could NOT go either way. And it was in defense of a new standard that set them through the middle of the page instead, that this comment was made. If we are talking about mere convenience I might agree, although -again- within whatever version I use, the direction is perfectly determined by a set of rules and in this case, it requires literally no more than a boolean of affected beams toggle to preserve continuity across versions. And -again- the resetting of manual parameters back to auto without my control or consent is so widespread and time consuming to correct, that without careful management from start to finish in the editing process, it's not even within my control, as it is repeatedly stolen back by musescore.
In reply to No. with all due respect,… by rkhirst
Hmm, maybe there was too much info in the issue report to make your point clear. The rule being followed for slurs I was looking at does seem like it could have gone either way, for the reasons Simon explained. Those particular notes seem subjectively like they were better with the slur one way, but other notes that would follow the same rule would make more sense the other way, as he clearly demonstrated.
In any case, it's quite simple to anticipate this case: slurs using cross-staff notation, with multiple voices, and stems pointing the opposite direction from the norm for that voice. It's not a very common situation overall.
But I have no idea what you mean about "resetting of manual parameters back to auto". That is no happening here. It has happened for very good reason in other cases, where the old defaults were clearly bad, the new ones clearly correct, and old manual adjustments made to overcome the old bad defaults would be disastrous if applied to the new defaults. Resetting those adjustments is absolutely the right thing to do there, and this has happened a few times in the past, although it isn't relevant here.
And the overall point remains: yes, sometimes improvement to the defaults do mean scores using those defaults might change - normally for the better. It does mean that if you choose to update to a new version of MuseScore to work on a score originally created on an older version, you might occasionally need to update some things for the corner cases where the improvements backfire. This was the case going from MU1 to Mu2, from MU2 to MU3, from 3.0 to 3.1, from 3.4 to 3.5, from 3.5 to 3.6, from 3.6 to 4.09, from 4.0 to 4.1, and each point release since then. Improvements are made constantly.