MuseScore 3.0 Beta Release

• 2018/11/28 14:45

We are pleased to announce the release of MuseScore 3.0 Beta.

We have been working on MuseScore 3 ever since the release of MuseScore 2 back in 2015, and with this Beta version, we are one big step closer to a final release. Meanwhile, we have fixed all the critical issues reported against the previous Alpha versions. We want to make sure MuseScore 3 is as bug-free as possible, so please help us test this Beta release.

Download MuseScore 3.0 Beta

Release Notes

As a major new release, MuseScore 3 contains some very significant and exciting new features and improvements over MuseScore 2.3.2 and older versions:

Improved score layout

  • Automatic placement, layout, and spacing means your scores are ready to print with almost no manual adjustments required
  • Generate parts from individual voices so you can combine instruments on a single staff
  • Take control of your layout with manual overrides, above/below placement settings, temporary and cutaway staves, mid-score staff type changes, and more

New notation features

  • Handwritten font for music notation
  • Noteheads with pitch names
  • Automatic system dividers
  • New articulations, expression text, clefs, accidentals, augmentation dots, capo changes, and more

Improved usability features

  • Tours to provide help as needed
  • Timeline and single page view for easier score navigation
  • Score comparison tool to identify differences between versions
  • Timewise insert and delete to provide more editing freedom
  • Search facility to help you find palette elements
  • Improved Style and Inspector tools for control over appearance and behavior of score elements

Improved playback controls

  • Improved Mixer for easier control of instrument sounds
  • Improved Piano Roll for fine control of individual notes
  • Improved Play Panel for faster access to playback controls

New autoupdate facility for Windows and MacOS

A brand new autoupdate engine has been developed and included in MuseScore 3 Beta. Keeping up to date with new releases no longer requires you to manually go find and download them. Just let the autoupdater handle downloading and installing of the new version for you! Receiving our latest bugfixes and features has never been easier.

Watch the video to see how it works on Windows.

Note, the autoupdater uses your OS locale which means that the language of the autoupdater interface will always be the same to your OS language.

Known issues

Save Online - musescore.com supports the scores created with MuseScore 3 Beta in testing mode. You are able to upload scores via the musescore.com interface. Save Online is still not available in the editor until we are sure that musescore.com processes al the files correctly. An update will be made available to enable Save Online within the editor, and autoupdate will make sure you can take advantage of it right away.

MuseScore 3.0 Alpha 2 doesn’t update automatically to latest Beta. Please, download .dmg file from the downloading page

For a complete list of open issues, visit issue tracker

Works along with MuseScore 2.3.2

You don't need to uninstall previous versions of MuseScore in order to use MuseScore 3.0 Beta. It can be installed alongside older versions, and you can continue to work in your current version while trying out MuseScore 3 Beta. It uses separate directories for all files (Documents/MuseScore3), so you will not accidentally overwrite your existing scores.

Note: MuseScore 3.0 Beta will not be associated with .mscz file format on Windows, so if you double-click on a score in File Explorer, it will open in your current version of MuseScore. You can open scores from File Explorer in MuseScore 3.0 Beta using the Open With… menu.

Read more about new features in MuseScore 3.0 Alpha 2 announcement.

Acknowledgements

MuseScore is developed by a vibrant community of programmers that continues to grow. In addition to the people like ws (Werner Schweer), lasconic (Nicolas Froment), miwarre (Maurizio Gavioli), Marc Sabatella, jojo-schmitz (Joachim Schmitz), Leon Vinken, shoogle (Peter Jonas), and trig-ger (Andrey Tokarev) who created MuseScore 1 and MuseScore 2, many new faces have helped shape this MuseScore 3 Beta release. Some of the major technical contributors include dmitrio95 (Dmitri Ovodok), mattmcclinch (Matt McClinch), jthistle (James Thistlewood), handrok (Alexandr Popov), tobik, blackears (Mark McKay), Felix Brauchle, Johannes Wegener, jeetee (Johan Temmerman), joshuaBonn1 (Joshua Bonn), ericfontainejazz (Eric Fontaine), and (anatoly-os) Anatoly Osokin. In addition, a group of dedicated users have been instrumental in testing and making suggestions. We would especially like to recognize cadiz1 (Jean Bernard Roy), mike320, geetar, and Isaac Weiss.

Contributions statistics

We have been doing a great job since MuseScore 3 Alpha 2 release. Within less than a month:

  • 158 Pull requests were created
  • 130 Pull requests were merged
  • 198 commits were pushed to master branch from 19 contributors
  • More than 150 issues were fixed
  • Less than 125 issues are left with P0 and P1 priorities

Upcoming events

  • Revising issue tracker and priorities of the issue reported for 3.0 version
  • Support for scores created in MuseScore 3.0 Beta on musescore.com
  • Fix all P0 and P1 issues and make MuseScore 3 Release Candidate (target date is December, 10)

Stay involved

If you find issues in MuseScore 3 Beta, we encourage you to post about them to our support forum. 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. Please indicate that you found the bug in the 3.0-dev version. Please take a look at the category system we use.

MuseScore 3.0 version has been developing for a long time which means there are a lot of new strings that need translation. If you would like to participate in the translation effort, you can get started by visiting Transifex.

Further reading

コメント

• 2018/11/28 22:40

Why didn't You add current translations to the installation packages? Why don't the official beta support updating translations via the Resource Manager?

返信

• 2018/11/29 10:12

Yeah... For version 2.3.2... The version of translation in the Resource Manager is for 2.3.2, so it isn't work. The versions of translations in the package is for MuseScore... 2.2? Where are shortcuts in Preferences? The Palette - all in english, but I translated it! I have a bad feelings about this... Now, it is a crap. Sorry. It looks like early alpha.

返信

• 2018/11/29 10:29

Translations in 3.0 are for 3.0, the ones for 2.x are frozen. (and the shortcuts issue is known and being worked on, see #278970: Preferences/Shortcuts not shown (and so not changable) and use the -e command line option as a workaround)

Edit: seems there's indeed something wrong with the translations, they can get updated but don't seem to contain the latest 3.x strings even if those are translated on Transifex.
Filed in #279012: Updating translations doesn't work.

返信

• 2018/11/29 16:46

Yes, Jojo - all translations for downloading via the Resource Manager are for MuseScore 2.3.2.
After the installation of MuseScore 3.0.0 Beta (with old translations, for MuseScore 2.2), I want to update Polish (whichever). I downloaded the update, did quick restart of MuseScore and... the translations have been updated… to 2.3.2 :D

返信

• 2018/11/29 16:56

Maybe it is Beta, the name is Beta, by definition. But it looks like early alpha, one of the nightly build for developers and testers. In the installation package only :D

When the next beta, more beta than alpha? :P

Question:
Will I be able to add updates for Gonville/Gootville font in the future?

返信

• 2018/11/29 17:10

You could have tested the 2 Alphas and voiced your concerns then...
And I can tell you that those Alphas really were Alphas,esp. when compared this Beta.
Translations not being available is bad, but not a reason at all to condamn the entire version.

What updates to Gonville do you expect? I'n not aware of an PR from on this and you're the designated maintainer...

返信

• 2018/11/29 03:37

Fellow MuseScorers:
Please try to keep questions about MuseScore 3.0 beta (and any development builds) in the 'Development and Technology Preview' Forum.
The forums for the current stable release (MuseScore 2) -- 'Support and bug reports'; 'General discussion' -- are starting to get all jumbled with MuseScore 3 questions.

This will make it easier for those of us manning the version 2.x help desk... 😂
Thanks.

返信

• 2018/11/30 01:56

Hello, I'm excited for the new release! Question: will the new release include the feature to break slurs or ties, such as in the image where the tie crosses over the time signature? Thanks!

tie over time.png

添付 サイズ
tie over time.png 15.02 KB

返信

• 2018/11/30 06:24

Nothing is implemented for that yet. One slightly useful thing, though, is the ability to set the "Stacking order" for elements - which displays on top of which - so in theory one could construct a graphic that blots out the slur and then make sure everything stacks in the right order you can still see the staff lines and time signature. It's fiddly, but it works:

blot.png

返信

• 2018/11/30 09:55

Is there an XML file with standard shortcuts available? When I open the preferences\Shortcuts tab it's empty and I have an option to load a ShortCuts xml. But I can't find the file.

返信

• 2018/12/01 18:03

Is there a way to use or impkement the old mixer? This one looks a little less efficient, since it makes a little more difficult to change patch to a line...

返信

• 2018/12/01 18:57

I'm not going to push MuseScore 3.0, as your decision to put a gravestone on the 32bit version takes with it tons of problems in my low-budget educational environment -- we need software that can "run" smoothly on both 32 AND 64 bits platforms. Though I'm sure that you can live with it. I'm sad that your "policy" force me in such direction.

返信

• 2018/12/01 20:25

The 32-bits systems are history. For example, Sibelius is 64-bit for a very long time, and 64-bit only. What 32-bit system are You using in your low-budget PCs? 20-year Win XP? MuseScore 64-bit is very good decision. I like it!

返信

• 2018/12/02 08:06

In the school where I work, I have to deal with platforms spanning from XP Service Pack 2 to some sparse Windows 10 machines. MOST of them are still 32-bits systems, with a prevalence of of some sort of Windows 7 machines. When dealing with a classroom with 25+ YOUNG pupils working on an array of PCs, I HAVE TO give homogeneus intructions, so having some pupils working with (just to say) MuseScore 1.3, some others working with Musescore 2.2 and some others working with MuseScore 3.0 is not a viable option. I'm sure that those of you that have teaching experience can easily get the point -- my instructions MUST be unique, or "terrible" things would happen in my class management.

P.S. My school dismissed its last Windows 98 machine just two years ago and its last Windows 2000 machine a few months ago. Why? Because their hardware died of consumption. With no hardware failure, those machines would still be with us, historical or not. Budget, you know...

返信

• 2018/12/02 11:28

Having Windows XP, 7 and 10 is already violating the target to have identical, homogeneous, unique systems/instructions for all pupils. And I'm not sure a 32bit version of MuseScore would run on XP, not sure whether Qt 5.9 supports that. As far as I can see Qt 5.6 was the last that supported Windows XP (and that already as the minimum), later versions require at least Windows 7. So even if someone would provide a 32bit version of MuseScore, it probably won't run on XP.

返信

• 2018/12/02 12:35

I don't think the situation is much different in even richer countries, Germany included :-( Here schools are still in Cretaceous (in both senses of the word, way back and behind other countries and still using crayon on black boards rather than electonic equipment)
But I certainly agree, PCs running XP are really badly outdated and it can't be expected from anyone, including MuseScore, to still support them

返信

• 2018/12/02 22:44

I'm now writing from a 32bit, Windows 7 system that works quite fine and, I am sure, will go on working fine for AT LEAST some other five years (indeed, I hope some more than that). My 2005 XP system (yes, I use 2.3.2 on XP on a regular basis) I use as a music workstation makes wonders with its 201x (I can't remember the exact year... 2014? 2015?) six-core Athlon, running like hell while managing tons of heavy-duty VSTs. I don't like throwing anything into the bin. I hate planned obsolescence, and I rate it very close to just a form of piracy.

Opinions, of course. Or not?

P.S. What should I say about my 2001 iMac G3 600, still on the run and shining side by side with its 2004 companion macMini G4? Oh, by the way -- I put a gravestone on Apple systems as soon as I realized their attitude to use my wallet as their personal "bancomat" (I mean -- I stopped buying anything from them all of a sudden). MuseScore people, at least, are not "milking" my wallet in any way, which is a point of honour for sure. Still loving you, mates.

返信

• 2018/12/03 09:51

@Gootector I removed your recent unrelated comments where you were very rude talking about the community members. My comment was deleted because it was a reply to your comments, but it is ok. I think you can read it in the email box.

Please, don't insult people here but be involved and try to help.

返信

• 2018/12/02 22:31

You got the point, frfancha. In fact, I'm now happily using MuseScore 2.3.2 on every machine. I'm not going to update anything, for the sake of having a single version of the program. Moreover, I'm going to force my pupils to use 2.3.2 at home as well, or do by themselves all that is needed to provide their homeworks in 2.3.2 file format. I'm going to force them to avoid asking even a single question about new versions of the software at school (I don't want to deal with bunch of pupils confused about what does work on this and does not work on that, why a menu command is not there any more and such, asking for endless and pointless questions just to raise more and more questions in a potentially endless chain -- I have to teach music).

2.3.2 is going to be my tool of choice for many, many years to come, I think. Sad story, no doubt, but that's what's going to be.

返信

• 2018/12/03 07:10

I'll try it out on a Virtual XP first ;-)

Edit:_ Nope, sorry, even a 32bit build won't run on Windows XP, not with Qt 5.9 (if I try, I get "The procedure entry point CancelIoEx could not be located in the dynamic link library KERNEL32.dll."), not even with Qt 5.8 (which is the minimum MuseScore 3 needs), XP only works up to Qt 5.7.
So sorry, but there (most probably) won't be a MuseScore 3 version for Windows XP (but if so, then with more serious restrictions than "just" no WebEngine, responsible for displaying the MuseScore.com part in the new score wizard, the only restriction other 32bit Windows version would have to suffer from).

返信

• 2018/12/03 17:41

Ok Jo-Jo, many thanks again for both your time and your kindness. I will keep on using 2.3.2 (a really good piece of software, in my opinion -- just to let you know, some years ago I dismissed Finale and adopted MuseScore, as I think it's SOOO MUCH better for my needs).

返信

• 2018/12/26 18:31

@Aldo :
I think I managed to compile MuseScore 3.0 for running under Windows XP, by using Qt 5.7. However, I had to completely disable the plugin framework (among the other little hacks and workarounds caused by the different Qt version).
You can download such unofficial build here (as a zipped folder):
https://drive.google.com/open?id=16YAHbDpHmdBvgEcCbjQusFc-z1NDNpYV
In order to run it under Windows XP, you need to install the 32bit MSVC 2017 redistributable, found here (scroll down to the end of the page): https://visualstudio.microsoft.com/it/downloads/ or direct link https://aka.ms/vs/15/release/VC_redist.x86.exe
I hope this helps.
Please remember that this is an unofficial build for an unsupported operating system, but it should mostly work.
Ciao,
ABL

返信

• 2018/12/27 12:50

@mirabilos : here is the patch I used.
As you can see, it is very hacky.
Part of it is due to the fact that compiling with SCRIPT_INTERFACE=FALSE does not work right out of the box for MuseScore 3.0 (plugin manager functions are not completely removed when pluginmanager.h is removed, and cursor.cpp depends on fractionwrapper class). With this patch the plugin framework is completely disabled, but everything else should (mostly) work, with minimum Qt version 5.7 (Qt 5.6 would have required a lot more changes).

添付 サイズ
winxp.patch 8.99 KB

返信

• 2019/01/12 21:05

@ABL
I just read this reply of yours I didn't see before. I downloaded your unsupported version (portable, I see) and soon tried it on a 32bit Windows 7 Starter Service 1 machine with a really slooooow cpu and as little as 2 GB RAM. The program did not start well, crashing with an error message about a missing dll (namely, libgcc_s_dw2-1.dll). Got that dll via the web and put it into the "bin" folder and tried again. The program started, then crashed again when prompting the window that allows one to choose the document to start from. I decided to try a work-around and opened the program by drag-and-drop of one of the template files that ship with MuseScore3. Tah-dah! Up and running! To avoid further crashes at launch, I modified the preferences so that the program opens with "no document". Quit and relaunch, and all looks fine (by now, at least).
I'm now going to try more features of the program and see if something wrong happens (hope not).
Tomorrow I'm going to try your version of MuseScore 3 on a much faster machine (six core AMD cpu) running Windows XP with Service Pack 3, then I'll be back here to tell you the result.
Many thanks, man!

返信

• 2019/01/13 09:39

crashing with an error message about a missing dll (namely, libgcc_s_dw2-1.dll
This shouldn't happen, that lib is getting installed into MuseScore's bin directory if MINGW is on and BUILD_64 is off, see ...mscore/CMakeListe.txt line 620.
Seems BUILD_64 had not been set to off? If so I wonder why it worked at all for you after added that missing dll? Maybe the other problems are related to that, like the build would also not have used the -Wl,--large-address-aware compiler/linker options?

返信

• 2019/01/13 10:36

I compiled it with MSVC 32bit, in principle there should not be any reference to libgcc_s_dw2-1.dll. That's strange. I will try to see in detail which library or executable is searching for it.
@Jojo-Schmitz : MINGW flag should be off as well as BUILD_64. I fear it could be one of the dependency dlls which is asking for it. If that is the case, I will try to recompile it: the 32bit dlls are at the moment the same as those used in previous MuseScore versions, while most of the 64bit ones were recompiled by me with MinGW 64bit for the switch to 64bit (and apparently they are not searching for libgcc, or at least no one has reported such a problem yet).
Do you know the MSVC equivalent of -Wl,--large-address-aware?

> then crashed again when prompting the window that allows one to choose the document to start from
Do you mean the start center or the new document wizard? I will try to reproduce in my Windows XP: I strongly fear it could be a bug of Qt which got solved in more recent versions.

Ciao!

返信

• 2018/12/04 22:39

Hmm. Would a life boot or terminal server Linux enviornment work for you?

That is, you boot the PCs all from a CD-ROM or USB stick, or have a server installed and boot them from network, and you have a consistent installation all pupils can use. We have a setup like that in a charity I work with that deals with Free Software and Education (and it can authenticate against LDAP, so your pupils could continue using the Active Directory username and password).

Contact me privately if you need details or talking about. We’re currently setting this up at a school in Germany, although in a Free Software-only setup, i.e. removing Windows® there altogether. (So far, feedback has been not just positive but overwhelming; teachers and secretaries are already asking how to get LibreOffice on their Windows boxen at home…) It is possible to run both in parallel, though.

返信

• 2018/12/04 23:09

A lot of those computers might actually have 64-bit processors, as using 64-bit versions of windows didn't become the norm until windows 7 (although both vista, and to a limited degree xp, had 64-bit versions). If the computer is from after 2005 it is almost certainly 64-bit, but anything after 2003 could be. Of course, you would have to get a 64-bit windows OS that is not too heavy for the computers, which might be a problem/ cost money. I assume linux or similar is out of the question with regards to consistency (although you could set up linux to "feel" as similar to windows, as windows xp feels to windows 10).

You should try angling the old XP installs as a security risk (as they are not longer supported) to get your school to upgrade/replace them :-)

返信

• 2018/12/04 23:22

There are still new systems built with 32-bit x86 processors these days.

There are still new 32-bit x86 processors produced these days, at least by Intel (confirmed).

Not to mention nōn-x86 systems (ARM, MIPS, …).

Agreed about old operating systems being a security risk, though. (Not so much for oneself but by being taken over by botnets and abused for sending spam, etc).

返信

• 2018/12/08 07:22

With Qt 5.12 being released now it shows that we can build a working and fully fleged 32bit version of MuseScore 3.0 for Windows.
So far for the good news.
The bad news: this sill won't work on Windows XP.
The worse news is: my attempt to build a 32bit version of MuseScore 3 using the last Qt version that supports Windows XP, Qt 5.7.1, failed miserably, it not just a matter of disabling the odd feature here and there, it would require a lot of fundamental changes, and as such isn't worth the effort. At least I'll give up on it, this is beyond my paygrade ;-)

返信

• 2018/12/08 09:31

You did more than I could ask. Many thanks again.
Anyway, a 32bit version supporting Windows 7 is something that could be useful when all of "our" 32bit XP machines will be dead or upgraded to W7 or more. Should the MuseScore team decide to make that 32bit version available, it would be a valuable opportunity for my pupils.

返信

• 2018/12/04 22:54

No, we have it working with Qt 5.11 on amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x, hppa, hurd-i386, powerpc, ppc64, sh4. We’re not bound to only support what Qt upstream does.

We also have MuseScore 2.3 with Qt 5.10 or so for alpha, m68k, powerpcspe, riscv64, x32. MuseScore 2.1 with an older Qt for kfreebsd-amd64, kfreebsd-i386, sparc64. Only IA64 is still on MuseScore 1.2 but that architecture was long dead and is about to be revived.

Yes, this means you can run MuseScore 2 on your Atari, Amiga or 68k Macintosh on Linux, given enough RAM (and a lot of patience, as these systems are slow).

These are 32-bit and 64-bit plaforms as well as mixed ones (x32 for example is amd64ilp32). We also used to have an 31-bit platform (s390) but that got removed from Debian by being superceded by s390x (64-bit). So we know about portability.

This does however mean no QtWebEngine (because it uses an unportable ECMAscript engine).

返信

• 2020/02/27 09:10

On armhf we are still going along with 2.0.3 officially and can get 2.3.2 installed too.
Now we can run Raspbian as a 64bit OS
( Linux rpi464bit 4.19.105-v8+ #1296 SMP PREEMPT Thu Feb 20 16:34:11 GMT 2020 aarch64 GNU/Linux) ,
can we have a musescore 3 64bit AppImage for ARMHF please?
I know ManjaroARM 64 has musecore 3 in their repository as I have tried it,
but I do not know who compiled and packaged it.
I would rather run it on Raspbian as it is designed for the RaspberryPi4,
and runs better than ManjaroARM on the RPi4.
( I use my RPi4 for all my music arranging, transcribing and as my general music workstation ! )
20200227_083815cut.jpg

返信

• 2020/03/04 12:38

We have musescore 2.3.2 and musescore3 3.2.3 in Debian. MuseScore 3 uses a different package name.

musescore 2.3.2 is in
• buster
• stretch-backports
• jessie-backports-sloppy

musescore3 3.2.3 is in
• unstable (sid)
• testing (bullseye)
• buster-backports
• stretch-backports-sloppy ⚠ without plugin functionality!

This way you can install them both in parallel.

I’ll be working on upgrading from 3.2.3 to something newer when I get the time.

返信

• 2018/12/03 10:24

This update is very nice! I wonder if it could be possible to change the notehead scheme on just one or two notes. I'm thinking for example if there are many ledger lines, it would be nice to have a letter in the notehead.

返信

• 2018/12/03 14:42

If it's literally just a few notes, probably easier to just add noteheads manually using the Symbols palette, same as can be done in 2.3.2. But for the record, the new Staff Type Change element does allow changing notehead scheme from that point forward. For, one staff type change at the beginning of a section, another at the end, if you want all noteheads in that passage affected.

返信

• 2018/12/03 17:11

That is not too bad, they can get updated by every user and are still in flux anyway. Worse is that this "in flux" currently doesn't work, i.e. changed texts in the source don't make it to Transifex (#279242: No development builds for Mac since Nov 27, those builds also upfdate the strings on Transifex). But this is being worked at currently (fixed just now)... (and it doesn't affect this beta anyhow)

返信

• 2018/12/04 13:00

MuseScore 3 is a great program and I love the work you all have put in this great version. But I have to admit, that I have to assist Gootector (despite his inappropriate behavior): This feels not like a Beta version.

From a psychological standpoint it was OK to name this release a Beta: many new people jumped on the train and help testing. But please change your road map and deliver a few Beta version every two week or so until it is not as easy as now to find bugs :-) MuseScore is now complex enough to allow a 8 week or even 12 week Beta phase! (Which means a longer feature freeze, but git has branches ;-) )

If we look on MuseScore as a professional tool, we have to ensure, that the first final version 3.0.0 brings more people to MuseScore, not only due to the wonderful feature set, but also due to it's quality! Don't follow the example of many commercial programs to let the user be the main testers. We have no need to rush a new version to make money to pay the developers or the staff!

返信

• 2018/12/04 13:41

I second this motion. I see no way that this beta can be turned into a usable stable release in 6 days. You may call the release in 6 days the release candidate and a couple of days later change its name to version 3.0 final, but it will be a farce. You may do updates monthly, but at this rate, the first 3.0 release will not be a stable release, but rather the quality of an alpha. The program should get scathing reviews warning the public of the poor quality of this "most bug free" release of MuseScore ever. The only reason I will even consider testing version 3 is the expectation that new releases will happen much more often than previous version. At the current rate, hopefully in 6 months or so, there will be a release that is worthy of being called a stable release.

As I implied, the beta is still far from being usable for daily work. Unless some miracle happens, I will continue using version 2 for my daily work, and continue testing the version 3 releases until a time they become usable for daily work. To me, daily work means working on original compositions in it or transcribing a symphonic piece. The risk of data loss is still too high and I will not risk losing that much work in such a buggy environment.

返信

• 2018/12/04 13:52

There isn't (and to the best of my knowledge never was) a plan to release 3.0 Final just 6 days after this Beta.
There currently is a plan for a Beta 2 at the end of this week though.
And I personally believe there will be am RC also, maybe even an RC2 after that or a Beta 3 before... we'll see :-)

The biggest problem is to get decent test coverage. The Alpha 1 and 2 vesions, (and even more so the development builds) seems to be too hight a hurdle esp. for Windows users, as these don't have an installer (but you need to unpack, drill down to the exe, double click that), at the same time Windows users are the vast majority.

返信

• 2018/12/04 14:39

Under Upcoming events in this announcement Fix all P0 and P1 issues and make MuseScore 3 Release Candidate (target date is December, 10)

Release candidate means this is what has been proposed to be the final and the final should be expected shortly with only previously unnoticed critical bugs being fixed. Anatoly said we can expect the RC on December 10. The info being made public makes it look like a train wreck is in the works.

You are correct that the majority of users are windows and there are different methods for installing nightlies than other programs that is different than the norm. More testing means more bugs being found before release. Announcing the Beta release has been a very good thing. The number of bug reporters has multiplied. As a result we do have to sift through more duplicates, but this is a minor inconvenience if it means a better final release.

I hope what you are saying is correct, because Anatoly has not previously shown much leeway in his timeline. It would be far better to delay the release of 3.0 that to release a poor quality 3.0. Everyone wants more MuseScore users and a bad experience in a "stable" release would scare away many of those who don't know what a fine program this really is.

返信

• 2018/12/04 15:00

Do you know more critical bugs that may lead to crash or data loss besides the ones with P0 priority? Please, file everything to let us know the real state of the editor.

Regarding the quality. It is very personal and subjective thing. Current state is good and suitable for 80% of users (according to leave feedback form). You will be happy with the quality in half a year. A lot of people still use Sibelius, because they don't have enough features in MuseScore. So, my question is whom do we serve? We serve musicians so we want to share great product with them to improve it continuously.

Btw, 2.3.2 will be available as usual on downloading page as well as supported on musescore.com.

Pthvogt, I'll answer a bit later, sorry.

返信

• 2018/12/04 15:34

If the quality is poor in the version 3.0 release, those Sebelius users you want to attract will try version 3 and decide it's better to keep paying for Sebelius. Some may look at MuseScore again later others will consider it a broken toy that's not worth their time and never look at it again. You don't want to alienate those users. Dropping features from the initial release to make it have fewer bugs is not the answer. Drop features? Yes, it seems plugins will not be part of version 3.0, but will be fixed at some point in the future. This isn't the only feature being dropped that was in version 2, but I can't think of others right now. Lowering priority to make it look better isn't the answer either. I've noticed that you changed some P-1 bugs to lower priorities. BTW, you're the one who put the P-1 on most of them in the first place. At first glance it looks like you're cooking the books. I have't analyzed these changes to see if I agree with them, I'm too busy trying to help you get a quality product out.

I for one, tried MuseScore 1 (probably 1.2 I didn't look) and decided it was such a poor quality program that I ignored it until shortly before version 2.1 came out several years later. I tried my version 1 again and it reported that there was an update - so I updated. Version 2.0.3 was so far superior that I became an ardent MuseScore fan. The only thing I get out of MuseScore is enjoyment. I consider myself an average user who cares about the future of MuseScore. I don't want to see version 3 be a disaster.

返信

• 2018/12/04 15:38

You are right, quality is a subjective thing. But I had not much time for testing and everything I tried (beside adding notes) failed:

  • TempoText + Volta failed
  • Changing the Key signature in the middle of a score failed
  • Implode combined with Written Pitch failed

(For all these problems issues exists, none fixed in Nightly.)

These are all very basic things and 100% of the non trivial things I tried failed... If we are not targeting the absolute beginner, I would declare this version as unusable. We claim MuseScore to be a "Professional music notation software", this means to me: used by professionals.

I am a professional software developer/architect since 1986, and in my experience this is currently far away from being a professional software.

Sorry for being honest!

返信

• 2018/12/04 16:00

I guess I would say if you only tried 3 things and they all failed, then you would indeed be justified in taking a pessimistic view. But I would also observe that this is a very small sample size :-). In my own testing of literally hundreds of different actions, my success rate is far greater. Still plenty of bugs to be fixed, of course, but as I mentioned, the pace is impressive.

返信

• 2018/12/07 11:51

Based on my experience so far, I have the same concern. The program frequently crashes on me (several times a day), and many of these crashes are not reproducible. I am not an experienced user (yet). I am about halfway your excellent online course and learning by the day. Still, I often will try things that an experienced user will not attempt. But does that mean that the program is allowed to crash on me? I would think that especially new users you do not want to scare off.

Unreproduclble crashes, by the way, are much more alarming than reproducible bugs, and difficult to report.

I would venture that you yourself, as an experienced user who also knows the program, are much less likely to walk into an error than a novice or casual user. Especially a not reproducible error, because such errors often are caused by unexpected (but allowed) behaviour.

As to the small sample of 3 problems out of 3 attempts: 3 is indeed a low number. But still sufficient to raise concern. Suppose 1 out of 100 features fails. Then to fail with 3 functions in a row has a probability of about 1 in 1,000,000. This would be an unlucky user indeed. Even if 1 out of 10 fails (much too high for a release I think), you have a chance of only about 1 in 1,000 to hit three errors in a row.

I am full of admiration of what the team has accomplished and is still doing to get the system ready for release, but I do share the concern of many in this thread.

I do hope I am wrong. Thanks for all the good work.

返信

• 2018/12/07 15:54

Crashes are bad indeed, and irreproducible ones are the worst. Luckily, there are tools that can help with that - AddressSanitizer in particular has proved invaluable and caught quite a few crashes for us. Plus, even with vaguely-described conditions in bug reports, we can sometimes do some detective work and solve the problem, and we had some good success stories with that as well. I am very pleased to report that say that with the aid users who have reported what they can, information fro automated tools, and a lot of hard work, the beta to be released today is going to be much less crash-prone. Even as an experienced user doing fewer unexpected things, I too saw plenty of crashes in the first beta. Haven't seen even one (!) lately, aside from the small handful already reported and not yet fixed.

Anyhow, the list of fixes in less than 10 days since the first beta is truly mind-boggling to me; I've never seen anything like it. I'm not saying it's 100% there yet, but I think people will get a better sense of just how fast the progress is, and this might help set expectations a little better.

So again I say, I understand skepticism, but I also see very good reasons for optimism, and I think you will too once you try today's beta update!

返信

• 2018/12/04 15:01

One thing that is probably not apparent is the almost furious pace of activity on the development side lately. We're on a pace of something like 100 bugs fixed per week - I don't know that MuseScore has ever experienced anything quite like that (although it would be kind of interesting to see stats). So, very many of the bugs one might encounter in the beta have actually already been fixed, and given the current pace, very many more will be fixed before the originally announced RC date. Where will that actually put us? I don't know, but I did want to emphasize that the state of the beta itself is not the only data point to go on here.

Another thing to consider is that a good many of the bug reports have to do with the import of 2.x scores. Obviously, beta testers tend to be users of the current version, and they have existing work they want to import, and they will of course find bugs in this area. But it does seem to me that, as different as the layout algorithms are, importing older scores isn't something that is likely to ever be completely automatic, and people will probably keep MuseScore 2 & 3 running in parallel for a while anyhow, using MuseScore 2 for older work and MuseScore 3 for new. This is totally understandable and completely fine. What this really means to me, though, is that much of the user experience with MuseScore 3 going forward will involve the creation of new scores, and the 2.x import issues won't be as much of a concern. FWIW, the same was true going from MuseScore 1.3 to MuseScore 2.0. Imported scores had all sorts of issues, to the point where most people just didn't bother until they were ready to put in some work fixing them up, but people were generally quite happy with the experience of using MuseScore 2.0 for new scores. I think we will see the same here.

Bottom line, between the bug fix rate and the notion that MuseScore 3 will probably be perceived more in terms of how well it does on new scores than on imported ones, I am optimistic. I too share the hope that 3.0 is as high quality as possible, and I personally am doing all that I can to help make that happen. Let's just keep focused on that goal, keep working toward it, and see where the road leads...

返信

• 2018/12/04 15:52

As far as portability is concerned (2.x to 3.0) is concerned, the 3.0 engine shouldn't be breaking the thousands (millions?) of scores loaded onto MuseScore.com in version 2.x. Users should be able to download most of the scores without regard to which version the score was created in. The exception is when ill advised and unnecessary workarounds were used. There should be no expectation that those would work in any later version.

MuseScore.com should be a major concern for 2 reasons. First - it's the main way MuseScore makes money. Second - People download scores and evaluate Musescore based upon how it handles it's own scores. If it can't handle its own scores then why should anyone use it.

I would be very surprised to learn there were anywhere close to as many bugs being fixed just prior to the 2.0 release since there were far fewer people fixing them. The fact that so many bugs are being fixed every week, day, hour or even second does not give me comfort that the version 3 release will be high quality. It just tells me there are that many bugs that need fixed and gives no indication of how many more need to be fixed.

The count of P1 and P0 bugs is really irrelevant as well. How many were reported after the beta release?

返信

• 2018/12/04 15:57

How is it relevant to the qualtity of the end product when a bug got reported (but in the past week there were far more than with the previous Aplha versions and their lack of Windowes cover)? Important and relevant is whether all the big and important bugs are fixed. This it what P0 and P1 is about.
BTW: there not that many more people involved in fixing bugs than in former times. But indeed 2 more full-timers.

返信

• 2018/12/04 16:09

The point about musescore.com is a good one - even new users will be likely to be trying to load 2.x scores into MuseScore 3. I'm not saying it isn't important to fix those issues. Just that only looking at that side of it does give a somewhat misleading impression of what the experience will be like creating new scores. And again, dozens of issues have been fixed since beta, dozens more will surely be fixed before release. While you are right that this in itself doesn't tell us how many bugs there are left to be fixed, as someone who was also quite active during the MsueScore 2 development and the beta phase there, I do have some perspective here. My sense is that the quality of the MuseScore 3 beta is already better than that of the initial MuseScore 2 beta (anyone who doubts that is welcome to try finding and downloading the initial MuseScore 2 beta for themselves!), and bugs are both being found and being fixed at a far faster rate. This is nothing but good news.
Rather than speculate about where this will end up, I'd rather focus on continuing the work.

返信

• 2018/12/04 20:19

"My sense is that the quality of the MuseScore 3 beta is already better than that of the initial MuseScore 2 beta."

I agree with this. It is also still less than that of the second MuseScore 2 beta, and there were still months of work needed between that second beta and the release.

Jumping from first beta to release candidate in two weeks is irresponsible, especially with a major version that has a thoroughly rewritten codebase, meaning that all the refinement and user testing of 2.0 is useless for evaluating 3.0's quality.

返信

• 2018/12/04 22:38

Indeed, while the first beta of MuseScore 3 was more solid than the first beta of MuseScore 2, it was less solid than the second beta of MuseScore 2. But I would say that with less than a week of work (!), current development builds are now about as solid as that second beta. In other words, in one week there has been as much progress as what took several months for MuseScore 3. That's nothing short of phenomenal, and if that progress continues, then it would not be unreasonable to hope for a MuseScore 3 RC that is at least as solid as the MuseScore 2 RC.

Meanwhile, a good point was raised that seeing so much development just before release is a cause for some concern, as there are often some regressions. Hopefully most of these will be caught during the period between RC and actual release.

But it's also important to realize that the whole release model of software is evolving. Mobile apps have shown that it doesn't have to be about big monolithic releases, that it is possible to adopt a more nimble release cycle with regular (monthly, even weekly for some apps) point releases. Early adopters may install brand new major updates right away, and they are typically the ones most willing to submit bug reports. By the time more conservative users install a major release, there may well be an update point available.

All of this is to say, the world is changing, and judging current software releases by the standards of those from years ago doesn't necessarily make sense.

Again, I too want to see MuseScore 3 be as successful as possible. That's why I've spent most of today investigating and fixing bugs. producing documentation, and otherwise working toward that goal. Time to get back to it :-)

返信

• 2018/12/04 16:22

I don't want to take away your enthusiasm, but a high number of fixes is not a good, but a bad sign for a software near to the release date. Each fix is a potential new bug, so we have 100 possibilities for new bugs each week. If this would be a commercial software and I would be the project manager, I would not sleep very good...

返信

• 2019/02/07 11:03

So true, alas. I wish it were different.

It is now 2 months later. I personally are giving up on reporting bugs in 3.0.2 I have prepared a number of bug reports in the past, up to a day or so ago. Preparing them takes a lot of care and time. It is very disheartening to do so if every time I have reported a bug, the next one shows up in this, a "stable" product. Such a product I want to help make perfect, not to help making ready for prime time.

Nowadays I have every 20 minutes or so an issue. Some of them are cosmetic and "only" require some manual intervention to fix, some of them make the program behave so erratically that I have to close and restart it. Some of them cause crashes without any clue why, not reproducible in a way that I can detect. Old issues that are supposedly fixed show up again in a different context.

If I were a developer or beta tester, no problem. This is what I would expect and I would gladly help out. But I am a user.

I know that this is a free program. It has fantastic features. I really want to love it. But it honestly should be labeled somewhere between alpha and beta, even now. The vast majority of functions work fine, but that is not enough. I do hope this state of affairs will not turn too many prospective users away and back to Sibelius, Finale, etc. and lose them for a long time.

So, sorry, but no more bug reports from me for the time being.

Please do not consider this a negative comment on all the work done by many dedicated people, usually in their own time. Thank you for all your efforts. My issue is with a rushed release, not with all your fine work.

返信

• 2019/02/09 06:27

You don't have to spend so much time reporting an issue. When you notice that something is wrong, report it in the forum support, by attaching the score and saying where it is happening. If you don't understand exactly, it doesn't matter, we can detect it. But we need a score (not images) for checking, that's really the most important thing, and don't worry about writing the bug report.

返信

• 2019/02/16 16:21

Thanks for that. I decided to resume logging issues. In fact, I did report one yesterday.

It was probably well intended, but I got a reaction (not from you) asking me to do all kinds of further investigation. Will not do, as per your suggestion.

Kind regards.

返信

• 2019/02/09 14:14

Hi Jeroen

I understand your frustration. I decided to spend my time helping where I can. Since I cannot code, logging Issues is one of the ways I can contribute and show my gratitude towards the project. Even if an issue is not picked up immediately, it can serve as the anchor that other forum posts can be tied back to until (hopefully) the issue has enough momentum to be fixed. There are definitely frustrating times. If your Issue does not catch the eye of a developer, it may never get fixed. Worse, whoever responds to your issue on issue tracker, completely denies there being an issue. And I don't know how to resolve that since you cannot escalate or complain in the conventional sense that you might with a commercial program that you paid for. Despite that, I feel privileged to be part of the effort, and could not see myself going back to being a regular user, just waiting for the fixes and features to roll in.

For a project with limited resources (handful of full-time programmers and many volunteers), those of us that see their way open to log issues, answer forum queries, end up being part of the development cycle. It is just one of the unintended consequences of the non-commercial open source business model.

返信

• 2018/12/04 17:14

After rereading all responses to my comment, I think the overall tone is not what I intended.

I think the current state of the development of MuseScore is fantastic and the great numbers of contributors and testers will bring MuseScore to a new level and in the next league of Open Source programs.

The only thing I want to say: Please take the time it needs.

返信

• 2018/12/04 17:15

I haven't been able to test MuseScore 3 beta yet because of two major crashes (I have reported them and they have been marked as P0) which make it impossible for me to use the programme. I'm sure there are a few other people out there who might have passed on the first beta due to similar showstoppers so I would expect more testing and more bug reports once the beta gets more stable.

Bottom line: It's not my intention to spread negativity but putting out a release candidate on 10 December seems unrealistic.

That being said, I am hugely enthusiastic about the speed of development and the large amount of dedicated contributors. I've become more and more interested in helping out a little. :-)

返信

• 2018/12/04 17:18

It is not my intention to spread negativity either. I realize I started this long conversation and added to it afterward. My intention is to see MuseScore be a good program and not scare away future users by pushing a release out too quickly for the sake of meeting a deadline.

返信

• 2018/12/04 18:48

(despite his inappropriate behavior) - so... where is this "inappropriate behavior"? Comments are deleted. I see the next user sponsored by MuseScore Team 😉 Jojo&Company comments are "appropriate", my - are not. These very long comments - covering inconvenient content? This propaganda exercise... No comment 😂 "Love music. Love MuseScore." "Love MusIc." - OK, I understand, but "Love MuseScore."? This "love" is the next level of self-love? ☹

返信

• 2018/12/05 19:30

With my many years in IT, one thing that was always in focus for a software project, is that the final product must meet the specifation.
In the case og MuseScore the specifation seems only to bee in the head of the developers, and has never been made public. Without this, it is impossible to make a qualified test, to confirm that the beta actually works 'as designed'.
This had been duscussed before
https://musescore.org/en/node/277968 but so far without any resulting action.

Also duscussed was the need to update the Handbook. In my opinion it does not make sense to release the new version before there is and updated Handbook to go with it.
The Handbook may be a ' community effort', but to the 'normal' user of MS that is irrelevant. An outdated or downright wrong Handbook will not improve the perceived quality of the product.
Edit:
See also
https://musescore.org/en/node/277749

返信

• 2018/12/06 01:07

I would say that the idea of a formal "specification" for a release makes sense in the corporate world, but it's seldom the case with open source software :-)

Getting the Handbook into shape would be good indeed, though. No reason that work can't be happening now, and I expect it will get more fully into gear as we hit the RC.

返信

• 2018/12/06 10:53

(This comment references a deleted comment of Gootector, which seemed to criticise the payment of some of the developers. Even if the comment was deleted, I wanted to state my view on this point and therefore I post this comment with dangling reference :-) )

Your point is not clear to me: It is the normal case, that people are paid to implement open-source-software. Open-source means (roughly), that the source code is available to all and that you can take it and make your own thing with this (as long as it is also open source). see The Open Source Definition.

Despite the fact, that "open-source software" and "free software" are not completely the same (Why Open Source misses the point of Free Software), I want to quote Richard Stallmann, the "Inventor" of free software who goes even further in The Free Software Definition:

Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”. We sometimes call it “libre software,” borrowing the French or Spanish word for “free” as in freedom, to show we do not mean the software is gratis.

May be you are annoyed, that other people gain money from your work on MuseScore, but that's the deal. You may have known this before you started to participate.

返信

• 2018/12/06 11:17

I tend to agree with each sentence, but the last. People don't earn money from open source project itself, but they create the ecosystem based on the open source product which earns money. It could be paid support, creating distributives, devops routines, etc. Also, some open source projects/products/services/frameworks help corporations to earn money, that is why corporations pay money to their employees to contribute to the OS projects.

To sum up, OS products don't earn money, but donations, and there are a lot of different ways to earn money AROUND open source products.

返信

• 2018/12/06 11:32

This gets philosophical, but one may look this way (as an example):
1. The translation work of Gootector enables many people in Poland to use MuseScore
2. Some of these people will become Pro members and will pay money to musescore.com
3. Inductive reasoning concludes: due to the work of Gootector musecore.com earns money.

Enough of this, back to work :-)

返信

• 2018/12/06 11:47

While true this not the usual vonlunteers' motivation. Like me, I (amongst other things) did large parts of the German translation, but not because I earn money with it, nor because or even despite other do, but because I want it translated, for me, for my own benefit. Even f I don't need this myself anymore, as I'm meanwhile often more fluent in the English terms than in the German ones ;-), but really I learned a lot by doing this, so still a benefit for me.
The good old OpenSource 'scratch your own itch' principle.

返信

• 2018/12/06 12:31

Ask your employer.

After all that is how it comes that some of the contributors (such as Anatoly) get paid and can contribute full time; His employer (UG) thinks a further developed MuseScore can provide enough added value to their own products/ecosystem. So much that this employer thinks paying his time contributing to this project is worth it.

My employer for example doesn't think so (I'm also in a different industrial branch) but does see the added value of me hanging around in the developers chat to pick up on some Qt stuff, as we do use that. So I don't get paid to contribute, but my employer is lenient towards me learning from this project.

返信

• 2018/12/07 13:05

I’m in the same situation.

We can contribute to the software we use at work, but we’re not in the music business. They are, however, involved with OSS, so I can hang around IRC during work time, and sometimes do small things on the side when idle (or in a break, i.e. not on paid time), and I can use my work computer (with eight vCPU cores) to compile MuseScore instead of doing it on the single-core Atom laptop I have at home.

I’m contributing to scratch my own itches, sometimes others’ too, and because I just like OSS.

I don’t normally even get donations for my own software (mksh being the exception, I think I got a total of 35 €, a five-year SSL-certificate and a custom-made T-Shirt over the last 15 years developing it).

返信

• 2018/12/06 09:40

I revised all P0, P1 issues for 3.0-dev version in the tracker. Right now we have 74 issues to fix which is not so many :)

I was a bit misunderstood when mentioned "Fix all P0, P1 issues in the tracker". P0 was supposed to be used for the issues "must be fixed for Beta update", P1 used for the issues "must be fixed for official release". Now I understand it sounds unclear and a bit ambiguous. So, I decided to keep all issues I see as critical under P0 priority.

Please, look through the list and let me know if some P1 (or not prioritised) issues should be marked with P0 priority as well. So, our target now is to fix all P0 issues and make a Release Candidate. Not target date, but the scope matters.

返信

• 2018/12/20 20:42

Hallo,
It would be nice, if there was a improvment in sound. It would be great if it would be easier to use externel samplers or Instruments. maybe VST.
Until now it is a super tool for me!
Great work!
Greatings Arne

返信

• 2018/12/26 09:47

Many new features but I'm still hoping to get the tremolo bar play back fix. In this version it seems to work visually, with some peculiar behaviour, though. However, without playback it is just a visual sign in the score and has no difference compared to eg the saw tooth line segment.

返信

• 2018/12/26 18:20

Are you saying that my wish for playback for tremolo bar is not justified? If Musescore is only for notation why then developers have spent time on:
-Improved playback controls
-Improved Mixer for easier control of instrument sounds
-Improved Piano Roll for fine control of individual notes
-Improved Play Panel for faster access to playback controls

This looks like someone has started to develop the tremolo bar and playback for it but has given up or forgotten to finish it. With all respect to the voluteering developers, I'm only proposing that this would be completed one day.

返信

まだ解決していない質問がありますか？ 質問を投稿するにはまずログインしてください。