MuseScore

Part 3 of 3 MuseScore 3.0, currently under development, is on track to be smarter, faster, and easier than any MuseScore you’ve seen before. We’ve previously discussed the first two of those areas of improvement for the next major version of the ... [More] world’s most popular, powerful, and easy-to-use free and open-source scorewriter. This May, we started by introducing you to the ongoing Smart Layout project, working towards making MuseScore 3 smart enough to automatically offset overlapping elements and avoid collisions. In June, we gave you a preview of the speed difference, as we revamp MuseScore’s layout algorithms so score editing is just as fast no matter how big your score is. In this post, we’ll take a look at how the work is going on the last of our three overarching goals: making working with MuseScore 3 easier in various ways. This is, of course, really the ultimate goal of all of the above; the motivation for making MuseScore smarter and faster is to make it easier to work with. When MuseScore is smarter, you won’t have to spend time manually fixing collisions. When MuseScore is faster, well, it will be faster—the advantage is self-evident. So we’ll start with an update on how those efforts are progressing. Smarter The Smart Layout initiative is still a work in progress, but moving fast, as Werner Schweer (the father of MuseScore) implements “smart” handling of one type of element after another. As an example of this gradual refinement, as of July 1st, ottavas (octave lines) are intelligent, and will automatically move up or down as notes, articulations, or dynamics get too close—but for pedal lines, the same hasn’t been implemented yet. With the similarities between pedal lines and ottavas, though, you can bet it will be soon. Faster Most edits are now processed very quickly, independent of score size and number of parts, but some editing functions, including note input, still use the same process as in MuseScore 2, and are still slow in large scores. Resolving this is on the agenda. Easier A whole host of new features and improvements on the side have already been added, or are planned—many of which are specifically aimed at making various stages of the MuseScore workflow easier. Here, in no particular order, are what may be the top ten to look forward to. Real-time MIDI input: This is one major new feature coming along in this area that you may have already heard of. Peter “shoogle” Jonas is working on it over the summer. While interpreting the input accurately is necessarily a challenge to implement (particularly because a human player might not be able to play the rhythm with mathematical precision), this has the potential to save you significant time on note input. Swap Clipboard and Selection: A way to to trade two selections—e.g., exchange the contents of two staves for a time, or change the order of two measures—was first requested in 2012. Four years later, the ideal solution turned out to be one that’s gradually becoming more common, and Jon Enquist joined the community as a first-time contributor with his solution. (This is one that you may get enjoy sooner, in MuseScore 2.0.4.) Custom toolbars: MuseScore 2 allows you to customize palettes, and create different workspaces with different sets of palettes. You can also choose to show and hide various toolbars and drag them around, but the content of each toolbar is locked. In MuseScore 3, thanks to Werner, toolbars will be fully customizable and able to change with workspaces, with preset Basic and Advanced options. So far only the Note Input toolbar is under control, but the framework is there. PDF Copying Assistant: In addition to the experimental online PDF-to-MSCZ converter, MuseScore 3 will be able to recognize the basic structure in a PDF (systems, barlines, line breaks), provide a blank score matching those specifications, and synchronize it visually with the PDF, making it easy to transcribe what you see on the right into the empty measure on the left. Work on this actually began some years ago, but was cancelled before MuseScore 2.0—now new contributor Liang Chen has rebooted the effort. See how it works in this video. Temporary/Cutaway staves: Mentioned in a previous blog post, this falls under the “easier” umbrella of MuseScore 3. This will make it easy to temporarily add another staff to an instrument, or create a one-measure ossia above a staff. Implemented by your friend and mine, Marc Sabatella. System dividers: If you ever wanted to put “//” on the side between systems in MuseScore 2, you had to manually add each one from the Symbols palette and position it by hand. In MuseScore 3, just switch on a style option, and there you are. Marc Sabatella did this as well. Complete shadow notes: When entering notes with the mouse, MuseScore 2 displays a shadow notehead to help you place the note on the staff, but it doesn’t show you the rest of the note. In MuseScore 3, the shadow note is complete with appropriate stem, flag(s), and dot(s), letting you know exactly what you’re about to enter. The first contribution from 19JoHo66. Metric modulation: When you have a time signature change and want the same beat to carry through, that’s commonly notated as something like ♪ = ♩. It’s not easy to create that kind of tempo change in MuseScore 2. In MuseScore 3, metric modulations will be as easy to add as any other tempo, thanks to this summer's synthesizer wizard Johannes "hpfmn" Wegener. New templates for band and percussion: In 2.0.3, the only template under the Band category is Concert Band. In MuseScore 3 (and probably even in 2.0.4), under Band and Percussion, there will be Concert Band, Brass Band, Marching Band, Battery Percussion, Small Pit Percussion, and Large Pit Percussion. Courtesy of variously first-time contributor Henk De Groot, first-time contributor Chris J. “duck57" Matlak, and yours truly, Isaac Weiss. Simpler menus: A few months ago, LibreOffice (an incalculably larger open-source software project) put some effort into making their user interface simpler to navigate, with some thoughtful reorganization of the application menus in LibreOffice 5.1. I took it upon myself to do something similar for MuseScore 3, and I’m very happy with the results. This is a sure guarantee that we’ll get a couple hundred million users, too. Bonus! This was going to be a top ten list, but here's a last-minute addition. Formerly, when you changed MuseScore's language, it was necessary to restart MuseScore to fully translate the interface. Not anymore. Core team member Nicolas "lasconic" Froment committed this change literally one hour ago. Notice how many of these improvements came from first-time contributors—musician/programmers answering the call to help develop MuseScore 3, or “scratching their own itch” and sharing the benefits with the community. In an open-source project, that’s not surprising, but it is really nice to see, and worth pointing out. A hearty congratulations and thank-you to everyone helping take MuseScore to the next level! You can help, too! Please test the latest features in the nightly builds, and report the problems you encounter. Your feedback is very welcome in the Technology Preview forum, and precise bug reports can be directly posted in the Issue tracker. If you’re a programmer as well as a musician, we would appreciate your help fixing those bugs—as MuseScore is free and open source, anyone can get the source and share code contributions on GitHub. Don't forget that you can also support the future of MuseScore with a donation. So, there you have it. The MuseScore of tomorrow is being sketched out today. I, for one, can hardly wait. [Less]

Part 2 of 3 MuseScore 3.0 is currently under development, getting ready to be smarter, faster, and easier than any previous version of the world’s most popular, powerful, and easy-to-use free and open-source scorewriter. In last month's blog post, we ... [More] outlined our development goals regarding the first of those three main areas of improvement, which we’re calling Smart Layout. Now, here’s an update on of the other two main points: how much faster the next major version of MuseScore is going to be. In all versions of MuseScore so far, every time any edit is made, the positions of everything in the entire score from beginning to end are recalculated in a process called relayout. You’d never notice it when working with a relatively small score, but a few dozen pages, and the delay after every edit starts to become appreciable. The problem compounds itself rapidly if you add linked parts, as the edit then has to be reflected through each part; and it’s much worse if you have the Navigator open, as that’s basically a whole other score view. In general, the larger and more complex your score, the more likely this complete relayout with every edit is going to start making MuseScore slow. As with the problem of score elements overlapping each other that we discussed last time, this has come up again and again on the forums. The problem is real for any large project, and the MuseScore team has made it a priority for the development of MuseScore 3. MuseScore 3 will be just as fast no matter how big your score is. Only the page on which the change was made will be recalculated, while the rest of the score, which can safely be assumed to be the same, will not be involved in the relayout. (If a change on one page results in the page breaking in a different place—i.e., also changing adjacent pages—then any affected pages will be laid out again, as well, but no more than necessary.) While linked parts and the Navigator will still slow things down, the relayout time for most edits will be entirely independent of the score size. The difference in speed is staggering. Here’s a taste of how good it is: Test Moving the first note in Bach’s Goldberg Variations (990 measures, 58 pages) Windows 8.1, Core i7-3630QM, 2.4GHz., 16GB RAM Result MuseScore 2.0.3 (compiled with Qt 5.4.2):     220 milliseconds (complete relayout) MuseScore 3.0-dev (compiled with Qt 5.6):     1.5 milliseconds (single page relayout) As the Goldberg Variations score is so large, that tiny edit comes with nearly a quarter-second delay in the latest released version of MuseScore. But the 3.0 development version already handles it more than a hundred times faster. That’s virtually instantaneous response time. There are great things coming down the pipe. Again, as stated in the last post, MuseScore 3 is not anywhere close to ready. However, the very haziest outlines of what MuseScore 3 will be like are available for testing in the nightly builds. There is no guarantee anything will work. Let Werner Schweer warn you:   “It crashes very often currently, and does other bad things.” So let’s fix that! You can help us develop MuseScore 3.0 by testing the latest features in the nightly builds, and reporting the problems you encounter. Your feedback is very welcome in the Technology Preview forum, and precise bug reports can be directly posted in the Issue tracker. If you’re a programmer as well as a musician, we would appreciate your help fixing the bugs—as MuseScore is free and open source, anyone can get the source and share code contributions on GitHub. You can also support the MuseScore 3 effort in the simplest way with a donation. So, now you know that we’re making MuseScore (1) handle overlapping score elements intelligently, and (2) process edits lightning fast. Next time: MuseScore gets even easier [Less]

Part 2 of 3 MuseScore 3.0 is currently under development, getting ready to be smarter, faster, and easier than any previous version of the world’s most popular, powerful, and easy-to-use free and open-source scorewriter. In last month's blog post, we ... [More] outlined our development goals regarding the first of those three main areas of improvement, which we’re calling Smart Layout. Now, here’s an update on one of the other two main points: how much faster the next major version of MuseScore is going to be. In all versions of MuseScore so far, every time any edit is made, the positions of everything in the entire score from beginning to end are recalculated in a process called relayout. You’d never notice it when working with a relatively small score, but a few dozen pages, and the delay after every edit starts to become appreciable. The problem compounds itself rapidly if you add linked parts, as the edit then has to be reflected through each part; and it’s much worse if you have the Navigator open, as that’s basically a whole other score view. In general, the larger and more complex your score, the more likely this complete relayout with every edit is going to start making MuseScore slow. As with the problem of score elements overlapping each other that we discussed last time, this has come up again and again on the forums. The problem is real for any large project, and the MuseScore team has made it a priority for the development of MuseScore 3. MuseScore 3 will be just as fast no matter how big your score is. Only the page on which the change was made will be recalculated, while the rest of the score, which can safely be assumed to be the same, will not be involved in the relayout. (If a change on one page results in the page breaking in a different place—i.e., also changing adjacent pages—then any affected pages will be laid out again, as well, but no more than necessary.) While linked parts and the Navigator will still slow things down, the relayout time for most edits will be entirely independent of the score size. The difference in speed is staggering. Here’s a taste of how good it is: Test Moving the first note in Bach’s Goldberg Variations (990 measures, 58 pages) Windows 8.1, Core i7-3630QM, 2.4GHz., 16GB RAM Result MuseScore 2.0.3 (compiled with Qt 5.4.2):     220 milliseconds (complete relayout) MuseScore 3.0-dev (compiled with Qt 5.6):     1.5 milliseconds (single page relayout) As the Goldberg Variations score is so large, that tiny edit comes with nearly a quarter-second delay in the latest released version of MuseScore. But the 3.0 development version already handles it more than a hundred times faster. That’s virtually instantaneous response time. There are great things coming down the pipe. Again, as stated in the last post, MuseScore 3 is not anywhere close to ready. However, the very haziest outlines of what MuseScore 3 will be like are available for testing in the nightly builds. There is no guarantee anything will work. Let Werner Schweer warn you:   “It crashes very often currently, and does other bad things.” So let’s fix that! You can help us develop MuseScore 3.0 by testing the latest features in the nightly builds, and reporting the problems you encounter. Your feedback is very welcome in the Technology Preview forum, and precise bug reports can be directly posted in the Issue tracker. If you’re a programmer as well as a musician, we would appreciate your help fixing the bugs—as MuseScore is free and open source, anyone can get the source and share code contributions on GitHub. You can also support the MuseScore 3 effort in the simplest way with a donation. So, now you know that we’re making MuseScore (1) handle overlapping score elements intelligently, and (2) process edits lightning fast. Next time: MuseScore gets even easier [Less]

MuseScore gets smart. It’s just one of the main improvements we are working on for the next MuseScore. Follow the development of MuseScore 3.

MuseScore gets smart. It’s just one of the main improvements we are working on for the next MuseScore. Follow the development of MuseScore 3.

Part 1 of 3 For all that MuseScore 1 was a decent entry-level scorewriter, it wasn’t until 2.0 that MuseScore really started to compete with the biggest names in the industry—astounding coming from a free and open-source project that no one had ever ... [More] heard of five years earlier. It took a few years longer than anticipated, but when MuseScore 2 arrived it was simply massive. Since then, from March 2015’s release of MuseScore 2.0 through April 2016’s release of MuseScore 2.0.3, some major changes and improvements have been made (among them playback of trills, ornaments, and glissandi, a more platform-independent rendering system, and a significant new notation element that didn’t exist before). But all of those changes have been in patch updates to 2.0. You can imagine how significant, and how far off, MuseScore 3.0 must be. I’d like to be clear: The features we're going to discuss in this post are not, by any means, “coming soon.” This is a work in progress, and that is likely to be the case for quite some time to come. But work on MuseScore 3.0 has begun! There hasn’t been such an exciting time since the team first started developing MuseScore 2.0—or maybe even MuseScore 1.0. So, it is my pleasure to let you know what’s going on behind the scenes. This is the first in a series of posts over the coming months, tracking development as it happens. Broadly speaking, the vision is to make MuseScore smarter, faster, and easier to use. Of these, the smarter aspect is probably the most interesting, as well as the most complex to implement. In future posts, we’ll look at the faster and easier improvements; for now, let’s dig into smarter and see what it means for the future of MuseScore. One of the more important changes introduced in MuseScore 2 was a set of improvements to the note/accidental layout algorithms. Basically, it was all too common for MuseScore 1 to position notes from multiple voices halfway overlapping each other, and accidentals were often in the wrong order, leading either to bad sheet music or a regrettable amount of manual adjustments. MuseScore 2 delivered an outstandingly improved system, with default positioning adhering to the highest standards in engraving, and manual adjustments to notes and accidentals essentially never called for. Now, the next level is everything else. Introducing: Smart Layout. How often do you have to drag a tempo marking off the rehearsal mark it was overlapping? Or reshape a slur to avoid crossing through the notes in its midst? Or use a staff spacer to make room for some high notes? The frequency of problems of this sort is undoubtedly MuseScore’s biggest limitation currently, and it’s come up again and again. With the new layout system, MuseScore will be smart enough to automatically avoid these sorts of collisions (though not all of the specific examples mentioned above are solved yet). Below you can watch Smart Layout in action: That’s not even all. While the current layout algorithms unnecessarily prevent notes and accidentals from overlapping the same linear space (based on a theoretical boundary rectangle the height of the system surrounding each element), the Smart Layout system will allow them to nestle under or over each other as needed (based on a boundary the exact shape of each element), for a more condensed and evenly spaced layout. Like this: And that is only the beginning of what's going to be coming in MuseScore 3. As I hope I made clear at the outset, this set of improvements is not anywhere close to ready. However, the very haziest outlines of what MuseScore 3 will be like are available for testing in the nightly builds. There is no guarantee anything will work. Let Werner Schweer warn you:   “It crashes very often currently, and does other bad things.” So let’s fix that! You can help us develop MuseScore 3.0 by testing the latest features in the nightly builds, and reporting the problems you encounter. Your feedback is very welcome in the Technology Preview forum, and precise bug reports can be directly posted in the Issue tracker. If you’re a programmer as well as a musician, we would appreciate your help fixing the bugs—as MuseScore is free and open source, anyone can get the source and share code contributions on GitHub. You can also support the MuseScore 3 effort in the simplest way with a donation. Next time MuseScore gets faster [Less]

Part 1 of 3 For all that MuseScore 1 was a decent entry-level scorewriter, it wasn’t until 2.0 that MuseScore really started to compete with the biggest names in the industry—astounding coming from a free and open-source project that no one had ever ... [More] heard of five years earlier. It took a few years longer than anticipated, but when MuseScore 2 arrived it was simply massive. Since then, from March 2015’s release of MuseScore 2.0 through April 2016’s release of MuseScore 2.0.3, some major changes and improvements have been made (among them playback of trills, ornaments, and glissandi, a more platform-independent rendering system, and a significant new notation element that didn’t exist before). But all of those changes have been in patch updates to 2.0. You can imagine how significant, and how far off, MuseScore 3.0 must be. I’d like to be clear: The features we're going to discuss in this post are not, by any means, “coming soon.” This is a work in progress, and that is likely to be the case for quite some time to come. But work on MuseScore 3.0 has begun! There hasn’t been such an exciting time since the team first started developing MuseScore 2.0—or maybe even MuseScore 1.0. So, it is my pleasure to let you know what’s going on behind the scenes. This is the first in a series of posts over the coming months, tracking development as it happens. Broadly speaking, the vision is to make MuseScore smarter, faster, and easier to use. Of these, the smarter aspect is probably the most interesting, as well as the most complex to implement. In future posts, we’ll look at the faster and easier improvements; for now, let’s dig into smarter and see what it means for the future of MuseScore. One of the more important changes introduced in MuseScore 2 was a set of improvements to the note/accidental layout algorithms. Basically, it was all too common for MuseScore 1 to position notes from multiple voices halfway overlapping each other, and accidentals were often in the wrong order, leading either to bad sheet music or a regrettable amount of manual adjustments. MuseScore 2 delivered an outstandingly improved system, with default positioning adhering to the highest standards in engraving, and manual adjustments to notes and accidentals essentially never called for. Now, the next level is everything else. Introducing: Smart Layout. How often do you have to drag a tempo marking off the rehearsal mark it was overlapping? Or reshape a slur to avoid crossing through the notes in its midst? Or use a staff spacer to make room for some high notes? The frequency of problems of this sort is undoubtedly MuseScore’s biggest limitation currently, and it’s come up again and again. With the new layout system, MuseScore will be smart enough to automatically avoid these sorts of collisions (though not all of the specific examples mentioned above are solved yet). Below you can watch Smart Layout in action: That’s not even all. While the current layout algorithms unnecessarily prevent notes and accidentals from overlapping the same linear space (based on a theoretical boundary rectangle the height of the system surrounding each element), the Smart Layout system will allow them to nestle under or over each other as needed (based on a boundary the exact shape of each element), for a more condensed and evenly spaced layout. Like this: And that is only the beginning of what's going to be coming in MuseScore 3. As I hope I made clear at the outset, this set of improvements is not anywhere close to ready. However, the very haziest outlines of what MuseScore 3 will be like are available for testing in the nightly builds. There is no guarantee anything will work. Let Werner Schweer warn you:   “It crashes very often currently, and does other bad things.” So let’s fix that! You can help us develop MuseScore 3.0 by testing the latest features in the nightly builds, and reporting the problems you encounter. Your feedback is very welcome in the Technology Preview forum, and precise bug reports can be directly posted in the Issue tracker. If you’re a programmer as well as a musician, we would appreciate your help fixing the bugs—as MuseScore is free and open source, anyone can get the source and share code contributions on GitHub. You can also support the MuseScore 3 effort in the simplest way with a donation. Next time MuseScore gets faster [Less]

Part 1 of 3 For all that MuseScore 1 was a decent entry-level scorewriter, it wasn’t until 2.0 that MuseScore really started to compete with the biggest names in the industry—astounding coming from a free and open-source project that no one had ever ... [More] heard of five years earlier. It took a few years longer than anticipated, but when MuseScore 2 arrived it was simply massive. Since then, from March 2015’s release of MuseScore 2.0 through April 2016’s release of MuseScore 2.0.3, some major changes and improvements have been made (among them playback of trills, ornaments, and glissandi, a more platform-independent rendering system, and a significant new notation element that didn’t exist before). But all of those changes have been in patch updates to 2.0. You can imagine how significant, and how far off, MuseScore 3.0 must be. I’d like to be clear: The features we're going to discuss in this post are not, by any means, “coming soon.” This is a work in progress, and that is likely to be the case for quite some time to come. But work on MuseScore 3.0 has begun! There hasn’t been such an exciting time since the team first started developing MuseScore 2.0—or maybe even MuseScore 1.0. So, it is my pleasure to let you know what’s going on behind the scenes. This is the first in a series of posts over the coming months, tracking development as it happens. Broadly speaking, the vision is to make MuseScore smarter, faster, and easier to use. Of these, the smarter aspect is probably the most interesting, as well as the most complex to implement. In future posts, we’ll look at the faster and easier improvements; for now, let’s dig into smarter and see what it means for the future of MuseScore. One of the more important changes introduced in MuseScore 2 was a set of improvements to the note/accidental layout algorithms. Basically, it was all too common for MuseScore 1 to position notes from multiple voices halfway overlapping each other, and accidentals were often in the wrong order, leading either to bad sheet music or a regrettable amount of manual adjustments. MuseScore 2 delivered an outstandingly improved system, with default positioning adhering to the highest standards in engraving, and manual adjustments to notes and accidentals essentially never called for. Now, the next level is everything else. Introducing: Smart Layout. How often do you have to drag a tempo marking off the rehearsal mark it was overlapping? Or reshape a slur to avoid crossing through the notes in its midst? Or use a staff spacer to make room for some high notes? The frequency of problems of this sort is undoubtedly MuseScore’s biggest limitation currently, and it’s come up again and again. With the new layout system, MuseScore will be smart enough to automatically avoid these sorts of collisions (though not all of the specific examples mentioned above are solved yet). Below you can watch Smart Layout in action: That’s not even all. While the current layout algorithms unnecessarily prevent notes and accidentals from overlapping the same linear space (based on a theoretical boundary rectangle the height of the system surrounding each element), the Smart Layout system will allow them to nestle under or over each other as needed (based on a boundary the exact shape of each element), for a more condensed and evenly spaced layout. Like this: And that is only the beginning of what's going to be coming in MuseScore 3. As I hope I made clear at the outset, this set of improvements is not anywhere close to ready. However, the very haziest outlines of what MuseScore 3 will be like are available for testing in the nightly builds. There is no guarantee anything will work. Let Werner Schweer warn you:   “It crashes very often currently, and does other bad things.” So let’s fix that! You can help us develop MuseScore 3.0 by testing the latest features in the nightly builds, and reporting the problems you encounter. Your feedback is very welcome in the Technology Preview forum, and precise bug reports can be directly posted in the Issue tracker. If you’re a programmer as well as a musician, we would appreciate your help fixing the bugs—as MuseScore is free and open source, anyone can get the source and share code contributions on GitHub. You can also support the MuseScore 3 effort in the simplest way with a donation. Next time MuseScore gets faster [Less]

The list of students selected for Google Summer of Code 2014 has been announced by Google. Among the 1206 students selected, 4 of them will be working on MuseScore this summer! Project: Improving default playback Johannes Wegener (hpfmn) will ... [More] improve the default playback of MuseScore by updating our SF2 synthesizer and improving our new SFZ synthesizer. He will be mentored by Werner Schweer (wschweer). Project: Semi real time MIDI note entry Peter Jonas (shoogle) will implement a new method of entering notes into MuseScore via a computer or MIDI keyboard that is more natural to musicians than the existing “step-time” method. The new method will allow the user to play the piece into to the computer as though they were giving a live performance, but steps are taken to ensure the accuracy of the resulting notation. This would make the process of entering notes significantly faster. He will be mentored by Nicolas Froment (lasconic). Project: Annotations Ruchit Agrawal (shredpub) will add tools to annotate the scores in MuseScore. His mentor is Marc Sabatella. Project: Voice extraction and implode/explode Felix Brauchle (fbrauchle) will extend the existing tools for implode/explode and add the ability to create parts for voices. He will be mentored by Joachim ‘Jojo’ Schmitz (Jojo-Schmitz). Follow the students Now the community bonding period officially starts. Students will get to know their mentors and prepare for the program by reading documentation, hanging out in the developer IRC channel (#musescore on freenode.net), and familiarising themselves with MuseScore. They will also introduce themselves to the community on the forum or on the developer mailing list. For more information on the work undertaken by these students for MuseScore, see our dedicated page (which will be completed by the students in the coming days). [Less]

MuseScore has been selected for the Google Summer of Code 2016, receiving funding to mentor students, and for them improve MuseScore. Read all about the student’s projects.