MuseScore 4.2 Beta now available
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: https://github.com/musescore/MuseScore/releases/tag/v4.2.0-beta
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:
Guitar
- Support for alternate string tunings
- All-new system for inputting bends and customising their playback
- Bend playback currently requires SoundFont or VST.
Parts
- 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
Engraving
- Support for arpeggios spanning voices
- Options to place ties ‘inside’ or ‘outside’ of notes and chords
- Various other fixes (see list)
Accessibility
- 6-key Braille input via the Braille panel
Mixer
- Ability to choose specific sounds within a SoundFont
Import/export
- Support for Music Encoding Initiative (MEI) format
- Various MusicXML fixes and improvements
Share to Audio.com
- Ability to update existing audio
- Option to publish to MuseScore.com and Audio.com 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!
Performance
- 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!
Comments
Is QtQuick.Controls 2.2 save too? 2.15 is not available for Mu3, so that'd otherwise break the dual compatibility plugins
Edit: I'll ask in the issue...
In reply to Is QtQuick.Controls 2.2 save… by Jojo-Schmitz
As per @cbjeukendrup any 2.x version should suffice
There's no PortableApp, still/once again!
See https://github.com/musescore/MuseScore/issues/15876
And no ARM version (which we build as of latest).
There are nightly builds for both though
In reply to There's no PortableApp, once… by Jojo-Schmitz
You can find these here under MuseScore 4 > Beta.
Please note that the ARM and
paf.exebuilds have not been tested at all, hence they are a bit hidden compared to the other 4.2 beta builds, which have all been tested.In reply to You can find these here,… by shoogle
These would get better test coverage if not being a bit hidden ;-)
In reply to These would get better test… by Jojo-Schmitz
I've added them to the main release page now as we have confirmation that they all work, or at least run inside virtual machines.
In reply to You can find these here,… by shoogle
Fix the saving file that ALWAYS make your file corrupted. I hate it. Last time I had a presentation--the day before my presentation, my FILE has been corrupted for just saving a minor changes. FIX THIS ASAP.
Hi,
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,
Jo
In reply to Hi, Thanks for releasing the… by sjkwadzo
Thanks Jo, what you found with staff spacers is definitely a bug (and a known one too: https://github.com/musescore/MuseScore/issues/19963). We'll be working on it as a fairly high priority (because spacers are almost unusable otherwise).
Thank you!
In reply to Thanks Jo, what you found… by bradleykunda
Thanks!
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?
In reply to What exactly is new with… by 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.
In reply to I downloaded the beta and… by 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!
In reply to Hi, Musescore 4.1 has a… by jonathankraka
Hi,amm can someone explain me, how to remove this absolutely awful thing? That new thing so stupid and disgusting, if it’s new update i hope that they will fix it.
In reply to Hi,amm can someone explain… by lapinmisa12
That apparently is musescore.com, not musescore.org or the MuseScore editor for Windows, Mac and Linux.
Go there.
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?
In reply to I'll tell you. I'd be much… by Ken Bloom
As far as it remember this is the very first time a minor release does this (unless you count 0.95).
Doesn't really make it better though...
In reply to I'll tell you. I'd be much… by 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.
In reply to I'll tell you. I'd be much… by 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.
In reply to > Why do you have to bump… by shoogle
a) Why not bumping the major version number then?
b) At least an import dialog should be shown IMHO rather than just asking the user to save on close, even if nothing got changed, 3.6 did that, regardless of not having bumped the file version.
In reply to a) Why not bumping the major… by Jojo-Schmitz
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.
In reply to a) If you write scores for… by shoogle
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...
In reply to I don't buy those arguments… by Jojo-Schmitz
We're not doing it because Qt did it. We're doing it for the reasons I stated earlier. The example of Qt was simply to illustrate that others have made the same decision.
In reply to We're not doing it because… by shoogle
Which I don't buy
In reply to I'll tell you. I'd be much… by 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 https://github.com/musescore/MuseScore/pull/18414, to 'fix' https://github.com/musescore/MuseScore/pull/18358. I did protest back then already and were not the only one...
I'm not hearing the promised voice-specific dynamic playback...
In reply to I'm not hearing the promised… by Asher S.
Well, nothing is ever “promised” when it comes to potential new features. It’s true it was at one point being projected for a possible 4.2 release, but complications have pushed it out to 4.3. (Assuming Jo further complications get in the way, of course).
In reply to Well, nothing is ever … by 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?
In reply to Oh, okay. I was kind of… by Asher S.
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).
When is that count-in feature coming back?
Hey!
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 ?