MuseScore 2.0 Beta 1 Released!

• Aug 26, 2014 - 20:34

The MuseScore team is excited to announce the first Beta release of MuseScore 2.0! This is your opportunity to try out the new features, see if your "favorite" bugs have been fixed, and provide feedback that we can use to make sure the final MuseScore 2.0 release is as stable as the well-established 1.X series of releases have proven to be. This first Beta release is our way of saying we think we're done adding features for 2.0 and everything basically seems to work – so we invite you to help us test it further. You can keep your existing MuseScore 1.3 (or earlier) installation with no fear of them interfering with each other.

Download MuseScore 2.0 Beta 1

If you do find bugs in MuseScore 2.0 Beta 1, please report them via the issue tracker. You can also discuss your experiences with MuseScore 2.0 Beta 1 on the Technology Preview forum. Read on to learn what's new.

What's New

MuseScore 2.0 will represent the culmination of the past four years of development effort, beginning even before the release of MuseScore 1.0 in 2011. We knew that implementing all of the new features that we were planning for the next major release was such a big undertaking that it would take a long time to get right, so we kept this work separate from that of the 1.0, 1.1. 1.2, and 1.3 releases. While the 1.X releases introduced just incremental changes over the past four years, we think you will be "wowed" by all that is new with MuseScore 2.0.

Here are some of the major changes you will find in MuseScore 2.0 Beta 1:

  • Linked parts - changes in score automatically reflect in parts and vice versa
  • Continuous view - scroll horizontally through your score with no line or page breaks
  • Tablature - variety of tab notation styles for guitar, bass, lute, and more
  • Fret diagrams - easily create diagrams and set up your own palette of commonly used chords
  • Flexible chord symbols - enter chord symbols using any common spellings, including support for German and solfege note naming and lower case minor chords
  • Dynamic text styles - changes automatically apply to all elements with that style
  • More supported notations - support for Steinberg's new open source Bravura music font, more flexible time signatures, pedal change markings, grace notes after (trill endings), falls/doits/scoops/plops/bends, bagpipe embellishments, figured bass, ambitus, early music notations, and a huge set of additional music symbols from Bravura
  • Layout improvements - automatic correct positioning and spacing for multi-voice chords and rests, dots, accidentals, ties, articulations, hairpins, pedal markings, voltas, etc.
  • Score management facilities - create scores of multiple movements, combine scores into albums, define and apply custom score styles, select default styles for scores and for parts
  • Playback improvements - new and more realistic soundfont, mid-score instrument changes, playback of more score markings, flexible swing style, improved JACK support for interoperability with other MIDI and audio programs
  • MIDI import improvements - automatic simplification of rhythms, handling of multiple voices
  • MusicXML import/export improvements - greater compatibility with other applications, ability to control degree of layout preserved
  • Guitar Pro import - supports GP3, GP4, GP5, and GPX formats
  • Usability improvements - repitch mode, on-screen piano keyboard for note entry, element inspector window, more precise manual adjustments, easier selection of instruments, simpler and more powerful page layout, copy/paste improvements, split and join measures, screenshot mode for creating graphical excerpts, customizable palettes and workspaces, expanded availability of keyboard shortcuts
  • And lots more!

Compatibility

With such a long list of new features, you may be wondering if you will still be able to find your way around. You may also be wondering about compatibility.

The good news is, most things in MuseScore 2.0 actually look and work about the same as always - just better. The new features never get in your way but are there to make life easier, and many happen completely automatically. For example, the layout and playback improvements will take effect even when opening a score created with previous versions of MuseScore. You can take advantage of linked parts, flexible chord symbols, dynamic text styles without your needing to do anything differently than you are accustomed to. And completely new features like continuous view, tablature, and fret diagrams are designed to be as intuitive as possible.

As suggested above, scores created in 1.3 or earlier releases should load into MuseScore 2.0 Beta 1 with no problems. In most cases they will look the same or better due to the layout improvements. Due to the magnitude of the changes under the hood, in a few cases you might need to revisit some manual adjustments you had made previously. Scores created in MuseScore 2.0 Beta 1 should open with no problems whatsoever in the final release, although to be safe you may wish to also export any scores you care about as MusicXML before installing the final release.

The one compatibility issue to keep in mind is this: scores created in MuseScore 2.0 (Beta or final release) will not open in earlier versions. This is unavoidable when making such major changes. However, you can still export MuseScore 2.0 files as MusicXML and import into 1.3 that way, thus preserving most of your work should you see the need to revert.

What's Next

There is no ETA set for the final MuseScore 2.0 release. If you would like to get notified when it will be available for download, subscribe on the MuseScore newsletter, or follow MuseScore on Facebook, Twitter, Google+ or LinkedIn.

The MuseScore team's commitment to open source software development remains as strong as ever. The MuseScore music notation software remains completely free - free as in free beer, free as in free speech. And with the MuseScore 2.0 release, MuseScore is easily the most powerful free and open source music notation program that has ever existed, doing almost everything the expensive proprietary commercial programs do. Over 300 developers, translators, designers, and testers – users just like you – worked to make this possible, and we continue to welcome new contributors.

Your support

You can financially support the open source development of MuseScore via our donation campaign. Having said this, the best support you can give to MuseScore is by recommending it to your friends and by spreading the word. Thank you for your support!


Comments

Is there a plan to support the 2.0 beta on musescore.com in some fashion?
For example, will it be possible to upload 2.0 scores to musescore.com before the final 2.0 release?

regards,
markt

In reply to by mtherieau

@mtherieau Scores created with MuseScore 2.0 Beta 1 are for the time being not supported on musescore.com, nor in the MuseScore mobile apps. However if no critical bugs show up linked with the new 2.0 file format, scores made with beta 1 will eventually be accepted. This decision was made to maintain the focus on MuseScore 2.0 development, and avoid having to fight on too many fronts at the same time. Hope you understand.

In reply to by Thomas

I also totally understand this decision, but as far as I can tell the new file format is the only one that really properly supports guitar tablature. I just tried exporting a file created with a pre-2.0 nightly build, with extensive tablature content, into MS 1.3 using MusicXML as an intermediate step; it was, unfortunately, an abject and unfixable rendering failure.

I'd really love to be able to share "playable" tab with my notation-illiterate bandmates and guitar students in the MuseScore mobile app (and before you ask why I don't "just" teach them to buckle down and read... believe me, I've tried).

There really are a lot of very exciting new features in the still-developing file format, and it would be a shame to create a bunch of scores relying on these features only to be told you can't share / send them up to mobile. I definitely hope the team won't wait forever to add 2.0ish support to the online engine (or forget about it in all the excitement of bringing the new version to the streets)!

Really impressed with what the team has been doing lately and 2.0b1 looks truly great so far. Cheers.

In reply to by robthesaxplayer

I tried compiling the beta (Mint 16) and failed this time - no problem.
But the wine version is a revelation. It just works. Sound and all.
Looking forward to the linux native version, but for now, this is just great.
Thanks again.

In reply to by [DELETED] 448831

Hi! I have downloaded the beta, and no luck with the installation.
It says "The cabinet file "media1.cab" required for this installation is corrupt and cannot be used. This could indicate a network error, an error reading from the CD-Rom, or a problem with this package."
I downloaded the nightlys sucesfully, and i used a download manager, so appear is not related to a corrupt download.

In reply to by marcielo

Are you sure you got the right file? I'm not aware of any file by that name connected with MsueScore in any way, although I could be wrong. But the file you want is called MuseScore-2.0beta1.msi. When you run it, it should be a standard Windows installer package. I have no idea what a "download manager" is, but I know you don't need one. Just click "Windows" in the original post here, and when the dialog pops up asking what you want to do ith the MuseScore-2.0beta1.msi file, either save it then double click it, or run it directly if your browser offers you that option.

In reply to by marcielo

Which download manager do you use, I myself use DownThemAll, and it does have issues with some types of compressed (zipped) files, giving me similar error messages when trying to unzip or install zipped files.

You would be safer downloading it without the use of the manager as Marc has pointed out.

In reply to by [DELETED] 448831

Regarding layers/tags, my understanding is it was partially implemented very early on (several years ago) and then just never made a priority while other more important user-requested features and bug fixes were were worked on. As a result, the layer/tag facility fell behind and would need a lot of updating to be functional again - and it was never very functional to begin with (limited to fingerings only).

None of which is to say it couldn't possibly find its way back if some sufficiently motivated developer were to volunteer their time to get it working again, do all the testing that would be required, etc.

Hi, I cant seem to find the option to make texts or certain elements invisible like in the 1.3ver
I also can't seem to change the size of lyrics font from stuff I've made using 1.3ver even if I edit text styles already....thanks!

Is there any way to change the key signature for only one staff? I'm trying to write something with transposing instruments and I need them to have no key signature even when not in concert pitch.

Curious, will patches or updates of fixed bugs for 2.0 Beta 1 be made after this release, or will those only continue to reflect in the Nightly builds?

Mosescore 2.0 beta 1 works well on my computer! My only concern is soundfonts. I've been using the generalusergs soundfont and it sounded wonderful. Though I do like the new fluid.sf3 I prefer my old sf2, and musescore doesn't sseems to want to load any sf2 files in the synthesizer. I checked but couldn't find any sf3 files anywhere that sounded like general user soundfont, which was an sf2. Any help?

In reply to by speedmeteor101

There should be no problem at all loading the old style sf2 format soundfonts.

I was using the build prior to the Beta release for testing a fixed problem in Fluid R6 using the SF2 version.

You may have to add the folder where your SF2 soundfonts are stored to MuseScore 2 in the preferences page, however.

In reply to by James_Wareham

Is there some sort of incomplete compatibility because several of my files done with 1.3 when opened in 2.0b have misplaced marks and some even have wrong notes. :(

Overall i do like 2.0 more but i hope there would be 100% backward compatibility with 1.3 files.

In reply to by Thomas

so for canon in c, it would open this file created in 1.3 correctly but when you save it in 2.0, the new save file has note errors specifically in measure 3. I haven't had a chance to check the rest of the piece yet but saving resulting in note error from the original is no good.

for everything i do, open this same 1 file in both ver to see the chord notation being messed up in 2.0. I haven't a chance to check if by saving this under 2.0 would there be a note error yet. But even note error in just one line in one piecce just by saving needs to be fixed asap...

Also 2.0 randomly insert a treble and bass clef symbol at the end of several of the staff lines.

In reply to by wildpig

The note errors in measure 3 of Canon do appear to be a bug, but you have to realize, that original file is *very* strange. The notes that appear to be in the top staff are actually in the bottom staff and vice versa - they've been moved between staves. You can see this even in 1.3. Load the file into 1.3, select the bass clef staff of measure 3 and hit delete - the *treble clef* note disappear. Now do the same for the treble clef staff and you'll see the *bass* clef notes disappear. MuseScore does support cross-staff notation, but it shouldn't have been needed here. Not that the bug shouldn't be fixed, but this won't happen nearly as often as you might have been led to believe. FWIW, what's happening is the cross-staff information is not being saved, so you re-load the score, you are seeing the notes back on their original staves. I wil;l fil;e the bug report for this.

Regarding Everything I Do, I would need to see the original 1.3 version to know what the problem is - this version appears to have already been saved in 2.0. I can see that the chords symbols are at various different positions, but it appears from the file you uploaded that this is where someone had manually moved them and that it would have looked the same in 1.3.

Regarding the clefs, we would need to see the file with that problem - again, the original 1.3 file - and instructions on how to reproduce the problem. I do see clefs at the end of the very first system of Everything I Do, but these apopear to be perfectly normal and correct courtesy clefs, needed because the next system starts with different clefs (middle staff changes from bass to treble, bottom from treble to bass). Again, I'd have to see the original to understand why you might think that was a problem.

In reply to by Marc Sabatella

So for canon maybe I should go in and manually fix the measure 3 so we don't unnecessarily have cross staff notation i guess? I think when I made this score it was by ocr of a music sheet or possibily from a midi file so probably why the weird cross staff but good to have the cross staff info saved now.

Ok here's are the 1.3 files again. The insertion of the treble and bass clef symbol at the end of staff line happens in both of these pieces when open in 2.0:

for canon, see the end of measure 11. There is not supposed to be any staff switching in this piece at all. For everything i do, it also insert the clef symbol unnecessarily at the end of a few of the staff lines even though there's no need since if you open up everything i do in 1.3 you ll see that there is no staff switching in the piece.

also 2.0 doesnt playback everything i do with the correct tempo (too fast). 1.3 playbacks with right tempo

With the new file format, i guess if i create anything in 2.0 would need to save as xml if i want to open in 1.3?

In reply to by wildpig

Yes, I'd fix the cross staff notation and the it should be fine. BTW, the fix is already in the currently nightly builds :-)

Were both of these created by scanning software, then? That could be where the extra clefs came from. Because when I look at your actual file with a text editor, I can see those "extra" clefs are already there. There is a clef change called for at measure 12, 23, 31, and 43. Not sure why they weren't showing up in 1.3 - could be a bug in 1.3 that is now fixed. If this came from a MusicXML file, you could share that?

What do you mean about not playing with the right tempo? Again, please uplaod a specific file and give specific instructions on how to reproduce the problem. In general, 2.0 plays back everything the same tempo as 1.3 if the score was created normally / correctly in the first place. But it's possible there are some invisible tempo markings that were present in the original MIDI or MusicXML fil you imported and these might be handled differently. Again, we'd need to see a specific example - preferably including the original MIDI or MusicXML file - in order to know for sure.

And yes, if you create anything in the MuseScore 2.0 Beta 1 that you want to load into 1.3, you will need to export as MusicXML, and be aware that because 1.3 is somewhat less sophisticated in its MusicXML import capability, you might end up with more curious artifacts like this.

In reply to by wildpig

I'm sure you're getting tired of hearing this, but this too seems like it might be caused by a problem with the original MusicXML file created by your scanning software, and then how that file was imported into MuseScore 1.3 MuseScore 1.3. What I see are two conflicting tempo indications in the file, but you don't see the problem in 1.3 because it handles this differently than 2.0 does apparently. Of course, it would be nice if MuseScore 2.0 could clean up after these errors. Could you post the original MusicXML file so we can see it contained and what happened when it got loaded in MuseScore 1.3? That would help in trying to fix this.

But to be clear - the issue you are seeing would not happen in a "regular" 1.3 score - one created form scratch in 1.3. It's a by-product of the conversion to MusicXML by your scanning software and the import into 1.3 that caused the tempo information to be saved in a way 2.0 isn't handling as expected.

In reply to by Marc Sabatella

I c... well thats good and bad....bad bc now I will hv to chk back over all the files I save or open in 2.0.

Good bc 2.0 brings up hidden problems that should prob be fixed anyway....

I am wondering of there is not a way of hving some ways that when 2.0 opens a 1.3 file it tells y or higlight potential problems..

Would it be any good if I export to xml in 1.3 then open that xml in 1.3 to see any potential problem first?

Also would it make any difference if i export to xml in 1.3 then open the xml in 2.0 instead of opening the 1.3 mscz file directly in 2.0?

In reply to by wildpig

Well, I'd say it would be good to fix as many of these issues as we can, so I encourage you to keep positng them as you find them. But you you do so in new threads in the Technology Preview forum, or else in the issue tracker - and you might as well just get in the habit of providing the originasl MusicXML file as well as the file you saved in 1.3, along with a description of what difference you see.

In general, you should normally expect to give a quick look to files saved with a previous version, but you shouldn't expect to see differences worth worrying about. I'd say only files that came from scanning software or otherwise came from suspect sources (bad MusicXML can be generated by things other than scanning software) would you need to look at carefully.

As for having 2.0 automatically detect bad input, I'd say, anything we know to look for and hence detect, we can probably fix - so keep posting when you see issues, and we'll see what we can do. So far I've already fixed the cross staff issue (which was a real bug that would affect new scores too). The playback tempo issue would be nice to understand, but again, seeing the original MusicXML from the scanning software would be very helpful there.

So far, nothing else is the sort of thing that we could do anything about. Chords attached to the wrong staves are trouble in 1.3 just as much as in 2.0 - had you done anything to your score in 1.3 to cause more staves to fit on the page, you'd see the exact same problems. But there's no way for MuseScore to *know* they aren't attached to the correct staves - it has no idea what staves they *should* be connected to.

I don't think exporting to MusicXML from 1.3 would help - these files already have issues, and since 1.3 is not as good at MusicXML as 2.0 Beta, you'll probably just get *worse* results that way.

Importing the *original* MusicXML file into 2.0 would almost certainly be an improvement over importing them into 1.3. But if you had already done a lot of cleanup, that work would be lost.

Basically, with scanning software, it's going to be very hit or miss in the first place, and then combining that with trying to import a file into a major new version, I think you're just going to have to expect some amount of extra work to clean those up.

In reply to by Marc Sabatella

I went back to everything i do and i think i figured out the tempo prob. nothing to do with original scan. The adagio property was set at 95 but the playback speed in play panel was set at 62%. So when 2.0 opens the file it plays back at 95 or 100%. I guess the playback % in play panel doesn't get carried over into 2.0 somehow but does get carried over in 1.3 from one computer to another.

There is plus and minus to saving the playback speed setting to carry over but i do see that its a good idea to have the correct tempo setting anyway instead of a bad tempo and a different playback speed to compesate but I do think that sometimes it's a good idea that playback speed % should be saved also...

In reply to by wildpig

Oh, yeah - about the chord symbols in Everything I Do - as I expected, they are kind of scattered all over the place in 1.3 too, some appearing way too high, some too low, etc. Is this is the result of some scanning software? In 1.3, I see some chords are actually attached to the staff *above* them rather than below, which is totally wrong. The reason they look different in 2.0 Beta then, is that 2.0 managed to fit more systems on the page, so the chords attached below the staves are now colliding with the next staff. This wouldn't have happened had the chords been attached correctly in the first place. But If you force a page break after three systems, you'll see the same layout of chord symbols as in 1.3.

For the scores you have that were scanned then imported via MusicXML, it could be interesting to try importing the original MusicXML into 1.3 again and then into 2.0 Beta 1. The MusicXML import in 2.0 Beta should be considerably improved. But it can't fix errors for you, like the notes or chord symbols that were put in the wrong staves by the OMR software.

In reply to by wildpig

Realistically, some change in layout is to be expected. The new default layouts should be in virtually all cases *better*, but if you had made manual adjustments to work around deficiencies in 1.3's default layout - if you had incorrectly used manual layout adjustment in places where you should have simply changed the anchor points for elements (eg, extending voltas or slurs with mouse rather than shift+right/left), then you will find some of those adjustments won't look right any more. We actually strip off manual adjustments in cases where we are pretty sure they won't be needed because the new defaults are so much better - in these cases, the new defaults might be different fro what you did manually, but should be at least as good.

I'd suggest starting a new thread for any score you have where there are issues you don't think are adequately explained by this. Certainly, there shouldn't be *any* cases where the notes themselves differ!

I just want to add right now, since I've downloaded MS 2.0, the playback has been amazing, a huge step up especially for the drumline add on my instructor made. Now with 2.0 the playback will actually play diddles, and correctly too, with one slash dividing the note in half and 2 slashes doing what's expected. Mike doesn't know about this yet but I know it'll make him extremely happy once he realizes the can play back without having to put 5 times as much work to make the rolls sound. Everything works well too, and this function still happens when you upload old musescore files from the old version. Only complaint is that it felt harder to incorporate the drumline add on than in the old version, but that could just be me after not doing it for awhile.

I'm wondering how I can select a large group of notes and set to small?
In 1.3 I simply used shift+click, then note properties on any one of the notes. However, if I shift+click in the Beta it seems I get an "element" in the inspector.
Other than that, it has been a great time for me using the Beta. I especially appreciate the addition of feathered beams!

In reply to by Haotian Yu

The reason you only get "element" in the Inspector when you select a large region is that the region actually contains things other than notes, and the Inspector is necessarily pickier than the dedicated "Note Properties" dialog about non-homogenous selection. So the solution is to modify your select to only include notes. Easiest way to do that is, after the selection, right click a note and "select all similar items within selection range". This is a nice new addition that will have many uses I'm sure.

Is there an easy way to revert to the old keyboard shortcuts without having to manually redefine everything?

Also, are there any options to use the system theme for the UI (I'm on Arch Linux x64) instead of just "dark" and "light"? I like to use the Redmond/Windows style instead of the default Oxygen style.

Hello, I have a problem when exporting PDF file - some texts are moving (bar numbres) and tempo markings do not space correctly (I mean "quarter note[no space]=[space ok]80". This bug happened to me with other 2.0 development versions.

Thank you and congrats for this great scoring software! :)

Attachment Size
My_First_Score.pdf 21.35 KB
My_First_Score.mscz 1.6 KB

I cannot figure out how to do slash notation in beta 1. The slash instructions in the help file appear to be for the 1.x version. The slash plugin does not work with beta 1 - or if it does, I cannot figure out how.

Also, with beta 1, the paste function overwrites existing chord symbols. Would be nice if there were a dialogue that would allow one to choose what is copy and pasted.

In reply to by Jim Ivy

I have not tried plugin's for beta 1 yet, but it seems you'll have to create slash notation from scratch. By that, I mean insert notes on middle staff line, give the notes slash note heads from the note head palette. Then with the note heads highlighted, in the inspector go down and uncheck the play option, so they do not sound with the playback.

For pasting, what are you trying to paste?

In reply to by Jim Ivy

The plugins are not working well with beta right now, but that will be fixed.

Meanwhile, slash notation can be created directly in Inspector window. Enter a note, use Inspector to mark stemless (if desired) and change head, then copy & paste that around.

As for copy & paste, I assume you mean that if the source has chords, they now overwrite chords in the destination. No overwriting should take place if there were no chords in the source. And if there 8are* chords in the source but you don't want them copied, you can now use the new Selection Filter (in View menu, or shortcut F6). Uncheck "Chord Symbols" before the copy, and now you can copy and paste a region that includes chord symbols without the chord symbols coming along.

In reply to by jotti

Even simpler, you'll now find Swing as an option on the Text palette. That applies it to the whole score from that point. Or create a staff or system text manually and set the Staff Text Properties yourself.

One of the reasons that I originally left Finale and came over to MuseScore a couple years ago was because of its native Linux support. I have to say that I am very disappointed to find that there is no Linux version of the 2.0 Beta.

Is there any plan to release one? I would think that it is important to find bugs in the Linux version as well as Windows and Mac.

In reply to by brianr0922

@brainr0922 all the MuseScore on Linux maintainers were informed about the beta and asked reply when they had a package available for testing. So far we received no replies.

What I propose you do, is post a message upstream in your Linux distro forum, with the request to provide a package for this first beta. If you can compile yourself and want to provide the package, make that post as well. In either case, reply on this comment with the link to your post. We can than feature the link in the main beta 1, 2, ... announcements.

How does that sound?

Note:

  1. There are always the Linux nightly builds: http://prereleases.musescore.org/linux/nightly/
  2. The MuseScore lead developer uses Ubuntu to develop MuseScore. So this way we know it's at least working on Ubuntu.

In reply to by Thomas

I see there are now Linux downloads. Thank you very much for providing them. I am working on setting my system up so I can do builds again. (I just have to upgrade my version of QT.) I will help out where I can when that is done.

Thanks again!!

but in 2.0, how do you save the file as a MIDI or .wav or whatever? Before, you could just click on "Save As," and change the file type. Now, I'm only getting the option to save as a MuseScore file.

Hi Marc,

The 1.3-version had different tuba's, in different keys.
This is been changed in Beta (for the good), in only the F-tuba.
However, very little possibility to add chorus and or reverb like in 1.3.
The only thing you can choose from (Sythesizer) is No Effects or Zita 1, and it seems that it is just one effect, without controls.
Do you know why?

Frans

In reply to by karelmollen

actually I don't think that is good at all to have only one tuba.

What if you had a piece of music that needed a Bb tenor tuba and a C bass tuba such as The Planets by Gustav Holst?

You wouldn't be able to do it unless you had F tenor tuba and F bass tuba and transposed them to Bb and C respectively

I created the version 1.3 rpms for PCLinuxOS. If anyone wants, I can create them for beta2. PCLinuxOS does not officially distribute beta software, but I can create and upload the rpms or src.rpms to dropbox. I am very excited for the next release.

Galen Seaman

Congratulations! It's user friendly, quite stable and flexible. The ability to use different time signatures simultaneously is great.

This works great so far from what I've seen (and on Vista, an unsupported platform)! So far, I've only run into one issue (the PDF export using Gonville and Bravura, which has already been posted as an issue), and that really isn't even a concern for me due to there being a possible workaround of using a PDF conversion printer driver, which works perfectly. Other than the PDF export issues, I haven't run into any problems, and there are a lot of improvements I like.

Magically it works in 2.0 Beta! I'm so excited...if you have been having problems with an older keyboard give this a shot. Whoopee wazoo!

Hello again, I just tried to import XML file to MuseScore 2.0 BETA and the program stoped working and closed. I tried this several times and it is the same.

Thank you!

In reply to by robthesaxplayer

Swing playback *is* in, and greatly improved! In 1.3, you had only two ratios to choose from (eighth note swing & shuffle) and it applied to the entire score - all staves, all measures - and wasn't saved with the score. In 2.0 Beta 1, you can choose any ratio you want, apply it to eighths or sixteenths, and also control which staves and which measures the swing is applied to, and it saves with the score. See "Swing" on the Text palette to get started; use Staff Text Properties to customize.

I downloaded the beta version for windows and run it with wine on Linux. Fantastic job! The linked parts are an extraordinary improvement. Better placement of objects also. Is there a plan to have system separators (double thick shotr lines between systems)? That would make so near perfect!

In reply to by Marc Sabatella

I don't think you hear it enough. I'd like to extend my gratitude and jealousy to the entire development team. I've read many posts in the Issue Tracker and the Technology Preview Forum. All that you accomplish each week is amazing. It's like a song in itself. I look forward to the new features I've tried with the beta and the nightly builds with patient anticipation. Please take the time you think you need to do it right. Take care.

In reply to by Vincore

There is not likely to be an official "portable apps" version until sometime after the real 2.0 release, but actually, the nightly builds *are* portable. Click the Download link in menu at right of this page, scroll down to nightly builds, download the most recent, unzip it into a flash drive, and run the nightly.bat script (Windows, anyhow). Should work just fine.

In reply to by Vincore

Exactly. The Beta build was really just one nightly build that we decided was good enough to label "beta" and package up to make available via the install process rather than the usual zip method. Since then, there have been over 80 fixes made in subsequent nightly builds. When you go to download one, you'll see dire warning about them being unstable, but really, those are just leftover from years/months ago when they *were* very unstable. They've been incredibly stable since the Beta, though - we've had an excellent track record lately of not breaking things as we fix others. So you can pretty much count on any given recent nightly build being at least 80 bugs better than the Beta. Even if a new bug is introduced here or there, I think it's still a better bet for most purposes than the Beta. Not that the Beta isn't good or worth using, but if you have any inclination at all that nightly build might suit you better - either because of the bug fixes made since beta or to get a "portable" version - I think you should go for it.

In reply to by Caters

Indeed, if your goal is stability above all else, definitely wait. The Beta and Nightly builds are for people eager to try out new features and help in the testing process.

Although to be honest, most of the known 1.3 bugs that are likely to be fixed for 2.0 are already fixed in the Beta, and a few more have been fixed since then. The main bugs left to fix are ones introduced while developing the new features.

My personal sense is, the Beta will feel less stable than 1.3 - a few too many crashes and score corruptions - but I think we're getting close to a point where the Nightly builds may actually be *more* stable than 1.3.

I am trying to build the rpms for PCLinuxOS and I've hit a few snags. Fortunately, all of the dependencies are in the repos, I just had to find them. But, I've never worked with pre-compiled headers, or -fPIE. Is there a way to turn off these features (and debug, if it is on). The standard pre-defined distro compile flags seem to be ignored.

Galen

In reply to by gseaman

You can turn out this feature in the main CMakeLists.txt but precompiled header is making the compilation a lot faster. If you want, you can join #musescore on freenode.net to get some help with the compilation.

In reply to by [DELETED] 5

I am not concerned about compile times. I am building a source rpm for distribution for PCLinuxOS. I hope to be able to submit to the repositories on the day that 2.0 is released. I have it compiling, but there are still a couple of packaging issues to work out. Thanks for the help.

Galen

perhaps it is because of familiarity, but I can work much more quickly in 1.3 than in the beta version. I do not get the logic of the new menus in the beta. Things that I found simple to do in 1.3 take more steps to accomplish in the beta. I particularly dislike the "inspector" gadget and am very hopeful that 1.3 will still be supported after the release of 2.xx.

In reply to by Jim Ivy

I think many of us found the aspects of the new interface new/unfamiliar and hard to get used to at first. But after getting accustomed to it, and realizing how amazingly wonderful it is to be able to leave the Inspector up at all times and not constantly have to open and close right click menus and individual properties dialogs, there is no way I could ever go back. Virtually everything one might want to to is now much easier & faster than before - once you learn how to do it.

So definitely, feel free to post examples of operations you are having trouble figuring how to perform as efficiently, and my bet is, we can show you how to do it faster than ever.

The grace notes in the 2.0 are actually playing (sounding) too slowly in the new 2.0 beta. They were great in the 1.x versions. (I haven't tried any nightlies yet so if that's been addressed yay!) It just really messes with my ears during playback to hear grace notes play awkwardly.

In reply to by [DELETED] 87939

You might wish to start a new thread and post the score you are having problems with. But be aware there are two types of grace notes. The kind without the slash are called appoggiaturas, and they are *supposed* to play slowly - half the value of the note they are attached to. See http://en.wikipedia.org/wiki/Ornament_(music)#Appoggiatura, for example.

But if you have the kind with a slash (acciaccatura) and find they are playing too slowly in some given score, again, start a new thread and post the score and we can take a look. When I've tried it, both kinds of grace notes play better in 2.0 Beta * nightly builds than they did in 1.3, although acciaccaturas on very long notes are still too slow just as they were in 1.3.

Does anyone know if in the Beta there will be built in Marching percussion samples? or will we have to get them from a different "developer" like in MS 1.3?

I get a segfault. What are the build requirements and versions? I've included every development library shown in the Ubuntu and Fedora build pages. I have qt 5.2, is 5.3 required?

Also, I had to replace all references to /usr/local with just /usr. cmake doesn't seem to follow environment variables.

[galen@localhost ~]$ mscore
"Qt Warning - invalid keysym: dead_actute"
Segmentation fault
[galen@localhost ~]$

Galen

In reply to by Jojo-Schmitz

Thanks for the tip. It still segfaults, but the program shows on the desktop for about 1 second.

[galen@localhost ~]$ mscore -F
"Qt Warning - invalid keysym: dead_actute"
cannot read workspace <>
Segmentation fault
[galen@localhost ~]$

Maybe this gives a clue?

(I am currently packaging qt 5.3, just in case.)

In 1.3, when I wrote an accidental, say A♭ in the key of C major, then another A in same bar, I got a natural A. In 2.0 Beta I get automatically an A♭, which might be convenient, if I write tonal music. Is there a setting somewhere, where I can choose whether I get A♭ or natural A for the next click in the same bar? I happen to write atonal music at the moment, very complex structured music with lots of notes and chords in same bar, and it gives me problems to check whether my clicked note is A♭ or A.

In reply to by jotti

A possible workaround is to use the built-in piano keyboard ('View' menu, or press P). Using that you have complete control over entered notes. Works well for me, especially after moving the virtual keyboard so it's directly under the note entry bar at the top.

In reply to by jotti

Hi Jotti,

there is indeed a change at this issue between the 1.3 and the 2.0.
While, for me, the 2.0-version is more convenient, I don't think that it is realy a problem for most of us.
In the 1.3-version of Musescore, if you wanted your Ab "repaired' into an A, you had to do nothing; but if you wanted the same Ab again, you had to repair it.
In 2.0 it's just the other way, which obviously is for you less convenient.
Here you'll have to repair your Ab into an A, but if you're score wants the same Ab, thén you'll have to fix it.
I don't know, in your case, if there is a solution for it.
I only can suggest to write a G# for the Ab and then you'll get an A instead of an Ab.

Good luck,
Frans

In reply to by karelmollen

Whether I've entered G♯ or A♭, I still might want to enter G or A later in the bar. And I'd still have to check among ten noteheads whether I've used G♯ or A♭ earlier in the bar. There should be a setting for this, which could be toggled when switching back and forth between tonal and atonal music.
The Western score writing convention is based on tonal music. And actually I'm adding the courtesy accidental for the second occurrence of A♭, just because of the music being atonal.
What rickfitz suggested might work well for me, as well as a midi keyboard.

I spent the last two days entering in a composition, about 300 bars long. On the last page, I pasted some material from earlier in the score, and 2.0 crashed. I re-opened, and the score was intact. I attempted to do the same, another crash. When reopening, I got a message that said Musescore could not read the file. I examined the score on my drive, and sure enough it is 0k. I've never had any program do this to me before. I would attach the file, but I can't see it in the dialogue box.

In reply to by Soolip

Sorry to hear this happened! But hoepfully we can help you recover your score. First, you say you examined the score on your drive - I assume that means you can find the file. Are you on Windows, Mac, or Linux? What folder is the file in, and what is the filename? When you go to attach the score to a forum post, it won't necessarily look in the same folder your score is in, but you should be able to navigate to that folder normally, and if you could find the file there before, it should still be there unless you deleted it (in which case, it is probably in a recycle bin).

So, start by attaching that. Other things we can try if there isn't something we can do from the score you attach will include finding the backup copy created by MuseScore last time you opened the file (same folder, same file name but with a "." in front and "," at the end) or the auto-save version MuseScore saves for you every two minutes (in a different folder with a not-useful filename; details will depend on what OS you are on).

In reply to by Marc Sabatella

Hi, the file is now 0k and apparently occupies no space on the drive. I can see it in the Finder (OSX, Mac), but I can't attach it because I can't see it in the dialogue box when I go to its location (Users, Me, Documents, Musescore 2.0, Scores). If Musescore makes backup files in other locations, that would be great! Where do I look? Thanks.

For one thing, slash scoring is simple in 1.3 - impossibly difficult and time consuming in 2.0.
The "Inspector" is a pain. Takes up space and is clunky to use.
Things that should logically be "note" operations are "measure" operations.
The menu changes are ok, but for the most part they seem to be different for the sake of being different.
On top of that, 2.0 seems to lockup quite often.

!.3 has been, and continues to be, a joy to use. Since it runs on Linux, I have been able to abandon Finale. I will continue to use 1.3 for the time being, but I do not consider 2.0 to be a viable option to either 1.3 or Finale.

In reply to by Jim Ivy

If you are referirng to the plugin for slash notation, we plan to get that going for 2.0. It just sin't there yet for the beta. But if you are not using thre plugin, it's should actually be easier to create slash notation in 2.0 Beta than it was in 1.3, because all the settings you need are right there in the Inspector. The only thing that is slightly harder is selecting the range, because you now need the one additional step of limiting the selection to just the notes (after selecting a range, right click a note, select all similar elements in range selection). But the rest of the process is enough simpelr that it ends up being a wash - again, if you weren't using the plugin.

I think the Inspector will grow on you as you get you used to it. It's actually a *ton* more convenient than having the settings scattered in a dozen different modal dialogs. Y0u can just leave the Inspector up alkl the time and it doens't interfere with your ability to use the score (unlike a modal dialog), or you can open and close it with a single keystroke (asgain, unlike a modal dialog). It's an adjustment, but absolutely better in every way.

The menu changes are mostly for the sake of standardization. Not sure which you are thinking of, but for example,. msot programs have "View" menus, not "Display" menus. And most design guidelines as well as most other programs call for things like PDF conversion to be in an "export" menu rather than "save as", etc.

Which things that are measure operations do you think should be note? I can't think of anything that has changed in this respect. Are you talking about the Measure Properties dialog - which is essentially unchanged except for having additional capabilities that didn't exist previously - or something else?

If you experience lockups, please report them. We can't fix problems people don't report!

Anyhow, I think you'll find your concerns with 2.0 are almost all just a matter of initial unfamiliarity. As someone who has been using it daily for months now, I can confidently attest it is more efficient than 1,3 for virtually everything you might possibly want to do. Things like text styles and linked parts abd the vastly imrpvoed chord symbol parser and layout engine - it's night and day how much better 2.0 is once you get used to it. You'll see :-)

If there is something *specific* you arre finding hard to do, feel free to start a separate thread asking about it, and I'm betting we'll be able able to show you how to do it easier/faster in 2.0 than 1.3.

I don't remember how well this worked in 1.3, but in 2.0 the following occurs:

ex1-1.png
This is what I entered. Then I'd like to move the 3rd and 4th chord in the 2nd group to the upper stave.

I get this:
ex2-1.png
The 1st and 2nd chord remain on the lower stave, as they should, but their stems have moved upwards. And the stems end at the topmost notehead, not at the bottom one. The stems did the cross stave thing, though they oughtn't!

I can double click the beam and adjust it. And I can double click the stems to adjust them to get this:
ex3-1.png

But the stems still don't reach the bottom note head. I use 1efc609

Attachment Size
ex3-1.png 23.58 KB
ex2-1.png 23.55 KB
ex1-1.png 23.03 KB

I just installed 2.0. I'm sure I will have a bunch of problems, etc etc. But my first impression is complete amazement: the MuseScore team has really outdone itself! I can't tell you how excited I am to tackle an upcoming series of arrangements. The best thing in notation software has gotten better!

Thanks for your tireless and expert work! The world is a better place thanks to MuseScore!

Hello, there was nothing in Library/Application Support (no Musescore 2.0 folder), either in the main or user libraries — no Musescore 2.0 folder at all. Also, no invisible backup files had been created as described (.Quartet_inD.mscz,). For some reason I was able to attach the file this time.

Attachment Size
Quartet_in_D.mscz 0 bytes

Aloha,

I remember in MuseScore 1 there was a way to mute the sounds while you inputted so that you wouldn't hear the notes as you put them in. Is this feature available? And if it is, how would I go about doing it?

Thanks,
Matt

So the first thing I did (knowing me) was put a couple of marimba notes and a long note at the end and put a tremolo on top of it, only to see weather or not it would roll, and to my surprise, IT DID! I have been waiting YEARS for this, and I honestly screamed like a little girl. Just that much has made my week, thank you so much!

On my old PC, running 32-bit Windows 7 Home Premium everything worked fine so far. But on my new PC, running 64-bit Windows 8.1 the msi doesn't work. I can not even get to the installation screen. It just says something that means as much as: "This installation package could not be opened. Let the developers of the application check whether it's a valid Windows installation package or not" (my PC is in German as is my old one so I tried to translate best I can. I also added a screenshot of the message).

I really liked the beta and I'd love to use it again. Can anyone help me with this?

Attachment Size
2014-11-16_201653.png 10.58 KB

When I open the attached file ('Original') in MuseScore2, it displays fine as far as I can tell, but if I then save a new file and then try to open it, I get the following error:

Cannot read file C:/Users/[PATH]/Visions_of_Scarborough_Fair.mscz:
bad format

I have attached this file as well ('After').

Unfortunately, I will be unable to use this version until this is fixed. :(

EDIT: Running Windows 7

In reply to by schepers

Removing the parts in 1.3, saving the file, opening it in 2.0 and regenerating the parts, saving and reopening does work though.

the after score gives the following debug messages:
Debug: htmlToString: read token: Invalid (...\MuseScore\libmscore\xml.cpp:668, QString Ms::XmlReader::readXml())
Debug: read empty text (...\MuseScore\libmscore\box.cpp:244, virtual void Ms::Box::read(Ms::XmlReader&))
Debug: Visions_of_Scarborough_Fair: xml read error at line 189980 col 28: (...\MuseScore\libmscore\scorefile.cpp:1158, bool Ms::Score::read(Ms::XmlReader&))
Debug: Visions_of_Scarborough_Fair: xml read error at line 189980 col 28: (...\MuseScore\libmscore\scorefile.cpp:1158, bool Ms::Score::read(Ms::XmlReader&))

There it apparently stumbles accross the & in the name of the path for "Horns 1 & 2".
Attempt to fix that file attached

Anyway, this needs to move into a separate and new thread.

Attachment Size
Visions_of_Scarborough_Fair.mscz 446.94 KB

I just installed the latest muse score beta 2.1. I notice a few things. When you first open the muse score dialogue the start center does not seem to be able to be arrowed through.

Also I' trying to create a blank templet as this piece is going to have 8 parts, 2 on each from alto to soprano.I tried selecting blank but hitting space, enter, etc gets me no ware. It seems I might have had this problem before, but I'm unsure. it seems well that when you tab between common and the list of instruments you don't get feedback you have moved. I'm using a sound scheme in NVDA to help me know I did in fact move. It also appears to crash easily. I just got the this program has stopped responding. Hitting escape has closed the score creation process. The key signature dialogue is also not accessible. I can't see what I'm entering. to add one more thing I could not input notes after I got done creating the score. Who knows if I'm in the right key, hopefully e minor. I also cannot figure out how to add an anacrusis. going back to the score creating dialogue if I add a staff I cant' hear the tree view anymore. Oh it speaks but with the latest nvda snap, I arrow and nothing is spoken besides the fact I'm in a tree view. I do see a lot of potential in this piece of software.

In reply to by marrie1

Hello, and thanks for your feedback! I would suggest you download the latest Nightly build (see Downloads link at top of menu at right of this page), as there have been a number of accessibility-related fixes since the Beta. Then report any issues you find in a separate thread.

The key signature selection window is indeed not currently accessible. In general, very little having to do with creating and editng scores from scratch is going to accessible, but it should work pretty well for *reading* existing scores, including scores imported from other programs via MusicXML. So you may wish to focus your feedback on issues you see within the score *reading* functionality, since we pretty much know that score *creation* and *editing* is not very accessible yet We do of course hope to improve that situation, but probably not before the the 2.0 release.

In reply to by EnriqueGirona

Not sure what you mean. The 2,0 Beta 1 release (which happened over seven months ago; not sure why you're responding to this thread now) *did* include a tremendously improved soundfont - FluidR3, which is much, much, much better than the the old 1.3 soundfont and arguably the best freely available, freely licensed SoundFont GM-compatible available. This is stated in the list of improvements in the original post.

The final 2.0 release uses this same basic SoundFont but with a few tweaks and improvements suggested by many users of the beta and nightly releases over the course of the last seven months.

Anyhow, if you know of a SoundFont that suits your own personal needs better, you are welcome to use it instead.

In reply to by EnriqueGirona

Soundfont quality compared to what???

There is an initiative currently to address issues with the MuseScore 2 default FluidR3Mono soundfont, but it is time-consuming work.

If you have specific issues with it which you would like addressing please discuss them in the soundfont forum: http://musescore.org/en/forum/776 providing detailed information about your concern.

You are of course under no obligation to use the supplied soundfont. There are several others around which you may find preferable. Again you will find some of these listed in the soundfont forum.

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