Version 3 at two months
I posted an editorial on the release of version 3 on the one month anniversary of the release of MuseScore 3. This post is a few days late and a day after the release of version 3.0.3. With this release I'm willing to actually start using version 3 rather than using it to help others and track down bugs. I haven't sold out to version 3 yet, because there are still some bugs that must be fixed for me to only use it.
I have started a project to host Braille scores on MuseScore.com located at https://musescore.com/openscore-braille. I do not allow version 3 score to be added to this project due to problems with export to MusicXML listed in #281511: [EPIC] Braille friendly musicxml export. Until these are fixed, scores created in version 3 are impossible to convert to Braille based upon the MusicXML exported by MuseScore. When it's possible to convert MusicXML to Braille, I'll require all scores to be in version 3. Since I upload all of these score, I can quickly convert version 2 scores to version 3 so they are sufficient for Braille conversion. This is one of 2 personal stoppers issue I still have with version 3.
My other issue is that there are problems with import, mostly related to importing text. I have a large project I'm working on that uses custom system text. When the score is imported, it converts the text to regular staff text. It would take too long to fix all of these occurrences in version 3, so this project will continue in version 2 for the time being. See #277501: individual text style is not imported from V2-score and #282236: Custom text ignores system flag when imported into 3.x. I am not the only person with similar issues.
There are still some issues with basic layout that were not addressed in the last two releases, like #279182: Cross-staff slurs/ties trying to avoid note on wrong staff, #280969: Cross staff 8ths lose beam if all notes moved to staff above . There are some critical (perhaps should be stopper issues since they cause crashes) relating to beams like #282352: Beaming 8th notes across barline and creating text causes crash. I didn't analyze all of the issues, but there are a couple of pages of Blocker issues that are still open and about 20 Critical issues with "PR created" as the status and around 50 more issues with "PR created" as the status since the release of version 3 in December. I realize some of these will never be merged, but there should be a comment on all of these with the status changed appropriately.
There are several Critical issues that relate to basic notation. Many of these prevent MuseScore from doing its basic function of notation. Some of these things, like #284434: "hide courtesy key signature" not working when hiding for only one staff of multiple-staff score from context menu and #284810: Lyrics verses overlap in the PDFs for parts prevent a professional score from being printed. There are professional printer who use MuseScore and cannot be reasonably expected to use version 3 until several issues are corrected.
From a user's point of view, until plugins work the way they did in version 2, it is impossible or very difficult to make scores like those in version 2. Among the most critical plugins is the TempoChange plugin, which cannot yet be ported to version 3.
One other item that I've heard nothing about except complaints is the MuseScore Drumline. This either needs fixed or an official statement saying it will not be updated for version 3. Users don't know what's going on with it.
In the past, there has been a delay in having MuseScore notify users of a new release, so if there is a disaster that is not found until release it can be fixed prior to full scale release of a new version. Version 3.0.3 has a disaster with playback that is a deal breaker for many users. Notifying users of this release automatically is not the best decision. It fills the forum with a large number of complaints about the same thing and it gets tiring telling people the issue is being worked on rather than helping users with real questions.
I don't want you think I have ignored all of the work being done to improve MuseScore. It has been noticed by me and others. The extreme slowdown that I've experienced in the past seems to be fixed. This makes it possible to use version 3 for symphonic scores, which I found impossible prior to version 3.0.3. The number of bug fixes between versions 3.0.2 and 3.0.3 is impressive. Thanks to all of the programmers, especially the volunteers, who have done this.
Comments
Nicely sums up the status.
👍
Very nice summary. For me MS2 is also still the workhorse, as MS3 has still some regressions blocking my workflow (generating MIDI files to be used in my DAW). Nevertheless I started to use v3.0.2 to tidy up my scores before generating PDF and / or printing. It does an incredibly nice job on that, so thanks to all the developers for the effort!
What makes me sad about v3.0.3 is that it was released although the "piano bug" introduced by fixing part playback was known a week prior to release. It is often said that playback has a lower priority in MS compared to producing sheet music, but so far I never had the impression that it also means accepting regressions in playback. I also agree that a sligthly more conservative update strategy would be helpful.
In reply to Very nice summary. For me… by drowo
What is the problem with MIDI export in MS3?
Exporting midi from MS to my DAW is also part of my workflow. For me it works as expected - MS 3.0.3 generates standard midi files. Is there something I should be aware?
In reply to What is the problem with… by woland
I generate midi files from parts, not the whole score. The DAW is cofigured to directly use those part-midi-files. After each change (even small ones) I export the part midi files and therefore overwrite the files in the DAW, which automatically re-reads them. This way I use Musescore more or less as an editor for my DAW (just in one direction, of course).
I use a tweaked instrument.xml giving me 6 midi channels per instrument, which I use to select different articulations in my VST instrument. I have templates for those instrument with some standard sustain sound on channel 1, more expressiv on channel 2, marcato on channel 3, etc .... which I change using staff text.
In MS2, each part started with midi channel 1, so I could directly use my templates without having to readjust the midi channels. In MS3, the midi channels depend on the position of the instrument in the score: The first one will have 1-6, the second 7-12, the third one 13-16 + 1-2, etc ...
If I would now adjust the VST to those channels and insert aother instrument in Musescore, I would have to redo the channel assignment. I have entered an issue on that, but lets see ...
Thanks for your comments!
I would encourage you to comment in the threads for the specific issues you feel are the biggest roadblocks. In particular, I am a bit mystified by the importance you gave to two that you mentioned specifically (an issue with disabling courtesy signatures for some staves but not others, and an issue with spacing of lyrics on export of so far only two known scores), so it would be good to understand how these have impacted you.
If I were to create my own such list - as you may know I used to do with my "hit lists" - the issues I think of as most critical in terms of being regressions from 2.3.2 that are likely to impact some common use cases are in a few areas specifically:
This list would includes several of the issues you did mention.
2.x import is to me in another class, something that unfortunately no matter how much more work in invested, there will remain cases where things aren't perfect, so it's kind of hard to get a handle on where the best bang for the buck is, but again, feel free to comment and bump the issues you feel are most significant.
MusicXML export is indeed going to be important for some subset of users, not just for eventual Braille conversion. I'm surprised the list of regressions is so long - are we really sure that all of those worked in 2.3.2? Regarding the Braille project, I'd personally still encourage people to create scores in 3.0 and hope the MusicXML issues are fixed before long, otherwise more work is created as then people have to worry about the work involved in import their 2.3.2 scores into 3.0.
In reply to Thanks for your comments! I… by Marc Sabatella
These are not all issues which necessarily impact me. I indicated the couple of issues where I had a personal interest. The key signatures that show up unexpectedly make using a score with that impossible to use for someone making a professional score. The issue with lyrics being printed on top of each other in a PDF have similar implications. I didn't go into detail in the bug reports, but there are no workarounds indicated, except possibly making a spurious key signature invisible (I don't think that's always possible), then you end up with a mysterious space (from an end user's point of view).
In reply to These are not all issues… by mike320
OK, good to know.
The key signature issue you linked to is real enough, but it's a very specific use case that I've never heard anyone actually request (being able hide a courtesy key signature for just one staff of a multi-staff score). The user in that report didn't actually mean to do that, they did it accidentally. And if your goal is to have it disabled in one staff, marking it invisible is actually no different because we'd still need space for the other courtesy signatures. So overall this seems more a curiosity than a blocking problem. Maybe you were thinking of a different issue? Through what I believe to be an oversight, #280390: Spurious key change after transposition was not included in 3.0.3 or 3.0.4, but was merged for master quite a while ago, and other reported problems with spurious key signatures have also been fixed already.
The issue with the lyrics spacing is indeed potentially problematic, but to be clear, it only applies to the "export parts" command, not ordinary PDF export, so I don't really see that as being as much of a blocker as it may have appeared at first glance. But I can confirm it applies to all scores, the small staff turned out to be a red herring. And now I've got a PR submitted.
I am really quite happy to work on the most important issues, but I do think it is important to get a good handle on what those actually are. Which is why I asked about these two specifically - if we know of real world use cases where these issues are in anyone's top ten biggest issues. Personally, I'm still thinking any of the other issues mentioned are more important.