MuseScore 3 at 3 months
MuseScore 3 was released on December 24, 2018, and I've been posting opinions about it around each month's anniversary date.
The biggest news of the last month is that plugins have been fixed. You can now use many of the plugins that were available in version 2. My understanding is that there is still a problem with halftime and doubletime. I know there is still interest in continuing to improve plugins.
I don't currently use version 3 for 2 main reasons.
- Continuous view is unusable.
If you try to enter a score larger than about a quartet, it gets slow so quickly that the pause between pressing a note and it's display (and stop sounding) is intolerable. If you do have a small enough score the total lack of anything resembling formatting makes it nearly impossible to read what you have entered unless you put in large enough spacers to keep the flute notes from showing up on the piccolo staff and the lyrics from being unreadable because they are covered by the staff below.
- The bar lines are unusable
Unless you use the exact instruments in the template, adjusting the barlines so instrument families are joined, which is common, is an adventure not for the feint of heart.
One other problem that needs to be fixed is the MusicXML export. The last score I started in version 3 then gave up on, I decided to export it to MusicXML and open it in version 2 to finish. After all of the fixing of the garbage that was imported I regretted not just starting over. I figured 30 measures wouldn't be too bad to fix, but it would have been easier to just start over. The two things I remember dealing with were the cres. and dim. lines were all changed to < and > hairpins and every staff that had more than one voice had the entire staff filled with invisible rests in the other voice. At least I knew how to fix the barline disaster I imported.
There are still several issues with cross staff notation that prevent proper notations for pianos and harps. These are still in need of being fixed.
The poor management of windows is one more thing that is in great need of being addressed. Version 2 did not have problems with windows being too big to see the buttons on them and telling people to change the setup on their systems just for MuseScore is totally wrong. These issues need to be addressed. Either QT has bugs that need fixed, or the programmers need to learn how to use QT properly. I don't program, so I don't know which one it is.
MuseScore.com's lack of ability to keep up with changes is another problem that needs to be addressed. Every time a new version of the program comes out, it's as though the .com maintainers are shocked that there are changes made and new scores probably won't upload for a few days. Perhaps a little bit of testing and coordination would help with this.
I use version 2.3.2. I don't even bother saving them in version 3.x to make them look better on the website. There are way too many complaints about version 3 scores not uploading and version 3 does such a poor job of exporting to MusicXML that these scores are ONLY usable in MuseScore and not for other purpose like transferring to Braille.
I'll continue helping with the forums on questions in versions 2 & 3, and I'll continue waiting for a usable version 3. I'm looking forward to version 3.1 being released, at least in the beta version, prior to next month's anniversary - I hope.
Comments
I use 3.0 exclusively now. Have not had problems with bar lines or continuous view (which latter I use extensively). For me, occasional non-reproducible crashes is a glaring fault, as well as now fixed-in-the-source bugs with MIDI and hidden staves. The .com site falling behind in application versions is a serious problem, too, but small among the serious problems of the site and its support,
👍
I've gone and added the "barlines" tag to issues involving them, to help us keep track of them (seems easier and just as useful as creating an "EPIC" issue and tracking things that way). Can't say I found them all, but there seem to be a couple in particular that are significant regressions, and then a bunch more originally reported against much older builds I am not sure if they are still reproducible or not, etc. If you're up for it, feel free to do a search on tag "barlines" (or click this link: https://musescore.org/en/project/issues/musescore?text=&tags=barlines&s…) and follow up on any you see fit.
BTW, regarding window management, this could be very system-dependent. For me, MuseScore 3 is actually much noticeably better than MuseScore 2 about window sizes and positions, probably due to the exact same differences that make it seem worse for other people. Lots of variables including monitor resolution, OS version, system font scaling, Qt environment, and more. And FWIW, while we do have more complaints bout certain dialogs being too big, we have significant fewer complaints about the entire UI being unusably big or small. It's an almost impossible problem to track all the different variables here, unfortunately.
Regarding Continunous view - as I mentioned previously, in my tests it averages only around 20% slower and I think that's what other developers are experiencing as well. But you did post on score that showed a much much much bigger slowdown compared to 2.3.2. I would encourage you to open up an issue and attach that specific score so someone can look to see what about it is causing the slowdown. Could be whatever other scores you are seeing that have similar slowdown have similar elements to them. Would be nice if it turns out there is one specific fixable thing that would help continuous view for that particular subset of scores that experience a significant slowdown.
In reply to I've gone and added the … by Marc Sabatella
As far as the barline are concerned, there are already so many issues open that I won't even attempt to try to understand how to fix them until they go through a major rework and someone not named Marc Sabatella says they work.
I don't remember many complaints about the UI being small and unusable in version 2, perhaps you're remembering version 1, which I used for about 3 days before I gave up on it.
Which score did I attach. Haydn's 2nd?
In reply to As far as the barline are… by mike320
I'm not asking you to understand how to fix the issues, I'm asking for your help in sorting out which are still active, which are regressions, and your impression of their severity. Because I absolutely agree there are a lot of issues there, and we could use help in prioritizing them. Not sure why you wouldn't trust my assessment of whether a bug has been fixed or not. Would you not I agree I have a pretty good record when it comes to fixing bugs successfully? Have there really been that many cases where I've said I've fixed a bug and it turned out not to have been fixed? Or maybe you are under the mistaken impression that I am somehow claiming about barlines that "they work" well now? Quite the contrary, I am agreeing that barlines are one of the biggest remaining problem areas, which is precisely I was asking for your help in assessing the situation, so we can focus on fixing the ones you think we should fix first. Sorry if this somehow wasn't clear.
There were indeed extremely many complaints about UI being too small in 2.x, I'm surprised you missed them, maybe I am more sensitive to it because I responded to so many of them. But see for example #106241: Monitor resolution detected incorrectly, making sizes wrong. Dozens if not hundreds of similar reports in the forums over the past several years.
As for the score you attached that had the significant slowdown, I forget which it was, but yeah, might have been Haydn. It's the one you posted when I asked if you had examples of scores that more than the known / typical 20% slowdown in continuous view as compared to 2.3.2. I recall measuring it as more like 400% (5x). Might well have been Haydn.
In reply to I'm not asking you to… by Marc Sabatella
The barlines are so messed up I don't know where to start. I have no idea how to work around the problems to figure out what needs to be fixed. I do what I did in version 2 and it doesn't work. I selected all of the barlines on a staff and reset them to their defaults and the barlines became unusable. There was a report a few minutes ago of not being able to double click a barline to extend it to the next staff. This is one example and may be at the heart of the issue. I didn't comment, because I don't know how to help the person.
#106241: Monitor resolution detected incorrectly, making sizes wrong is one issue that was reported multiple times and I consider that one issue. The fix was to tell MuseScore what it couldn't automatically detect. The current fix is to reconfigure your system just for MuseScore when the current settings work on every other program. That's not an acceptable work around. If there were a command line option to fix the huge dialog boxes, that would be acceptable.
Yeah, I think the slow score discussion happened on telegram. Here's the link to my .com page for that score. https://musescore.com/user/6105546/scores/5435811
I'l open an issue if that's the right score.
In reply to The barlines are so messed… by mike320
What I can say regarding barlines is that without a sense of where to start, it's hard to start, but one has to start somewhere. I look at the issue tracker see no barline issues marked P0, and around a dozen marked P1. Of those, some are not regressions - they are things that never worked well in 2.x either - and others are feature requests, not bug reports. Some were reported originally on a beta build and may no longer apply, some are only reproducible with a single posted score, others not reproducible at all that I can tell. Some seem serious at first but turn out to have trivially simple workarounds. Others are probably quite serious but aren't explained well, with sample score and clear steps.
To me, "where to start" is, help go through those existing issues and bump the ones that should be marked P0, providing sample score and clear steps to reproduce where needed. This is the sort of thing I already did for issues with cross-staff notation, for small staves, and for invisible staves, and as of today all of dozen or so critical issues I identified in this process are fixed in master. I see absolutely no reason barlines can't be next. And FWIW, in my own considerable experience using MuseScore 3 for a number of real-world projects and tests, barlines are not actually in as bad a shape as these other areas were, so I don't actually think it will take as much effort to fix as it did to fix those others. Anyhow, if you've got a backlog of issues you haven't submitted, now would be a good time.
The resolution issue I linked, BTW, is actually lots of interrelated problems that sort of got dumped into one thread, and indeed, the current issue that a small subset of users set with dialog sizes is also part of that same basic problem. In short, it is that we don't always get good info on resolution and font sizes from the OS and/or Qt and this makes it hard to calculate good sizes for elements in our GUI. There are just more combinations of monitor resolutions, system font sizes, system scaling, and other factors (environment variable settings, etc) than one could possibly imagine. I'm not saying it wouldn't lovely to sort them out, but the reality is, it's far more complex and system-dependent than people realize, and it changes stupidly often (eg, a new OS or Qt setting is introduced to supposedly improve high DPI behavior but has the effect of breaking things that used the old way) Way too much system software was written in a world where all monitors had roughly the same resolution (72-96 DPI) and this "brave new world" of "retina" and other high DPI displays is something the OS's and libraries like Qt just plain don't have a good solution for yet, making it next to impossible for cross-platform application developers to deal with. It's frustrating indeed, to all of us.
In reply to What I can say regarding… by Marc Sabatella
FWIW, I made another pass through issues with the word "barline", made sure they had "barlines" as a tag as well if they really do have to do with barlines (some were unrelated), and fiddled with the priority. There are now 4 P0's - one of which I have a fix for, one there is a PR that still needs some work, and two that need to be looked at but I don't think will be all that involved.
In reply to FWIW, I made another pass… by Marc Sabatella
Another update: I have now submitted PR's to fix all the high priority barline regressions I could find (and a couple that weren't regressions but were broken in 2.3.2 as well): see https://github.com/musescore/MuseScore/pull/4843
Feel free to go through the issue tracker to see if there are things I've missed that seem especially critical. But probably not worth looking for new bugs until my changes here get merged.
In reply to Another update: I have now… by Marc Sabatella
As I previously stated, the barlines were so bad I didn't know where to start. When 3.1 beta is released I checkout the barlines to see if they're usable. I'll start a new forum topic at that time if necessary so we can see which bugs still need fixed and which need new issues.
In reply to The barlines are so messed… by mike320
And yes, that's the right score, I found where you posted it:
https://musescore.org/en/node/285741#comment-903935
and my response:
https://musescore.org/en/node/285741#comment-903943
I would love to see Musescore succeed and I've always put money into it... but I'm so disappointed with 3. I find it crashes. I keep getting random clefs showing up in bars where the clef hasn't changed. I get layout problems. Print problems. It is alpha at best.
In reply to I would love to see… by revdjohngoodman
You need to be way more specific and report one issue at a time in as much detail as possible.
In reply to I would love to see… by revdjohngoodman
It is alpha at best
@revdjohngoodman
It's probably more like a Beta, but that's a meaningless debate. I voiced strong objections to version 3 being released back in December. I even objected to the beta being released as a beta because it was in such a poor state at that time. I was not alone in criticizing these decisions.
In the open source environment with few paid employees, you need feedback from users and volunteer contributors to get problems fixed. Releasing it way ahead of time increased the number of testers by a large number. Every final release has had the same results - more feedback. More people use it, more problems get found, and more improvements are made. I've been rather frustrated by this process at times, but it has sped up the improvement of version 3. Let's face it, this is free software and you and I can have a huge impact on its development. MuseScore is much better today than it would be if it were still called an alpha or beta because of the many additional voices helping to improve it.
My only criticism about the actual release now is that it has been wrongly touted the most stable version yet. It has WAY too many crashes and other problems to live up to that billing, but I hope that before long this will be an accurate statement.
In reply to It is alpha at best … by mike320
So you're saying that 3.0.5 has more crashes than 3.0.4 or any other before that? I Very much doubt that, I'm not aware of a single regression between the current and the previous release that causes a crash.
3.0.5 is pretty stable as far as I can tell.
Not bug free though, of course.
And not yet at a state like 2.3.2, but then again it has just 3 months on its back, not 3 years.
In reply to So you're saying that 3.0.5… by Jojo-Schmitz
And not yet at a state like 2.3.2
My point exactly.
In reply to And not yet at a state like… by mike320
But far away from an alpha or beta state, which is my point...
In reply to But far away from an alpha… by Jojo-Schmitz
If I had to pay for it I would demand my money back as of the latest release. This puts its quality as lower than a release quality. As I said, it's far superior to what it was when 3.0 was released, but it still needs work.
In reply to If I had to pay for it I… by mike320
Good luck trying that (getting the money back) with any commercial software. You won't even get fixes as fast as you get them here.
In reply to It is alpha at best … by mike320
mike320, I think those are great points you bring up, thanks for stating them so well!
In reply to It is alpha at best … by mike320
Releasing it way ahead of time increased the number of testers by a large number.
Indeed, newbies unwittingly become 'testers' - with resulting frustration.
Had development builds (nightlies) been allowed to "cook" a little longer (as they used to be) that Start Center problem with Macs would have surfaced and been solved well before the official release. It would have avoided a flood of complaints to the forum.
In reply to Releasing it way ahead of… by Jm6stringer
This is the price to pay for open source software.
In reply to This is the price to pay for… by Jojo-Schmitz
OK... but...
It seems like the price (especially for newbies) went up on this release.
When I was a newbie (MuseScore ver 0.9x), if someone at that time suggested running the app with a command line option, for example, to disable a 'buggy' feature; today I'd be answering Lilypond forums. ;-)
Also, I thought the software was 'free' and the 'price' is contributing - e.g. answers to the forums, testing nightlies, coding... not racking one's brains trying to obtain a pleasant OOBE (out of box experience).
Nowadays, I miss the "How can I delete a rest?" posts.
Regards.
In reply to OK... but... It seems like… by Jm6stringer
In those 0.9x days I did use MuseScore as a frontend for Lilypond :-)
(sometimes)
In reply to OK... but... It seems like… by Jm6stringer
Hahahaha.
In reply to OK... but... It seems like… by Jm6stringer
On the other hand, how long was it between 0.9.x and 0.9.x+1? There were quite obviously some major bugs that then, and generally one waited months or years for fixes. I don't know about prior to 0.9.6 because that's when I came on board, and that's as far back as Wikipedia goes, but it was 10 months from 0.9.5 to 0.9.6, and 8 months from 0.9.6 to 1.0. Whereas the bug I assume you are referring to in 3.0.x that caused a subset of users to need a command line option was fixed within a couple of weeks. Are you seriously suggesting it was better back then?