MuseScore 2.0 Release Candidate

• Mar 12, 2015 - 20:37

Today, we are announcing the release of the MuseScore 2.0 "Release Candidate". A release candidate means that we have done everything we plan to do for the 2.0 release, but we are welcoming one final round of testing to be sure we have not forgotten anything. Assuming all goes well, there will be a final official release of MuseScore 2.0 on March 24 that will be identical to this release candidate except for updated translations (see below). At that point, you can expect another announcement with full details on everything you need to know about MuseScore 2.0.

So far, we have had two highly successful beta releases with tens of thousands of downloads and lots of great feedback. Hundreds of bugs have been fixed, including approximately 200 just since the last beta in December. For more information on the two beta releases and what new features were added, see and Our thanks to everyone who participated and helped us identify ways to improve MuseScore!

If you find issues in this release candidate, we encourage you to post about them to our support forum at If you are sure you have found a bug and that it has not been reported already, you may post directly to the issue tracker at That is also where you can check to see if an issue has already been reported.

Download MuseScore 2.0 RC


As of this release candidate, MuseScore 2.0 has been fully translated into 10 different languages (in addition to the default, US English), with another 7 more than 80% translated and another 6 more than 50% translated. In all, there are 54 translations underway. We can still use your help completing as many of these translations as possible. If you would like to participate in the translation effort, you can get started by visiting

Here is a list of the languages that have been or are being translated so far:

Status Language
100% Czech, Danish, French, German, Italian, Japanese, Polish, Russian, Spanish, Romanian
+90% Dutch, Galician
+80% Portuguese (Brazil), Norwegian Bokmål, Catalan (Valencian), Ukrainian
+50% Swedish, Greek, Chinese (China), Hungarian, Catalan, Finnish
Under 50% Portuguese, Vietnamese, Slovak, Hebrew, Serbian, Slovenian, Bulgarian, Persian, Lithuanian, Basque, Asturian, Croatian, Faroese, Arabic, Estonian, Thai, Turkish, Korean, Belarusian, Georgian, Indonesian, Afrikaans, Hindi, Mongolian, Uzbek, Latvian, Norwegian Nynorsk

What's New

In addition to the bug fixes and updated translations, this release candidate comes with one important new feature - upload to is now supported. So you can now share you scores online, just as was possible with MuseScore 1.3. In addition, when uploading a new version of a score you had uploaded previously, MuseScore will now ask if you want to update your existing online score or upload it as a new score. Support for MuseScore 2.0 scores in the mobile apps (Android, iOS) is still in the works.


Here are two unofficial builds for Windows:

- 64bit version:

- version compiled without SSE2 instructions and without the plugin environment (for compatibility with old hardwares not supporting SSE2):

Please note that these two version are personal build, and thus are not officially supported.
If you try out one of these versions and experience a bug, be sure to try to reproduce it in one of the official build before reporting.

In reply to by ABL

64-bit? - more than 4GB RAM for MuseScore 2.0? MuseScore 2.0 RC - MuseScore.exe (32-bit) - memory usage in Task Manager is 150MB RAM max.

More than 4GB now I'm using with:
- Cubase & VSTi
- Assassin's Creed: Unity - rarely
- The Witcher 3: Wild Hunt - in future, rarely...

Specification of PC:
MuseScore 2.0 RC
CPU: Phenom II X4 960T BE
RAM: 4GB DDR2 Kingston 800MHz CL6
OS: Windows 10 Pro 64-bit build 9926 PL

...but the progress is acceptable. When MuseScore will support VSTi - 64-bit will be great idea :D

Nice job, MuseScore Team :D


In reply to by [DELETED] 5

Well, actually there was also one report of a midi keyboard running with 64bit driver apparently recognized only in the 64bit experimental version. See:

And one can imagine of using at the same time a lot of different large soundfonts (the use of more soundfonts simultaneously is allowed in MuseScore 2.0) that sum up to more than 4GB.

But otherwise, I completely agree that a 64bit build is not necessary :-)
... But it was funny and rewading trying to overcome the task of compiling it and finally succeeding in it :-)

Am I seeing well? Windows and Mac OS? What? Do you realize that the biggest percentage of Musescore user's in an operating system comes from Linux? Most Wndows and, especially, Mac OS user's dont' care about Musescore. Most Linux users do care and support.

I can't believe I'm asking Musescore developpers not to forget Linux! Should Linux users move to Finale or Sibelius?

In reply to by canhoto

In my opinion, attempting to correlate an individual's OS with his or her interest in MuseScore (or music notation software in general) is not a sound or helpful idea.

Even if, for the sake of argument, you knew with certainty that 'the biggest percentage of Musescore user's in an operating system comes from Linux', no one could possibly know the following to be true: "Most Wndows and, especially, Mac OS user's dont' care about Musescore. Most Linux users do care and support."

In reply to by [DELETED] 448831

stevebob, the original comment was non-constructive and very hyperbolic, but you could have brought things back to being constructive instead of letting yourselve wade into the tangential arguments about users and OS's.

canhoto, there's a continuous support for GNU/Linux from Musescore, I'm sure lots of the community developers use GNU/Linux, and the original announcement about MuseScore 2.0 release schedule indicated that the GNU/Linux version might be just a couple weeks later than the Windows and Mac versions. So, stop worrying. There's no need to think we're being abandoned.

In reply to by [DELETED] 448831

Sorry for being blunt. I was basically trying to say this:

When someone on the internet writes exaggerated over-the-top junk the first thing to do is give them the benefit of the doubt and assume however much they are being emotional and irrational, they aren't always that way; so if you reply thoughtfully and constructively, they often turn out to be reasonable.

In this case, the poster was feeling let down and worried about the direction of Musescore (but this wasn't founded in reason or facts).

Anyway, to sympathize a little, understand that Windows and Microsoft as well as Apple and Mac in their own ways do all sorts of negative things in how they run their software and their businesses. GNU/Linux is the refuge for people who want technology to actually be in the hands of the public and serve the public interest. Being able to use Musescore without being forced to be subjected to the malicious aspects of Microsoft or Apple is an important thing to many of us. And there are many times that community projects end up disregarding community values and just follow the money… so the poster's concerns are understandable. Thankfully, we need not worry in this case.

Anyway, I invite you to consider trying a GNU/Linux system sometime, or at least taking a moment to understand what it's all about. See

You can sort of think of GNU/Linux as the farmers' market compared to Microsoft being Walmart, and you'll get a sense of the issues a little.

Got to disagree with you there. Macs are hugely popular for students, musicians and those in the music industry. I don't know of a single one of my music colleagues that use Linux. Programers and those that deal with technical side of things, absolutely. (Though most technical people I know outside of the internet use Windows)

In reply to by Joshua Pettus

Please don't get into this debate, it was just someone being unnecessarily worried about Musescore abandoning its core free/open values and ignoring the GNU/Linux community.

Anyway, just to clarify: the poster was trying to claim (confusingly so) that the percentage of GNU/Linux users who are Musescore users is higher than the percentage of Mac users who are Musescore users. They weren't making a claim about the OS used by the largest percentage of Musescore users overall. In other words, Musescore is valued by a larger percentage of the GNU/Linux community than the Mac community. It's still speculative nonetheless.

Anyway, irrelevant as Musescore is not abandoning GNU/Linux.

We are coordinating an effort together with the many package maintainers to have 2.0 available for as many Linux platforms as possible on the release date.

Thus far we have pledges from maintainers that on March 24, MuseScore 2.0 will be available for:
* Ubuntu
* OpenSUSE
* PCLinuxOS
* OpenBSD
* Linux Mint
* Debian
* Arch Linux

We are still trying to get pledges for
* Fedora
* Gentoo
* Mageia
* Slackware Linux
* CentOS
* Puppy Linux

If your Linux distribution is not in, please leave a comment.

If you don't want to wait until March 24, let this comment be a testimonial that building MuseScore yourself is doable.

In reply to by robthesaxplayer

I can't answer the second part, but something you may or may not be aware of regarding the first: you can run Ubuntu within Chrome OS. There are different ways of dong this, but the most popular is a set of scripts known as "crouton" that basically run Ubuntu in a chroot environment, sharing the kernel with Chrome OS, which is Linux-based.

Even in a world where we take technology for granted, I have to say, it works almost like magic. I am typing this on my Toshiba Chomebook 2 right now, with what should hopefully be the final build of MuseScore 2.0 running in another window, along with my Qt development environment, a full set of LaTex tools, etc. Yet I can press a button and switch to the Chrome OS desktop in an instant.

In reply to by robthesaxplayer

It should be compatible with the so called flavors of Ubuntu within a version. So it should run on Ubuntu 15.04 regardless of flavor (k/x/lubuntu). I am not sure it it will run easily on earlier versions of Ubuntu or not, it needs Qt 5.4 I think. If qt 5.4 is not in the repos you would have to install it manually or hope someone makes a ppa / backport.

In reply to by robthesaxplayer

>One other question. Would the Ubuntu version be compatible with sub-versions as well? (i.e. Lubuntu, Xubuntu, Kubuntu, etc.)

Yes they will, and also with Mint (17.1 compatible with *buntu 14.04). All different Ubuntu flavors share the same core system, the different thing is the desktop.

Due to the way I can take it around with me in an easy-to-use USB stick, every now and then I find Puppy Linux an invaluable solution. Nevertheless, I have to say that I don't feel comfortable with the many problems related to the installation and configuration of new software in that OS -- that's to say, I never ever succeeded in installing MuseScore in my Puppy Linux USB stick (my fault, of course). So, I would find it really useful and highly desirable the availability of an easy and ready-to-use solution for Puppy Linux. Meanwhile, I enjoy MuseScore on many Windows based PCs. My many pupils, at school, do as well.

I found some capitalization and punctuation errors in the Getting Started score, and also part of the instructions didn't actually work without adding extra lines of text explaining missing steps. I know you really don't want to have to change anything between now and the final release, which means I should have gotten in here earlier, but do you think there's a possibility of changing just this one thing now? I started a thread with a revised version of the score attached at

I have two problems with the release candidate:

Problem 1:

On OS X, when MuseScore 2.0 RC starts, it always displays this error:

Screenshot 2015-03-15 16.49.46.png

Problem 2:

On Windows, with a high resolution "UHD" screen, MuseScore is difficult to use because the controls are tiny. The sheet display itself is zoomable thus it's fine. The toolbar icon size is adjustable in the settings, and after increasing it and restarting MuseScore, it's fine. However, all text (menus, buttons, etc.) is quite small: not unusably small, but it's seriously straining the eye and it causes fatigue. The elements of the palette are so tiny that they're nearly unusable. This latter one is the serious problem.

Update: I have now attached two screenshots to illustrate the problem. Both of these are from a 15" screen, but smaller screens are available with this resolution too.

Attachment Size
Capture.PNG 564.13 KB
Capture2.PNG 624.47 KB

In reply to by Thomas


Thanks for the pointers. Unfortunately neither works.

1. mscore -F works fine, but on the next startup it displays the same error. Before posting here for the first time, I also tried removing Library/Application Support/MuseScore in an attempt to reset all settings, but the error is still there on startup.

2. MuseScore.exe -x 72 crashes on startup. Using -x 100 or -x 200 crashes too.

In reply to by Szabolcs Horvát

1) My guess is you have an older incomaptbiel build also installed, and you are accidentally running it some of the time, and its settings are conflicting with the RC settings.

2) The argument to -x is a *scaling factor*, not a raw resolution. So 1.0 is nominal, you probably want something like 2.0

In reply to by Marc Sabatella

1) No, I don't have any other versions installed and I'm fully aware which one I am running ...

"Jojo-Schmitz" is correct that this is actually set in the preferences. The default for Program Start is Start with: ":/data/My_First_Score.mscz", which looks like a bug. If I reset preferences, it always resets to this invalid value.

2) Yes, this works, though it doesn't affect every part of the program, e.g. the Start Centre is still tiny. But MuseScore is much more usable now. Thanks!

In reply to by Szabolcs Horvát

Factory reset should fix that and did for me, but you're the 2nd to report that it doesn't on a Mac...

Oh, I see, ":/data/My_First_Score.mscz", this is the correct setting, the bogus one in Beta 2 was ":/data/My_First_Score.mscx". The ":" referes to a built-in file, not to something you'd actually find in your file system..

In reply to by Szabolcs Horvát

Thanks for all the feedback thus far Szabolcs.

1. In order to help us to reproduce the First Score issue, could you state which Mac OS X version you are working on (and why not also the hardware)? Also, did you install MuseScore (drag & drop it into the Applications folder) or do you run it from (mounted) disk?

2. Could you make a screenshot of the MuseScore together with the Start Center so we can see the difference on your setup? You can attach it to a reply on this comment.

Thanks again for the support.

In reply to by Szabolcs Horvát

Well, all I can report is I did a full search through all source files, and the string My_First_Score.mscx does not appear anywhere. So it's hard to understand how MsueScore could be looking for this file unless somewhere on your system is an old setting - because that indeed 8was* the default score until a few months ago.

Not sure what you mean about ":/data/My_First_Score.mscz" being an invalid value. It is the correct value; that is the correct pathname for MsueScore to find the build-in score. but indeed, you can override it in Preferences. Running with "-F" sets it back to that value.

In reply to by Marc Sabatella

I tried several times again today, and now I cannot reproduce the problem any more ... can you let me know how I can remove MuseScore fully from the system, so I can try this again? I mean fully remove all MuseScore related files, not just use the -F option, for my peace of mind ...

Do I need to remove anything else than ~/Library/Application Support/MuseScore ?

I have a couple of questions about possible discrepancies in the release candidate.

1) The application is actually named MuseScore 2. Previous versions have been named MuseScore. How is the final release going to be named?
2) There is a folder named MuseScore2 (again, shouldn't it be just MuseScore?) placed in both the Documents folder and the Home folder. They seem to be exactly the same, except only one of them is actually used. Why are both created?

In reply to by chen lung

While we were still in unstable nightlies and betas you wouldn't want to get rid of the old version, so that would make sense, but after the final release I'm not sure why you would want to have both MuseScore 1 and MuseScore 2 installed. But, whatever. I can go with it.

What about the folders, though? First, why are there two of them; second, I really think the folder shouldn't have the number in its name. Or, if it really has to, it should at least be separated by a space.

In reply to by Isaac Weiss

There are enough differences in how 1.3 and 2.0 render a score that I think many people will want to keep 1.3 on hand in case they run into scores that have differences and it is not convenient to put the time into addressing them. So I think it pretty important it be possible to keep both versions around.

To me, it seems that in itself addresses why have separate folders - to kee the two installations separate. As for spaces, I don't see that as an important detail, but I would note that embedded spaces in folder names can be awkward when running from the command line on pretty much any OS (making wonder what Microsoft was thinking when they came up with "Program Files").

In reply to by Marc Sabatella

You misunderstand what I mean about the separate folders. I have a folder named MuseScore2 placed in my Documents folder, containing subfolders Images, Plugins, Scores, SFZ, Soundfonts (I say again, this needs to be capitalized properly!), Styles, and Templates. This folder is used by MuseScore. However, there is another folder also named MuseScore2 placed in the User or Home folder, containing all the same folders except SFZ, all of them empty and unused. Why was this created?

Additionally, it should be pointed out there is no folder for "MuseScore1", so there isn't anything it could be mixed up with.

As to the issue of the space—I'm almost terrified to bring this to your attention, for fear you'll change it (No!), but there's a space in the name of the app itself. However, at least on a Mac, this is rendered in the Terminal as "MuseScore\ 2".

In reply to by Isaac Weiss

What you are describing about multiple MuseScore2 folders sounds like either a Maconly issue, or perhaps something unique to your particular system configuration. Are you sure both were created by the RC and weren't created a previous Beta, or by running the RC with settings left over from a previous Beta?

Not sure what you mean by the "the name of the app itself" - there are a number of names that you could be referring to depending on context. But the actual file name as recorded in the filesystem is "MuseScore.exe" for Windows, and I believe just "mscore" for Linux and Mac. It's only the actual filename where spaces are a concern, not names that might appear as icon labels, window titles, etc.

In reply to by Marc Sabatella

Could be from a Beta, or I guess could be from a Nightly. I don't think, though, that I ever told any version of MuseScore to use a folder called "MuseScore2" in my Home folder.

And I'm referring to the application bundle: application.png

But it's an absolutely terrible idea to run the name together with the number. Don't!

In reply to by Isaac Weiss

Again, for a *filename* that someone may want to type at the command line, then spaces are the terrible idea, not lack off them. Mac "application bundles" are their own unique and streage world, so I don't know that it matters one way or the other. Looks like we use space where we should and don't where we shouldn't, then, unless you have new additional information?

EDIT: oh, and MuseScore2 in your home folder (or maybe in ~/Documents) is exactly the folder MuseScore should and does create by default on install or first run with factory settings. Any *other* folder you see would be one you created yourself.

In reply to by Marc Sabatella

An application bundle is basically a way of packing an entire application together. So things like the the templates and My_First_Score are in the bundle, as are the icons for the application and for MuseScore documents, as are all sorts of dynamic libraries, as is the actual mscore executable. I understand in some systems these would be dispersed in a dozen different locations. This way it's much easier to install, uninstall, or copy the program, because it's just one .app file.

But the bundle can be treated as a folder, containing all these things organized in subfolders inside. Thus, if you want you want to access any of these items—such as the executable—through a terminal, the application bundle becomes part of the file's path. See, for example, Note the "MuseScore\" in the path.

However, this is not the slightest bit of a problem, so nothing needs to be changed.

EDIT: Yes, I know ~/Documents/MuseScore2 is the right one. (If there was a space, it would be ~/Documents/MuseScore\ 2—this is POSIX, right?) I'm just puzzled by this other, unused ~/MuseScore2.

In reply to by [DELETED] 5

It's really all right. I deleted the unused ~/MuseScore2 and have had no problems. I still don't know where it came from—I'm going to try installing the RC on another computer and see what happens. I don't feel it's necessary to have the number in the folder's name, but it doesn't really matter one way or the other.

I had beta 2 working well on Mint 17.1 - Installed the RC deb package and now nothing happens when I attempt to start Musescore. I am running an older 32 bit computer. Is the RC deb for 64 bit? Could that be the problem?

What is the directory path that the .deb file installs into? I do not see a musescore folder in my home directory nor anywhere else on the system when I do a search.

In reply to by Jim Ivy

OK - This has something to do with the path to QT.

I installed QT and then installed the latest nightly build. Same problem - so I created the "lancemscore" script as described in the nightly build instructions and the nightly build ran fine.

Then I reinstalled the Release Candidate and pointed to last line to it's mscore. Voila!! The Release Candidate boots and runs just fine!

Here is the lancemscore script that worked for me:

export QT_PLUGIN_PATH=/home/jim/Qt/5.4/gcc/plugins/
export LD_LIBRARY_PATH=/home/jim/Qt/5.4/gcc/lib/
# Comment out the next line and repoint to the RC mscore location
#cd /home/jim/musenight/
cd /usr/bin/

So now I just have to figure out what to change so the the RC will find the correct QT directories without requiring the lancemscore script.

Well, my comment about the absence of a Linux version on the first days of the release generated a lot of discussion. Wolftune got my point and tried to explain it. I thank him for that.
I really was afraid that Musescore developers would be following the money path, buy trying to get to the big market of Apple and Microsoft. It would be against the nature of Musescore, of course. But it would also be very unfair. It is easy to see that, while in the Linux world most of the users will probably use Musescore as a notation editor - because it's in the repositories but also because it's FOSS and that's related to the reason why they choose Linux at first - most of the Windows and Mac users will stick to their Sibelius and Finale. Believe me, being a professional musician and knowing hundreds of people in my area, the vast majority of them don't give a damm about free software in general, and Musescore in particular.
That's why I truly respect the Mac OS and Windows users who choose Musescore (and Ardour, and Libreoffice...). I have some friends, non-Linux users, who use Musescore. It's a minority, but they exist. And I do everything I to reach Windows and Mac users with this wonderful software, and to convince them there's not one thing that makes Finale and Sibelius good choices when there is Musescore.
And, of course, lots of users in this forum are Windows and Mac OS users. Great!
I myself was a Mac user before (for about 10 years). Then I discovered great free software like Musescore and a few others. And then I discovered that I could go a step further and have the whole system free and open source. I entered the Linux world and I don't regret it. Actually, I've become quite intolerant to Apple and their politics.

Anyway, this is not an OS war: I was just concerned about the path Musescore developers could be following. Fortunately, I was wrong.

In reply to by canhoto

I am excited to be using Musescore 2.0 RC in Ubuntu (Linux Mint) and in Debian Wheezy (crunchbang) via WINE. This has meant I'm no longer worried by how soon it will be available in repositories etc.
WINE seems to run it pretty well without any tweaking and I've reuploaded some of my sheets that have I've updated to Musescore 2.0 format to my sheet music account.

In reply to by canhoto

Yeah, I still don't get what you're trying to say. You said something about the builds for Mac and WIndows representing "MuseScore developers following the money path [by] trying to get to the big market of Apple and Microsoft." Unless MuseScore starts actually selling itself (heaven forfend!), trying to get users on different platforms doesn't mean anything about money at all.

But I still wish to violently counter the outrageous stereotypes you're spouting. Starting with "Most Wndows and, especially, Mac OS user's dont' care about Musescore. Most Linux users do care and support."

Okay, first of all, "especially, Mac OS"? Just curious—why do you hate Mac users even more than Windows users? But let that pass.

I think that you are factually wrong. I think that

a) most MuseScore users are on Windows, while Linux and Mac both represent much smaller shares;

b) Mac and Windows MuseScore users are just as likely to donate money, beta testing and bug reports, and documentation as Linux MuseScore users (though it's likely that Linux users are more likely to contribute code);

c) while I'm sure there's some difference, it's absurd to say that most non-Linux people "don't give a damm about free software in general." Firefox? I'll say no more.

The first two points, it may be possible to check. Does the team keep records of number of downloads for each OS, or things like that?

Also, it may surprise you, but there are free software projects that are Mac-specific, and probably ones that are Windows-only, too.
Okay, aggression released, let's be friendly. :)

I'm a Mac user not because I have some vague liking for commercialism, but simply because Macs are what I know and love. Windows, Linux—nothing against them, I just don't get them. I like what I'm used to. Same reason I think Darkseid is better than Thanos (selective pop culture reference there—look it up on Wikipedia if you don't know what I'm talking about). However, as a user of LibreOffice exclusively (if I'm using a computer that only has Microsoft Word, I download LibreOffice), MuseScore (obviously), Firefox, VLC, Audacity, Gimp, and more obscure things, I've considered going into the Linux world, and I actually installed Zorin OS in a VirtualBox virtual machine. (I figured, I might as well try to get used to the Linux distribution that's most similar to Windows.) But I found it no fun to use.

Question: when you switched from Mac to Linux, which distribution did you choose? Is there anything that feels at all familiar?

Also—I bet you use Google. :/

In reply to by canhoto

Let's not let this degenerate into a debate on open source activism and operating systems.

Fact 1: Most people don't use Linux.
Fact 2: MuseScore is the best gratis sheet editor (whether FOSS or not).

Those of us who don't make money with music but want a high quality sheet editor are grateful for MuseScore to exist. We are happy that MuseScore seriously supports all common operating systems, including popular easy to use ones like Windows. There are (fortunately few) open source software which won't support Windows primarily for political reasons, and I'm glad that MuseScore is not like that. Political discussions and FOSS activism really have no place here. MuseScore supports all three major OS, so there's nothing to complain about.

In reply to by Szabolcs Horvát

Thank you. Except it seems you couldn't resist… who says Windows is "easy to use"? Not me, that's all I can say. ;-) But let it pass. Your facts are true, and I might even add that most people don't use Macs. But indeed, decidedly, political discussions have no place here, and I apologize for throwing fuel on the fire. Thank you for saving us from ourselves.

This version now reads my templates from a directory specified by me but puts them at the bottom of the template list which is rather inconvenient. Can we please have user templates at the top as they are the most likely to be used.

Here is the screenshot, as promised. This is a 15" screen. MuseScore was started with the -x 2 option for double size. It looks very usable like this, and it's only few things such as the Start Center and splashscreen (irrelevant for me) that are still small.

Attachment Size
Capture.JPG 407.29 KB


I think it would be good if tags (via a icon or something) 2.0 (2.0RC or betas) uploaded scores. I found one score that doesn't play in 1.3/2.0b2 and it would be nice to be advised on the exact file version.


I'm kinda sad that i can't save a copy of the music as a midi file. I loved watching it on synthesia. Will that be on the version that is going to be released on March 24?

Should I be able to load files created in Musescore 1.2 and expect them to look the same in Musescore 2.0? So far I have tried this with eight files and all but one of them has had problems:

In five of the files, the number of bars per system has changed at various points in the score.

In one of the files, there are strange artifacts in the beaming. In a couple of places, the beam for the notes in one system is displaced up by exactly one system. This means that the notes that should have the beam appear as crotchets and the beam appears on its own in a different part of the score.

In another file, the lyrics have moved up so that instead of being between the staves, they are on top of one of them.

In another score, the crotchet rests have been displaced upwards to the top line of the staff.

The file version I am using is:

I would like to use Musescore 2 because the exported svg files are easier to work with. Am I doing something wrong? Do I need to do something to these files before opening them in Musescore 2? It seems like a lot of rework to do to upgrade to a new version and there are some of the problems such as the beaming and the lyrics mentioned above that I don't really know yet how to deal with.

In reply to by bodhi.zazen

Thanks for the suggestion. However, I only have 2.0 installed. I had to install a new operating system (debian jessie) because the old one (debian wheezy) didn't support 2.0. So, 1.2 (or 1.3) has never been in this installation. The files are stored on my NAS and I can access them from either operating system. The files are still all as saved from 1.2 because I haven't saved them again from 2.0.

Could what you did have changed anything else that I could try?

In reply to by hughtmccullough

See my earlier reply There's probably not anything wrong with your installation. A few minor layout differences here and there are to be expected; the beam issue is a knowh bug in both 1.3 and 2.0 (looks far worse in 1.3 actually, but a problem for sure in both). Anything you are seeing besides an occasional case where a different number of measures fits on a system could be a bug or just something you were relying on in 1.3 that is "fragile" and should have been done differently. We'd need you to post the score you are having trouble with in order to say.

In reply to by hughtmccullough

In general, most scores should look quite similar. But the layout algorithms have been very significantly improved, which does mean there will be differences that do occasionally mean a different number of measures per fit per system by default than under the old algorithm ssystem. So if you need to emulate the specific system layout of 1.3 for some reason, then simply decrease/increase stretch and/or add line breaks as necessary.

Displacement of rests in a multivoice context is indeed on of the many improvements in 2.0 - 1.3 centered rests inappropriately in multivoice music, leading to all sorts of collisions that had to be resolved manually. This is no longer necessary in 2.0, but in the very specific musical situations where it actually acceptable to center a rest for one voice even though it is a multivoice context, you will instead have to manually adjust *those* case.

Regarding beaming, you'd have to post the specific score you are having problems with to say for sure, but my guess is you are trying to beam across barlines, which works in both 1.3 and 2.0 but *only* if there is not also a system break. That didn't work in 1.3 and continues to not work in 2.0, but it fails differently between the two versions. So those cases you'd just to fix to not use cross-barline beaming, and then it will look correct in both 1.3 and 2.0.

Regarding lyrics,m there is no way to guess what might be happening without seeing the score. Most likely, it was some sort of manual adjustment you had made that should instead have been made with a style setting and is now being defeated by the change in the layout, but without seeing the score, that's just a guess.

In reply to by Marc Sabatella

OK. So, I'll have to go through everything and re-align the system breaks to where they were again. However, you do stretch the meaning of the word "occasional". Five out of eight short pieces of music is more than occasional.

I have attached two pieces of music. One has the beaming problem and there are no beams that cross barlines. The other has the lyrics problem. Some advice on how to sort these out would be welcome.

Attachment Size
74 Desert CM.mscz 3.71 KB
jubilate_everybody.mscz 2.8 KB

In reply to by [DELETED] 5

Thanks. That allows me to sort out the problem but what do you mean that the beam crosses the line break? All of the notes that are beamed are within the first bar of the second system and always have been. I would like to understand what has gone wrong so that I avoid problems in future.

In reply to by hughtmccullough

For future reference, if you want to guarantee line breaks don't move, simply add explicit line breaks rather than rely on whereever one prticular version of a program happens to place them. You shouldnt "have to" go through everything an re-align breaks - the new breaks should ordinarily be *better* choices than the original, more in keeping with standard rules of engraving, whereas 1.3 would very often get things wrong and inappropriate create collisions and other artifacts that should have been and are now avoided.

As for how occasional, I would guess that of those 5 pieces, not *every* system has a different number of measures than before. So saying 5 out of 8 pieces are different is not a very good measure. More to the point would be to count what percetnage of *systems* were different. But in the end, it shouldn't matter what that percentage is - again, the new layout is *better* than the old. You wouldn't want MuseScore not to improve, would you? In a way, the more differences, the more sign that MuseScore actually *has* improved. Again, if you want to override the defaults and enforce your own line breaks, that's what the explicit line break are for, but you shouldn't just go in blindly trying to reproduce the choices made in 1.3.

Anyhow, on to specifics:

The score with the beaming issue has beams across system breaks that are being suppressed due to a bug in 1.3 that is now fixed. But to see just how bad those beams would have looked in 1.3, try clicking the last note of the first system, top staff, voice 1, and double clicking the "middle of beam" icon to force 1.3 to display the beam across the system. You'll see the beams and stems go absolutely haywire. MuseScore 1.3 was failing to beam that group across the barline even though you asked for it with the beam property for the first note of the second system so you weren't seeing just how badly broken this was in 1.3. But now that 2.0 correctly honors the beam property on that first note of the new system, you do see the bug that was always there with cross-system beams, although as you can now see, it's actually nowhere near as bad as it was in 1.3. But still bad enough that you need to not try to beam across systems, so reset that first note to Auto.

The lyric issue I don't understand. What specifically are you not liking about 2.0? Looks pretty much the same except that 2.0 has managed to fit an extra measure onto a system here and there, making a better and more compact layout overall. Again, if you prefer to have fewewr measure per line, you can simply add line breaks, but I wouldn't do that just because it's how 1.3 happened to do it. Personally, I'd do a select all, reduce stretch a nothc, then Edit / Tools / Add/Remove Line Brekas and add breaks every 4 bars. To m,e, that would be the ideal layout, noticeably better than the default in either verison, but closer to what 2. does than what 1.3 does.

In reply to by Marc Sabatella

I've been through the process Marc describes with plenty of my scores recently and have been impressed by how much improved everything is. It takes a little effort but it's so pleasing to remove a bunch of nasty tweaks that 1.3 enforced and watch the default behaviour do what you want. Much impressed and thank you.

In reply to by Marc Sabatella

First of all, thank you very much for going through all of this. I appreciate you taking the time to do that.

I wasn't actually trying to reproduce the choices made by 1.3 as such (actually 1.2). Because of printing restrictions, I have to fix the number of systems that are used for each tune. In 1.2 I had carefully gone through and done this manually. In some cases, the default layout produced by 1.2 was fine and in others I had to tweak it. Presumably what is now happening is that the combined effect of the automatic layout and my changes to it is being ignored. I realise that you have made improvements and I may just have to accept that what is happening is the price of progress. It does mean that I will have to go through and redo all of them.

I understand what you are saying about the beaming but I don't know how it happened. I never wished to or tried to have beams going across bar lines at a system break or anywhere else. I can only imagine that I made a mistake somewhere and that I didn't have to fix it because it was hidden from me.

I apologise about the lyrics. I uploaded the wrong file. I have now attached the correct one. I have probably done something wrong here too that didn't manifest itself in 1.2 but I don't know how to fix it.

Attachment Size
Du lever du soleil.mscz 3.33 KB

In reply to by hughtmccullough

Regarding systems breaks - the files you uploaded didn't have any manual ones. I have found the best way to ensure breaks stay the same is always add manual breaks to every line once I am satisfied with the layout. This is easier in 2.0 because there is an option do do it autoamtically using Edit / Tools / Add/Remove Line Breaks. Then, I select all and reduce stretch a notch or two. It will have no visible effect, but it does give some protection against another version happening to take slightly more space in some measure and thus pushing the last measure of the system onto another system all by itself. And then, even if this does happen, getting back to the original layout is as simple as selecting all and reducing stretch another notch or two. Manual line breaks are definitiely your friend if you want a specific layout that might be different from the officially optimal one.

Regarding lyrics - the vertical offset in the text style has been set to 0sp for some reason. A bug in 1.3 apparently prevented this from being honored, but now that bug is fixed, and the file is displaying the lyrics correctly according to your defined text style. Simply change the text style back to normal - 6sp is the default - and all should be well.


hello my name is kanakomoerer. if you can prepare, would you upload 64-bit version& without SSE2 of MuseScore 2.0 final release ? thx.

In reply to by kanakomoerer

@kanakomoerer and all those interested,
here are the links of MuseScore 2.0 for:

the Windows version (32bit) without SSE2 (and without plugin framework, which requires SSE2):

the Windows 64bit version:

I didn't include the launcher in this folder (zipped with 7zip); the executable is inside the "bin" folder.
(I wanted to build an .msi installer, but I did not succeed)

As before, the usual caveat about these not being official versions and about reporting only bugs reproduced with the official build still hold.

Enjoy it :-)


In reply to by kanakomoerer

Sorry for the delay, but I was very busy in the last few days, and I also had to find a 64bit Windows version of freetype which is a needed dependency for MuseScore 2.0.2 (I used the one from ).
Here are the unofficial versions of MuseScore 2.0.2:

- Windows 64 bit version:
(Using Qt 5.4.2 from… )
MD5 : f960a92e021810f14006e7deb645b294
SHA-1 : bbc2082eb20580cf75a1740461df48ac21a37459

- Windows 32 bit without SSE2 instructions (and plugins disabled):
(I used Qt 5.4.1 because I didn't have time to compile Qt 5.4.2; it takes almost 8h)
MD5 : dcc2d253085291f39a956ed3a927d3d4
SHA-1 : 39ccbf8e0995949710e3c250607eb4ac5b9caec4


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