MuseScore 3.3 Release Timeline

• Aug 27, 2019 - 08:56

We are nearing the release of MuseScore 3.3!

Thanks to the hard work of the community, we improved already stable release of MuseScore 3.2.3.

  • @DLLarson exposed a lot of properties and made fixes for the Plugin API
  • @Tantacrul redesigned and @dmitrio95 implemented the redesign of the palettes widget. The goal was to simplify customization of the palettes and get away from the master palette. Check it out in the Beta version and let us know whether we succeeded :)
  • @MarcSabatella made a lot of improvements for the accessibility of the editor including navigation
  • @lvinken made a lot of improvements for MusicXML export and import
  • @Jojo-Schmitz made MuseScore work with the latest version of Qt on Windows which reenabled NVDA support
  • @mattmcclinch implemented some of the Tantacrul's ideas related to the Note Input workflow

Many other developers and testers reported and fixed bugs and implemented improvements which have made MuseScore better and more stable.

Description

Updated: 24 October 2019

We have already implemented essential improvements related to the appearance, usability, and customization possibilities of the palettes. We are focusing on new users to let them understand MuseScore's facilities faster and easier, yet keep the workflow for experienced users the same or significantly simplify it.

One more thing we want to see in the upcoming MuseScore 3.3 release is the Tantacrul's Note Input workflow redesign implementation. @mattmcclinch generously helped the project and implemented the most significant part of the usability improvements. The changes were not massive, but significantly improve the UX of the Note Input workflow. It allows users to enter notes right after clicking proper duration without the necessity to enter "Note Input mode." At the same time, nothing is supposed to be changed in the usual workflow.

Meantime, the changes to the Note Input workflow have revealed the problems that the editor had all the time. The editor doesn't always show the currently edited place as it is done in text editors. As a result, the user might add, delete, or edit elements that are not in the current view, and do not even know about it. We are working on the solution to ensure any changes move the viewport properly.

After testing the changes, we will publish MuseScore 3.3 Release Candidate 3, which will contain all the changes that we plan to include in the final release in October.
ETA for RC3 is October 28.
ETA for the final release is October 31.

String Freeze remains valid, which means no new lines will be added until release. Translators have time to complete the translations until October 31, 9:00 UTC.

Timeline (Updated)

October 26-28

MuseScore 3.3 Release Candidate 3

October 31

MuseScore 3.3 Final release

All dates are realistic estimations which might be changed at any time. There are no guarantees :)

Comments

• Aug 27, 2019 - 11:12

Qt > 5.9 for macOS would mean to drop support for macOS 10.10 and 10.11 (or have a separate build for those), so is unlikely to happen any time soon.
For Qt 5.12 we're still waiting on 5.12.5 to get released (and also to be made available on AppVeyor, for the Windows builds), so for the time being we got to stay on 5.12.3, 5.12.4 having a bad bug, esp. with plugins, see https://bugreports.qt.io/browse/QTBUG-76509

Reply

• Aug 27, 2019 - 11:40

That doesn't address the problem. That's just putting up a sign, *No se habla español". That way, plugin writers can make the plugin say "Sorreee!" , a world of no-Mac plugins. Plugin writers would have to be acutely aware of ECMA 5/6 differences, with no way of checking that they got it right,

Reply

• Aug 27, 2019 - 11:43

Sorreee, to me printing "Sorreee!" is "failing". A better solution is needed. "The Black Art of Plugins Manual" would have to explain very carefully, "Ye must write plug-ins in an olde dialect of ye Java-scrippt, lest it not work on ye olde Mac!" What about the C++ code? How can you make fixes and upgrades or take advantage of Qt improvements if Mac not?

Reply

• Aug 27, 2019 - 11:52

I'm willing not to code for new ECMA features, sweet as they are, as long as my plugins can be debugged and be ensured that they will work without change on all platforms. The problem would be people on windows, esp Javascript programmers used to ECMA6 features, writing programs that either fail on the Mac, or are declared Mac-only (with version check) for this reason alone. As a matter of fact, if the Mac is forever stuck with 5.9, plugin writers like myself writing on the Mac can't possibly create plugins with this problem. But not so plugin-writers in Windows. Someone will have re-debug them in ECMA 5.

Reply

• Aug 27, 2019 - 12:03

Not true. We may be able to build 2 MuseScore versions for macOS, one with Qt 5.9 and another with 5.12. Or just switch to 5.12 and drop support for macOS 10.10 and 10.11 (with MuseScore 3.2.x remaining the only version for that), maybe @Anatoly-os can share some statistics about the platforms used?

What features exactly are you talking about BTW? And why hasn't that come up before, we're using those different Qt versions since quiote a while.

Reply

• Aug 27, 2019 - 12:30

The first time Dale sent me a plugin he had built, it didn't work, it "had syntax errors" and it took me a while to figure out that this was the problem. He reverted to 5.9 for me. Here is a beautiful page listing and explaining all the ECMA 6 features. http://es6-features.org/#Constants . The features are many and beautiful. It's been around for a while, and serious Javascript programmers are used to it. 2 versions might be a way to go (but MacOS 10/11 users couldn't use such new plugins). I myself have built MacMuseScores with 5.12, and had to revert to 5.9 to ensure that my plugins (which will be very popular when 3.3 is born for real) would continue to work.

Reply

• Aug 27, 2019 - 12:36

As far as I can see for most of those new ECMA 6 features there are ways to write it in ECMA 5, so a workaround is available. Or are there ESMA5 thing that won't work with Qt 5.12?

Switching to Qt 5.12 for all platforms means loosing macOS 10.10 and 10.11, no workaround (also loosing some Linux variants BTW).
Going back to Qt 5.9 for all platfoems means no NDVA, no workaround (and some Linux variants will go with whatever Qt comes as part of the distribution, so well may be in 5.12 or even later).

Reply

• Aug 27, 2019 - 12:52

There is no question that there are write-arounds, and it is possible to code in ECMA 5 in an ECMA 6. That is not the problem. The problem is that any established Javascript programmer coming to plugin programming, on Windows, will unknowingly create plugins that fail on the Mac unless he or she is acutely aware of the 5/6 differences, and gets it 100% right without any way to test/check, or says, "I don't care about Macs", i.e., the platform-independence of plugins will become very, very iffy. If there were a way to tell Javascript "flag ECMA6 features (maybe there is?)" the way C++ compilers can be told what standard to abide by, this would be easier. but AFAIK there's not.

Reply

• Aug 27, 2019 - 13:04

I got that from the start. The alternative of either dropping macOS 10.11 and 10.11 or NDVA is worse though.
So restricting ourselfes to ECMA5 seems the far lesser evil for the time being, esp. as plugins are only used by a pretty small fraction of the user base.

Would this help to tell them appart?

try {
  var k = new Map();
  console.log("ECMA6 supported!!")
} catch(err) {
  console.log("ECMA6 not supported :(")
}
<qml>

Reply

• Aug 27, 2019 - 13:35

No, that would not help at all. I'm not sure you see it yet. If a plugin coder consciously requires ECMA 6, he or she is saying, "I know that this script will not be usable on MuseScore on the Mac; too bad, Mac users! Get a Windows!" Such a check would merely simplify this behavior. Is that behavior to be encouraged? --As you observed, not one such feature is "necessary". But if he or she unconsciously uses ECMA 6 features (perhaps unaware of the issue we are discussing) it will generate plugin bug reports left and right when it fails mysteriously on the Mac.

Reply

• Aug 27, 2019 - 13:43

How will you know? Who is going to study their plugin, look at its subtle run-time data handling etc and validate that it will work on the mac/ECMA5? We don't vet plugin-writers, either. How will plugin writers even know? Whose responsibility is it to make sure that this procedure is successfully followed?

Reply

• Aug 27, 2019 - 13:51

Right. And I'm pretty sure the above is the case, as for those users in deed of NVDA there is no workaround and it'd render the entire MuseScure unusable for them (a bBlocker), while here for the macOS users (which are, compared to Windows users, in the minority already) those that want to use plugins (which is just a fraction of them) won't be able to run plugins using ECMA 6 features (which most probably will be a very small number), which in turn be a minor nuicance at most would and with an easy workaround (rewrite to ECMA 5).

Reply

• Aug 27, 2019 - 14:02

Actually, no, it's not an easy workaround for the person who has Windows MS with Qt 12. And it will not be up to the plugin "victim" to rewrite it, but the plugin author, who will have no way of testing his or her supposed downgrades when the complaints roll in. It will fall on experienced Mac plugin writers to do their work for them, a fraternity in which I barely count myself, and mandate a submission path for the latter ("us") to upgrade (or, rather, downgrade) the former's plugins. It's sort of like "Mac accessibility"; to the person not encumbered by Qt5 compatibility, they would not be so concerned about those who might be, especially when there is no easy path to ensuring it. At least I know that plugins that I write are upward-compatible of necessity.

Reply

• Aug 27, 2019 - 14:06

Well, it is up to the user to report to the author and/or rewrite the plugin or find someone else to do it, indeed.
But still this is only a very small minority, and the other 'workaround' is to just not use that particular plugin, simple as that.
I have yet to come across a plugin that is absolutly vital to be able to use MuseScore.

Reply

• Aug 27, 2019 - 14:14

You don't need STL to write C++ programs. You can use strdup, malloc, and strcat and buffer overruns etc. But life is much, much better with STL. Same with C++11/14 features! Not needed!

You don't need the tempo-change plugin or my new articulation plugins, but they make all the difference in how the music sounds ("but we're not a performance engine!"). Fortunately, they work on the Mac. But we're entering a "segregated" plugin world, where which "caste" a plugin falls into cannot even be accurately and easily determined by its author unless he or she can verify full function of his or her features on a Mac. The whole point of using Qt is that it offers precisely such compatibility.

Reply

• Aug 29, 2019 - 20:59

Heres a 5/6 issue that came up on another thread. Plugin object-wrapper objects are shared between concurrently-exposed (e.g. dock-type) non-cooperating plugins; it is thus undesirable to store properties in them. One could make a map of objects to further structure, except Maps of non-string keys or ECMA6 only. Thus, the workaround to the workaround needs another level of workaround, which can't even really be done (there is no write-around for object-keyed maps) unless the underlying wrapper system supplies some kind of help, or we ("what do you mean we?") decide, "oh, to hell with Macs -- not that many people use them anyway"; they can do without plugins.

Reply

• Aug 29, 2019 - 23:16

That's a bit extreme. Tons of useful features can and have been written without the latest esoteric language features, and I see no reason these can't continue to work, unless I'm missing something. So a few cool new plugin features of interest to a few folks might have to wait a bit, doesn't seem like the end of the world to me.

Reply

• Aug 29, 2019 - 23:24

My argument earlier in this thread says that ECMA6 is not so new at all, and plugin writers are bound to no ethical code, and if allowed in 3.3 to use ECMA6 on Windows, will not think twice about using minor language features, like destructuring assignment and for-loop iteration over lists, and their code will work just fine, on Windows, and they might not care too much if the minority with Macs can't use it, for "restrict yourself to older language features", without a "-std=ecma-5 control argument" as in C++, will have little means or motivation to cater to people "stuck with Macs". And JoJo did hint that the Mac Minority was "less important", and that plugins themselves weren't all that important. This will lead to plugin "static castes", if I may.

Reply

• Aug 29, 2019 - 23:37

I never said that.
I merely said that the combined number of users that a) use a Mac and b) use plugins and c) want to use plugins using ECMA6 features are very, very, very few.
And that for those a) workarounds exist, as almost all Ecma6 features have Ecma5 equivalents and b) the number is users needing accessibility are more important and without any workaround.
I'm rather disappointed that you argue the way you do...

Reply

• Aug 29, 2019 - 23:41

I'm sorry if I misinterpreted your position. Maps do not have an ECMA5 equivalent. And yes, accessibility is really important. There are no plugins using ECMA-6 features, so the argument that not many want to use them doesn't carry much weight. Frankly, I don't know how to solve this problem. It is a hard problem. I hope I don't sound like I have a secret or radical solution in mind. I don't. I'm sorry again if I'm arguing unreasonably. I'm just scared of chaos or downgrading of plugins as a direction. Accessibiity is really important, as is support of OS X 10/11.

Reply

• Aug 29, 2019 - 23:51

So, sounds like the ideal solution is to find the right Qt option to simply generate a syntax error on Windows if someone tries to use a new language feature not supported in Qt 5.9. Or failing that, then as you say, simply documenting it clearly that new language features aren't supported on all systems.

The point being, the issue is merely one of documentation - making it clear to plugin developers what is supported and what is not. I don't see how that's a big problem - we document lots of things, I don't see what makes this inherently harder to document than anything else.

Whereas the accessibility is one of functionality (as in, the entire program is entirely unusable). So yes, in the grand scheme of things, I think it fair to say that documentation issue is less important. Certainly, you don't make MuseScore entirely unusable to entire populations of people just because some plugin writer might not read the documentation (although I'm not sure how they'll manage to write a plugin if they don't!) and thus might end up writing a plugin that doesn't work on macOS and that such a plugin (which may or may not ever exist) would not work for macOS users. Plugin writers can write a lot of code that doesn't work well, there really isn't much we can do about that. But we want MuseScore itself to work for everyone, and there is something we can do about that.

Anyhow, to me this entire discussion really belongs in a separate thread.

Reply

• Aug 27, 2019 - 14:54

Nice timeline.
It offers at least about a month of testing and correction time.
I look forward to the release of Beta.

My sincere thanks to everyone who has contributed.

Reply

• Aug 31, 2019 - 19:39

Has any progress been made on making Musescore run faster? I remember it was one of the goals for the release of Musescore 3.0 that editing would be just as fast regardless of the size of the score.

Has there been any progress on that?

Reply

• Aug 31, 2019 - 19:54

A significant progress has been made and delivered in versions 3.0.5 (May) and 3.2 (July). There were no significant work done in the scope of the upcoming release.

Do you know something specific about the performance? Could you please share your observations on this topic? Maybe, separate forum thread is a good place to start that discussion. Ping me there via @

Reply

• Oct 11, 2019 - 14:50

There is no documentation available yet for the new palettes, correct? I'd like to make sure I know how things are supposed to behave before I start reporting bugs…

Reply

• Oct 11, 2019 - 15:04

I'm not aware of any yet. Feel free to ask questions (best to start a new thread). But FWIW, given that one of main purposes of the redesign ws to improve usability and specifically discoverability of features, to some extent, I'd say if you can't figure out how something works, that's kind of a bug in itself.

Reply

• Oct 24, 2019 - 16:55

There's a lot to the design proposal, but in practice, what is actually implemented isn't as dramatic a change as one might fear. Matt McClinch can say more about specifics, but we've been discussing it on the developer chat on Telegram, and I've been playing with a build of it, and I don't think there is so much to be concerned about here. It's definitely worth discussing, so we all understand what's actually involved - but best to do so in a separate thread.

Reply

Do you still have an unanswered question? Please log in first to post your question.