MuseScore 4.2 Beta now available

• 2023年11月24日 17:20

Hi everyone,

As promised, we have a beta build ready for MuseScore 4.2, which you can download from our release page over on GitHub:

Once the beta is installed, it will show up on your machine as “MuseScore 4 Testing”. You can install it alongside your current version of MuseScore 4, but please be aware that the two versions will share preferences and workspaces. Also, if you save any score files with 4.2 then you will not be able to open them with previous versions of MuseScore 4.

If you find any issues, please report them on GitHub. As always, please check first that the issue hasn’t already been raised, and ideally try to reproduce it in the latest nightly build before reporting.

Here’s a reminder of the new features in 4.2:



  • Better synchronisation between the score and the parts
  • Ability to exclude certain elements from the score or the parts

Harp pedal diagrams

  • Support for glissando playback with correct enharmonics



  • 6-key Braille input via the Braille panel


  • Ability to choose specific sounds within a SoundFont


  • Support for Music Encoding Initiative (MEI) format
  • Various MusicXML fixes and improvements

Share to

  • Ability to update existing audio
  • Option to publish to and at the same time

Microtonal accidentals

  • Playback support for microtonal accidentals has now made it into MuseScore 4.2!
    • Finessing this feature is likely to be an ongoing process over the next couple of releases, but we’d appreciate your feedback and input!


  • Optimisations for note-input

Many thanks,

The MuseScore Team

Reminder for plugin authors: if your plugin uses the TextField component from QtQuick.Controls 1.0, please replace it with the TextEdit component from QtQuick.Controls 2.15 (or from QtQuick.Controls 2.2 if you require compatibility with MuseScore 3). See issue #19326 for details. Thanks!


Thanks for releasing the 4.2 beta. I've been trying it today, mainly because of some performance issues with 4.1.1, especially when opening the "Format/Style" dialog as reported by other users, and the 4.2 seems to work very well for that. Thanks for the great work!
I just noticed a small issue: When I add a staff spacer, it's invisible. Not sure if something is wrong on my side, but just want to report it in case it's a bug.
Best regards,

What exactly is new with microtonal accidentals? Is it just playback support for notes that have been tuned in the inspector, or is the ability now there to associate particular accidental symbols with particular tunings?

回复Ken Bloom

I downloaded the beta and gave it a try. The special accidentals all know their tunings, so simply applying one of them to a note means that the note will play back with the correct tuning. Also, somewhere along the line, Musescore gained the ability to play back custom key signatures. So in addition to putting accidentals on individual notes, I can now create key signatures for Maqam Hijaz, Maqam Rast, and Maqam Bayat and they'll play back correctly without the need for a plugin, and without the need for accidentals on the notes that aren't found in a Western diatonic scale.

回复Ken Bloom

Interesting, how and why could I miss that? It is even mentioned in the initial post...
There are still quite a few those that don't, because they don't have a known/fixed cent offset apparently, check accidental.cpp, lines 50-224, all that start with Acc(AccidentalVal::NATURAL,    0,, so the Arel-Ezgi-Uzdilek (AEU) accidentals and most of the Extended Helmholtz-Ellis accidentals (just intonation) ones.
I guess that, and the ability to change the offsets is meant by "Finessing this feature"

Hi, Musescore 4.1 has a problem with latency in midi input. The problem doesn't seem to have been fixed in 4.2
This is a dealbreaker for many people and I'd really love to see it fixed in 4.2
Looking forward!

I'll tell you. I'd be much more willing to beta test this version if the scores it saved could be opened in Musescore 4.1. Why do you have to bump the version number in the saved files with every minor release?

回复Ken Bloom

I also think this is the first time a change to the file format in a minor release has required a version number bump. There are times in the past when it probably should have, like for 3.6 with the new fonts and engraving features, where opening a score in an older version would potentially look very different, and where a fair amount of information could be lost if you opened in an older version then saved.

As far as I can tell the main reasons for bump in 4.2 are the new guitar bends and property linking system, which would also lead to loss of information if you try opening/saving a 4.2 score in an older version.

Anyhow, since a beta is by definition for testing, this shouldn't be a limiter. Make a copy of any scores you want to use in your testing., if you think you might also need to still open them in an older version for some reason.

But in any case, I get the sense the actual release of 4.2 is pretty imminent (days, not weeks), so it's probably mostly moot.

回复Ken Bloom

> Why do you have to bump the version number in the saved files with every minor release?

This is the first time we've done this, although the plan is to keep doing it from now on. The reason is that we're adding new features very rapidly, and some of those changes are quite fundamental, so it's difficult to maintain forwards compatibility.

Even if we did maintain forwards compatibility, scores that take advantage of the new features would look and sound very different in the older version. And if you save them with the old version then the new information would be lost, so they would look and sound wrong in the new version as well.


a) Bumping the major version wouldn't help with compatibility (you would still be unable to open scores in the older version). It might help with expectation, but we have to balance the expectation for compatibility with the expectation for new features. If you write scores for guitar and parts then you would consider 4.2 a "major" upgrade, but if you don't write scores for those things then you would see the changes in 4.2 as incremental, so it wouldn't make sense for us to bump the major version.

Strict semantic versioning only makes sense if your app/library does one thing. If it does lots of things then you're going to run into a problem when some of those things change a lot while others don't change very much. Qt dropped compatibility for Qt Webkit on a minor release, so it's not without precedent.

b) The default fonts and engraving settings changed between 3.5 and 3.6, so it was necessary to show a dialog to give users the chance to apply the new settings to their existing notation. The dialog said nothing about compatibility with older versions, which was maintained either way (to the extent that it was possible to do so). The engraving changes in 4.2 are less significant, and primarily affect new notation rather than existing notation.


I don't buy those arguments.

a) Just because others do something never is a good reason to do it too.
4.2 might not feel like a major update to many, but infact is, as far as the file format is concerned.
b) 3.6 showed a messages regardless 3.5 still being able to open those scores (and 3.5 did warn about the possibility of loosing things, IIRC). No reason for 4.2 vs. 4.1 not to do the same

Anyway, now that 4.2.0 is released, that bird has flown...

回复Ken Bloom

Workaround: MuseScore 4.1.0 Beta 1 can still read 4.2 scores.
Might be pretty difficult to find though.
Proves that the ability to read newer file versions had been deliberately and unnecessarily removed, sometime between 4.1.0 Beta 1 and the 4.1.0 final release.
Happened via, to 'fix' I did protest back then already and were not the only one...

回复Marc Sabatella

Oh, okay. I was kind of excited, because it would make woodwinds in pairs a lot easier. I'm sorry I said "promised". I noticed it but for some reason changed nothing. I still like the features that did get in. The score-parts synchronization settings will be really useful. Can you get rid of staff labels in the parts (for string solos, divisi, etc.) and keep them in the score? That would be extremely useful.
I know this is kind of straying from the main topic, but if the uniquely staffpad features (divisi, audio, and metronome staves, a built-in sound store, etc.) were added, staffpad would not be made useless, because it is still extremely useful to be able to just open up your tablet or iPad any time and put down your ideas without a computer (and quickly too), and the handwriting recognition software makes it unique.
There's just so much stuff that could be added. I think MuseScore is amazing, especially the fact that it is entirely free to get the notation software, download the incredible Muse Sounds library, and much more. I also really love it that some of the people in the Muse Group such as you are composers as well as copyists and developers. I don't want to make you guys feel like there is too much to do. It's nice that there is always room for improvement.

P.S. Is it safe to work in the beta, or is it best to stick to 4.1 until the final release?


It's never safe to use a beta version for mission-critical work.

If the scores are just for personal use, and you need some of the new features, then it might be worth the risk to use the beta. Ideally you should create as much as you can in 4.1, then just add the finishing touches in 4.2 beta, but keep a copy of the 4.1 version so you don't have to start again if it goes wrong.

Remember, MuseScore 4.1 can't open scores saved in MuseScore 4.2 (beta or non-beta).

Thanks for working on new version !

I sorely miss a specific feature in version 3 : The possibility to choose a specific output and a specific MIDI channel for each track. I intensely use external hardware synth and since version 4 I just can't :(

Do you plan on implementing this ?

您还有未解之惑吗? 请登录以发布问题。