A lot of information is already available in the GSoC Contributor Guide. Do read it!

If you like to participate to Google Summer of Code with MuseScore, these are the steps you need to follow to apply:

• Help us get to know you.
  If you aren't communicating with us before the application is due, your application will not be accepted.

  • Hang out in our Discord Server. Ask questions, show us that you are motivated and well-prepared. There will be more applicants than we can effectively mentor, so do ask for feedback on your application to increase the strength of your proposal!

• Find something that interests you.
  It's critical that you find a project that excites you. You'll be spending most of the summer working on it (we expect you to treat the SoC as a full-time job).
  Don't just tell us how interested you are, show us that you're willing and able to contribute to MuseScore. You can do that by fixing a bug or submitting a pull request well before the deadline, in addition to regularly interacting with MuseScore developers and users on the forum and Discord Server. Our experience shows us that successful GSoC students demonstrate their interest early and often.

• Prepare your proposal with us.
  By working with us to prepare your proposal, you'll be getting to know us and showing us how you approach problems. The best place for this is in the Discord Server.

• Complete your application.
  Fill out our application template.
  Only the organization admin and the possible mentors will see this data. You can still edit it after submitting until the deadline!

Things you'll be expected to know or quickly learn

MuseScore is mostly written in C++ and use the Qt SDK. In addition to being familiar with C++, successful applicants will be familiar with or able to quickly learn about MuseScore's infrastructure. You can't spend the whole summer learning how to build MuseScore or prepare a changeset and still successfully complete your project.

• The build system. CMake is used to build MuseScore.
  While you generally don't need to understand too much unless you actually want to change how MuseScore is built, you should be able to understand enough to get a general idea of how to build MuseScore. You must demonstrate that you are able to build the development version of MuseScore from sources before the application deadline. Steps to compile MuseScore are available in the developer handbook.

• The version control system. We use git and GitHub.
  Git is the distributed version control system (DVCS) we use for managing our source code. You should have some basic understanding of how a DVCS works.

• The procedure for contributing changes.
  You will be expected to follow the same procedures as other contributors. You will be helping current and future MuseScore developers by using our standard style for changes, commit messages, and so on.

• The Developer Group Chat.
  https://musescore.org/en/handbook/developers-handbook/references/develo…
  It's very helpful for new contributors (you) to get immediate feedback on ideas and code.
  Unless your primary mentor has a strong preference for some other method of communication, the Developer Group Chat will likely be your primary means of communicating with your mentor and MuseScore developers.

• Progress blog.
  If you're selected for the program, you'll be expected to write up progress reports on your own musescore blog. Request activation in the Developer Group Chat. Once activated, you can add a new blog post using https://musescore.org/en/node/add/blog .

• Related skills.
  In addition, you probably should know some things about music and music notation and be able to read simple music. It's not mandatory and we already had successful students who couldn't but MuseScore is a tool for musicians, most of the developers are musicians too. Also music notation has a specific vocabulary that you should know or learn quickly (staff, stem, chord, beam, slur etc...)

Criteria by which applications are judged

These might vary somewhat depending on the mentors and coordinators for a particular Google Summer of Code, but typically the main factors considered would be:

• Applicant has demonstrated an ability to make substantial modifications to MuseScore.
  The most important thing is that you've contributed some interesting code samples to judge you by.

• Applicant shows understanding of topic.
  Your application should make it clear that you're reasonably well versed in the subject area and that you researched it before your application and won't need all summer just to read up on it.

• Applicant shows understanding of and interest in MuseScore development.
  The best evidence for this is previous contributions and interactions.

• Well thought out, adequately detailed, realistic project plan.
  "I'm good at this, so trust me" isn't enough. You should describe which steps you'll take to implement the feature and how you'll integrate with existing MuseScore code. You should also prepare a full timeline and goals for the midterm and final evaluations.

GSoC 2025

Please note, MuseScore is not taking part in GSoC 2025. Our team is currently busy making large structural improvements to MuseScore's engraving and percussion engines, as well as assisting with Audacity's re-platforming from wxWidgets to Qt, which involves integrating MuseScore's UI components. As such, we feel that we don't have sufficient capacity to mentor any student projects this year.

We've made no decision yet about future years, but we encourage potential GSoC contributors to consider applying to other open source organizations this year. Any coding experience is good experience!

Please read the "Writing a proposal" chapter from the GSoC Contributor Guide. The full guide is a must read if you want to apply.

If you would like to get feedback before the deadline:

1. Write your draft proposal in Google Docs.
2. Set the sharing permissions to "Anyone with the link can comment" and copy the link.
3. Check you can access it and type comments/suggestions from within an incognito tab or private browsing window.
4. Share the link with team-members Peter or Casper via private message in Discord.

Remember that the draft proposal link does not count as a final submission. You must download the Google Doc as a PDF and upload it to the GSoC Dashboard before the deadline. Google allows you to delete the submitted PDF and upload a new one right up to the deadline, so you should submit something early even if you plan to come back and amend it later.

About you

Name and email

Please provide your full name and email address.

Discord nickname

If you frequent our Discord Server please let us know what your nick is. If you don't, then you'd better connect and introduce yourself!

MuseScore.org and GitHub profile links

Please include links to these profiles. To save us time, you should also include a link to your GitHub pull requests for MuseScore. For example:

MuseScore.org profile: https://musescore.org/en/user/57401 (shoogle)
GitHub profile: https://github.com/shoogle
MuseScore PRs: https://github.com/musescore/MuseScore/pulls/shoogle

Please note that your musescore.ORG profile has a different URL to your musescore.COM profile. We need the .ORG profile link. You can find this by visiting https://musescore.org/user and copying the URL this redirects to (if you are logged in).

Links to evidence (optional)

If you have any web pages you'd like us to know about, please include links to them. These could be:

• A website, blog, or YouTube channel that you run
• A repository on GitHub that you own or manage
• An impressive pull request that you submitted to us or another open source project
• An interesting music/programming/design discussion thread that you participated in

Don't worry if you feel you have nothing to show here. The main things we are looking for is at least one non-trivial pull request on MuseScore's repository and some activity in the Discord Server.

Remember, to be eligible to participate you must be a student or a beginner. If you're not a student, and you already make non-trivial open source contributions on a regular basis, this would make you ineligible to participate as a GSoC contributor.

Bio

Tell us a bit about you, such as:

• What are you studying and where, or if you are in work what is your job?
• What activities do you enjoy?
• What is your experience with MuseScore or other music notation software?
• What code development projects have realized, music or otherwise?
• Are you a musician? Which instrument(s) do you play or vocal parts do you sing?

About the project

Synopsis

A short description of the project.

SIze and Duration

Do you consider the project to be medium (~175 hours) or large (~350 hours) in size? We may ask you to change this if we disagree. Please note that the project size cannot be changed after the proposal submission deadline. We will not select your project if we feel the requested size is inaccurate.

Do you expect to complete the project within the standard 12 week period or do you anticipate needing extra time? Google allows projects to be extended by up to 10 weeks (i.e. total length of 22 weeks). The extension can be granted during the project if necessary, but we want to know in advance wherever possible. Please state your reason(s) briefly here (e.g. time off for vacation, work, classes, coursework, etc.) and then elaborate on this in the Schedule section if required.

Benefits to MuseScore

Describe how your project will benefit MuseScore. How will it benefit musicians using MuseScore to create scores? Will it be an aid for future MuseScore development?

Deliverables

Provide a user-level summary of the final output or results of your project. What does it look like? How do users interact with it? How does it cooperate with the rest of MuseScore's features?

There might not be time for everything so try to identify what is essential and what could be left for optional stretch goals at the end of the project. What would the MVP (minimum viable product) look like? Would it be ready for end users straight away, or is it just the beginnings of a system that would require further development beyond the end of your project?

Schedule

How long will the project take? When can you begin work? Include an estimated timeline of the project with mini-milestones. Please number the weeks during the coding period and give each Monday's date as the week beginning:

Week 1 - 13th June
Do research. Get familiar with code.

Week 2 - 20th June
Start implementing feature X.

Week 3 - 27th June
Unavailable (vacation).

Week 4 - 4th July
Continue implementing feature X.

The schedule is just an estimate so don't worry if you're not exactly sure how long things will take or what order you will tackle them in. Where possible, try to break the project down into stages that can be merged in separate PRs throughout the project rather than in one big PR at the end.

The aim is to have your MVP (minimum viable product) ready at the earliest possible stage. If the project turns out to be harder than expected, the MVP might be all you manage to get done, but it should serve as a starting point for future development by the community or internal team (or by you if you stick around!). For this reason, it's a good idea to spend a bit of time tidying and commenting the code as you go along, and writing documentation at the end of the project to aid future development.

Make sure you note any vacation time or other commitments (e.g. work, classes, coursework, etc.) you expect to have during the project period. Such things may provide valid reasons for requesting an extension in advance. With the exception of fixed dates like the first evaluations, we can allow for some flexibility during the project. However, we will fail GSoC contributors who do not give advance notice of prior commitments or extended periods when they will be unavailable during the coding period.

Implementation (optional)

For bonus points, tell us any details you can about how you would actually implement the project in the code. You could:

• Mention some files and classes you expect to create/edit/remove as part of your project.
• Describe an algorithm that you will have to implement.
• List any libraries or resources that you might need to include, and explain why you chose them over alternatives.
• Create a simple UML diagram or flowchart to illustrate how different areas of code will interact.

This really is a bonus section so make sure you have completed everything else first and sought feedback from us before doing any work on this section.

Conclusion

Why is this the right project for MuseScore and why are you the right person for this project?

Adding Ideas to this Page

GSoC applicants should discuss potential ideas with the team in MuseScore's Discord Server before adding them to this page. Introduce yourself in the #gsoc channel and please post your questions there whenever possible, but you may send a direct message to a mentor, or to our community ambassador Peter Jonas, if there is something you want to keep private from other contributors.

GSoC Contributors

You don't have to do one of the ideas listed on this page; you can suggest your own. Always speak to a team member first to check that it would be manageable before you begin writing a proposal.

Mentors

In order to meet Google's requirements, only experienced developers who are familiar with MuseScore's code are eligible to mentor projects for GSoC. Please speak to us if you are interested.

Community

Everybody is welcome to suggest ideas to the team. Once the projects have started you can follow the progress of the students and offer constructive feedback.

Process

If your application is successful, the first step will be to have an initial meeting with one of the internal designers as well as your mentor (who will make contact with you). The designer and mentor will provide an initial specification that will outline all aspects of the desired functionality (core feature, accessibility, associated shortcuts, etc.). This specification will then be discussed and potentially revised to ensure that the scope of the project is not too large. Throughout the process of development, you will be encouraged to share updates with relevant team members to ensure that your work receives testing, development advice and design support.

Project Ideas

Palettes UX / UI improvements

The palettes section in MuseScore 4 has been improved a lot in recent years but still needs a lot of additional refinement. In particular, there are some very obvious UX and UI improvements that would benefit the vast majority of users. See this quick explainer video to get an idea.

Here are a few improvements that would be ideal to solve as part of this project. Please note the exact UX interactions will be specified by a designer in advance.

• Articulations - to be made to work like the articulations in the note input bar
• Dynamics - you can select one dynamic and replace it with another
• Hairpins: you can select a hairpin and replace it with another
• Accidentals: follow the same logic as the accidentals in the Note Input bar, including triggering the appropriate sounds
• General - when an item is selected on the score, it is selected in palettes too
• General - when selecting an element on the score, it can be removed by selecting the same element again from the palettes menu
• General - when selecting an element on the score, it can be replaced by selecting an element from the same category in palettes

Apart from developer mentoring, this project will involve close collaboration with our design team, who will provide designs and testing support.

Possible extensions: spell-checking, automatic hyphenation, verse extraction.

• Difficulty: Medium
• Time: ~350 hours
• Skills: C++, Qt, QML, design
• Suggested by: Martin Keary (@Tantacrul)
• Design support: Bradley Kunda (@bradleykunda)
• Possible mentor: Casper Jeukendrup (@cbjeukendrup)

Floating Text Widget / UI improvements

A small widget that would contain all options found currently in the Properties panel, which hovers above selected text on the score. Very much inspired by similar widgets used in word processing applications.

Please note the exact UI/UX will be specified by a designer in advance. Apart from developer mentoring, this project will involve close collaboration with our design team and testing support.

Possible extensions: spell-checking, automatic hyphenation, verse extraction.

• Difficulty: Medium
• Time: ~350 hours
• Skills: C++, Qt, QML, design
• Suggested by: Martin Keary (@Tantacrul)
• Design support: Martin Keary (@Tantacrul)
• Possible mentor: Casper Jeukendrup (@cbjeukendrup)

Keyboard Navigation

This project would implement keyboard access in certain parts of the app that currently lack it, and improve it in areas where the current implementation is unintuitive.

To provide some background, MuseScore 4 has a new 'hierarchical' system of keyboard navigation:

• Press tab to move focus between control groups (e.g. toolbars and panels).
• Press the arrow keys to focus individual controls within the group (e.g. buttons in a toolbar).

This is different to the conventional 'linear' navigation system used in MuseScore 3 and other applications, where the tab key was used to access every individual control in the entire interface.

The new system is faster since it requires fewer keypresses to get to where you want to go. However, the new system can be disrupted by text fields and other controls that "swallow" arrow key events, meaning that the tab key, rather than the arrow keys, must be used to navigate away from those fields. Furthermore, the new system impedes discoverability because it is no longer possible to access all the controls simply by pressing the tab button alone.

This GSoC project would adopt a hybrid approach to navigation. The hierarchical system would be used in places where it makes the most sense, such as on the Score tab, where there are many controls and navigation speed is the priority. Meanwhile the traditional "tab to everything" approach would be used in places where discoverability is crucial, such as dialogs.

A stretch goal for this project would be to implement mnemonic accesses keys for dialog buttons (e.g. Alt+N for Next). Access keys have been implemented in the menus, but not yet in the dialogs.

• Difficulty: Medium
• Size: Large (~350 hours)
• Skills: C++, Qt
• Suggested by: Peter Jonas (@shoogle)
• Possible mentor: Peter Jonas (@shoogle)

Woodwind Fingerings

Important: The internal team is still considering whether this is viable as a GSoC project. You are allowed to submit multiple proposals, so if you apply for this project idea, we recommend applying for something else too.

While piano and guitar have easy to notate fingerings using only numbers, most wind instruments still use drawings to represent fingerings. There is currently various plugins that implement in a not-so-user-friendly manner that ability for very few instruments. Some free fonts, like the fiati font (source here, demo here, include glyphs for a lot of instruments. These could be used as a basis (exporting the base diagrams as svg and using them as base). This new fingering element would work very similarly to the existing fretboard diagrams, which means keys could be toggled pressed or not pressed with a click. Apart from developer mentoring, this project will involve close collaboration with our design team, who will provide designs and testing support.

• Difficulty: Medium to Hard
• Time: ~350 hours
• Skills: C++, Qt, QML, UI design
• Suggested by: Marr11317
• Possible mentor: Casper Jeukendrup (@cbjeukendrup)

Guitar Fretboard

There currently exists a MuseScore plugin to reveal an interactive guitar fretboard diagram, which can be used as an extra means of entering notes into the score:

We wish to incorporate this concept as a native feature within MuseScore 4, perhaps using this plugin as a starting point, or alternatively working from scratch. We intend to design some feature improvements, including better note input interaction from the fretboard, as well as transposition features that connect with guitar-specific things like alternate string tunings and capo settings. There will also be the opportunity to work on a new UI styling for the fretboard visualisation itself. Apart from developer mentoring, this project will involve close collaboration with our design team, who will provide designs and testing support.

• Difficulty: Medium to Hard
• Time: ~350 hours
• Skills: C++, Qt, QML, UI design
• Suggested by: Bradley Kunda (@bradleykunda)
• Possible mentor: Casper Jeukendrup (@cbjeukendrup)

Accessibile Native VST Interface

This is a UI system that represents all parameters in a given VST using native controls. This provide a backup when the VST interface fails. More importantly, it provides an accessible version of the interface controls. This job requires that all controls in the native VST interface can be accessed via keyboard navigation and is providing the appropriate output the screen readers.

• Difficulty: Medium
• Time: ~350 hours
• Skills: C++, Qt, AppImage
• Suggested by: Martin Keary (@Tantacrul)
• Design support Jessica Williamson
• Possible mentor: Casper Jeukendrup (@cbjeukendrup)

AppImage Installer and Updater

MuseScore's AppImage has command line options to update and install itself, but there is no way to do these things via the GUI. This project would create an update solution for Linux along the lines of the Sparkle and WinSparkle frameworks that MuseScore uses for automatic updates on macOS and Windows respectively. The project would include an install wizard that would offer to integrate the AppImage with the desktop environment (GNOME, KDE, etc.) so that it appears in system menus. While the project would be built primarily for MuseScore, the code would be written and licenced in such a way that other Qt-based AppImage projects could use it too.

• Difficulty: Medium
• Time: ~350 hours
• Skills: C++, Qt, AppImage
• Suggested by: Peter Jonas (@shoogle)
• Possible mentor: Peter Jonas (@shoogle)

Other Ideas

Check MuseScore 3 features not (yet) implemented in MuseScore 4

Adding ideas to this page

To all students: please discuss potential ideas with the team in MuseScore's Discord Server before adding them to this page. Introduce yourself in the #gsoc channel and please post your questions there whenever possible, but you may send a direct message to a mentor, or to our community ambassador Peter Jonas, if there is something you want to keep private from other contributors.

GSoC Contributors

You don't have to do one of the ideas listed on this page; you can suggest your own. Always speak to a team member first to check that it would be manageable before you begin writing a proposal.

Mentors

In order to meet Google's requirements, only experienced developers who are familiar with MuseScore's code are eligible to mentor projects for GSoC. Please speak to us if you are interested.

Community

Everybody is welcome to suggest ideas to the team. Once the projects have started you can follow the progress of the students and offer constructive feedback.

Process

If your application is successful, the first step will be to have an initial meeting with one of the internal designers as well as your mentor (who will make contact with you). The designer and mentor will provide an initial specification that will outline all aspects of the desired functionality (core feature, accessibility, associated shortcuts, etc.). This specification will then be discussed and potentially revised to ensure that the scope of the project is not too large. Throughout the process of development, you will be encouraged to share updates with relevant team members to ensure that your work receives testing, development advice and design support.

Project Ideas

Global Shortcuts

Currently our shortcut system allows users to assign key combinations to a set number of existing functionalities. We want to expand this capability to enable users to select any item in the interface and assign a shortcut to it immediately.

As a stretch goal, we would also like to create large shortcut 'sets' to help accommodate new users. For example, if a user is coming from Sibelius or Finale, they should be able to select a set that matches the workflow they are accustomed to.
We have designed the interface and UX to support this feature already.

Apart from developer mentoring, this project will involve close collaboration with our design team, who will provide designs and testing support.

• Difficulty: Hard
• Time: ~350 hours
• Skills: C++, Qt, QML, UI design
• Suggested by: Martin Keary (@Tantacrul)
• Possible mentor: Peter Jonas (@shoogle)
• Design support: Martin Keary (@Tantacrul) and Jessica Williamson

AppImage Installer and Updater

MuseScore's AppImage has command line options to update and install itself, but there is no way to do these things via the GUI. This project would create an update solution for Linux along the lines of the Sparkle and WinSparkle frameworks that MuseScore uses for automatic updates on macOS and Windows respectively. The project would include an install wizard that would offer to integrate the AppImage with the desktop environment (GNOME, KDE, etc.) so that it appears in system menus. While the project would be built primarily for MuseScore, the code would be written and licenced in such a way that other Qt-based AppImage projects could use it too.

• Difficulty: Medium
• Time: ~350 hours
• Skills: C++, Qt, AppImage
• Suggested by: Peter Jonas (@shoogle)
• Possible mentor: Peter Jonas (@shoogle)

Lyrics Editor

As described here, the Lyrics Editor would display all lyrics from the score as plaintext in an editable multiline text field. The contents of the text field would be doubly linked with the score, meaning that a change to lyrics in either the score or the Lyrics Editor would be reflected in the other. Users would be able to search for lyrics online and paste them into the lyrics editor, or copy lyrics from the editor to produce lyric booklets for choirs and church services.

The lyrics editor was partially implemented in PR #2326, but this was using the old Qt Widgets (C++) interface for MuseScore 3 and the design was far from optimal. The student would work with the in-house design team to come up with an improved design, and then implement it in the new Qt Quick (QML / JavaScript) interface for MuseScore 4.

Apart from developer mentoring, this project will involve close collaboration with our design team, who will provide designs and testing support.

Possible extensions: spell-checking, automatic hyphenation, verse extraction.

• Difficulty: Medium
• Time: ~350 hours
• Skills: C++, Qt, QML, design
• Suggested by: Peter Jonas (@shoogle)
• Possible mentor: Peter Jonas (@shoogle)

Woodwind fingerings

Important: The internal team is still considering whether this is viable as a GSoC project. You are allowed to submit multiple proposals, so if you apply for this project idea, we recommend applying for something else too.

While piano and guitar have easy to notate fingerings using only numbers, most wind instruments still use drawings to represent fingerings. There is currently various plugins that implement in a not-so-user-friendly manner that ability for very few instruments. Some free fonts, like the fiati font (source here, demo here, include glyphs for a lot of instruments. These could be used as a basis (exporting the base diagrams as svg and using them as base). This new fingering element would work very similarly to the existing fretboard diagrams, which means keys could be toggled pressed or not pressed with a click. Apart from developer mentoring, this project will involve close collaboration with our design team, who will provide designs and testing support.

• Difficulty: Medium to Hard
• Time: ~350 hours
• Skills: C++, Qt, QML, UI design
• Suggested by: Marr11317
• Possible mentor: Casper Jeukendrup (@cbjeukendrup)

Guitar Fretboard

There currently exists a MuseScore plugin to reveal an interactive guitar fretboard diagram, which can be used as an extra means of entering notes into the score:

We wish to incorporate this concept as a native feature within MuseScore 4, perhaps using this plugin as a starting point, or alternatively working from scratch. We intend to design some feature improvements, including better note input interaction from the fretboard, as well as transposition features that connect with guitar-specific things like alternate string tunings and capo settings. There will also be the opportunity to work on a new UI styling for the fretboard visualisation itself. Apart from developer mentoring, this project will involve close collaboration with our design team, who will provide designs and testing support.

• Difficulty: Medium to Hard
• Time: ~350 hours
• Skills: C++, Qt, QML, UI design
• Suggested by: Bradley Kunda (@bradleykunda)
• Possible mentor: Casper Jeukendrup (@cbjeukendrup)

Harp Pedaling

There currently exists a MuseScore plugin to reveal an interactive harp pedaling interface, which places pedal diagrams on the score:

We wish to incorporate this concept as a native feature within MuseScore 4. The widget will also allow users to enter the text for pedaling as well as diagrams. This project would involve some work on refining the appearance of the diagrams (and text), as they appear on the score. In addition, work should be done to ensure that notes that are currently unplayable are displayed in red. Apart from developer mentoring, this project will involve close collaboration with our design team, who will provide designs and testing support.

• Difficulty: Medium
• Time: ~175 hours
• Skills: C++, Qt, QML, UI design
• Suggested by: Martin Keary (@Tantacrul)
• Possible mentor: Casper Jeukendrup (@cbjeukendrup)

How to add an idea to this page

Click the 3 dots button at the top right and "Edit". Copy a project idea from below and update the text with your new idea. Don't forget to remove the mentor's name (unless it's you).

Everybody is welcome to ideas to the page, but newcomers are encouraged to discuss their idea with developers in MuseScore's Telegram group first. Also have a look at ideas from previous years.

• Students
  • You don't have to do one of the ideas listed on this page; you can suggest your own. Always speak to us first to check that it would be manageable before you begin writing the application.
• Mentors
  • In order to meet Google's requirements, only experienced developers who are familar with MuseScore's code are eligible to mentor projects for GSoC. Please speak to us if you are interested.
• Community
  • Everybody is free to contribute ideas. You are also welcome to follow the progress of the students and offer constructive feedback once the projects are underway.

Project Ideas

Global Shortcuts

Currently our shortcut system allows users to assign key combinations to a set number of existing functionalities. We want to expand this capability to enable users to select any item in the interface and assign a shortcut to it immediately.

As a stretch goal, we would also like to create large shortcut 'sets' to help accommodate new users. For example, if a user is coming from Sibelius or Finale, they should be able to select a set that matches the workflow they are accustomed to.
We have designed the interface and UX to support this feature already.

• Difficulty: Easy (unless you propose something more difficult)
• Skills: C++, Qt, QML, UI design
• Suggested by: Martin Keary (@Tantacrul)
• Mentor: Vasily Pereversev
• Design support: Martin Keary (@Tantacrul) and Jessica Williamson

Hairpin & Dynamics: UX Improvements

Hairpins are among the most important features in MuseScore. In MuseScore 3, the experience of adding, lengthening and copying/pasting has been improved but the overall task of finessing them remains unfinished.

This task involved multiple small UX improvements to dragging and snapping behaviour, as well as stretch goals to develop a system where multiple hairpins can be edited at once, and an even stretchier goal where they can be grouped too. The designs for the expected behaviours have been created for this already by our in-house design team. This is a highly collaborative project that will involve iteration based on user-testing conducted by the design team.

• Difficulty: Easy (unless you propose something more difficult)
• Skills: C++, Qt, QML, UI design
• Suggested by: Peter Jonas (@shoogle)
• Mentor: Vasily Pereversev
• Design support: Martin Keary (@Tantacrul)

Accessibility for low vision impairment

It is estimated that one in six adults over age 45 has low vision; one in four adults over age 75 has low vision. For this reason, MuseScore 4 was built with a new UI system that allows for very flexible colour themes. In part, this was done to make way for a highly configurable 'High Contrast' theme which allows users to specify the colours and intensity of the MuseScore interface. This would be largely based on the flexibility of the High Contrast capability seen on Windows 10 devices.

With any remaining time, this task should include a magnification system that allows the user to scale up the size of the MuseScore interface as well as the ability to invert the colours of the score page itself.

• Difficulty: Easy (unless you propose something more difficult)
• Skills: C++, Qt, QML, UI design
• Suggested by: Martin Keary (@Tantacrul)
• Mentor: Vasily Pereversev
• Design support: Martin Keary (@Tantacrul)

Tours

MuseScore 3 has a Tours facility, which is basically a series of dialogs that point out different parts of the program and teach people how to use them. However, these dialogs can distract users and get in the way of a normal workflow.

For MuseScore 4, we'd like to improve the Tours feature to make it more helpful and less annoying. This could mean using tooltip-style popups rather than dialogs, integrating tutorials directly into the interface, or another idea suggested by the student. The student would work with their mentor and the internal design team to come up with the best design, implement it, and update it based on testing and user feedback.

• Difficulty: Easy (unless you propose something more difficult)
• Skills: C++, Qt, QML, UI design
• Suggested by: Martin Keary (@Tantacrul)
• Mentor: Vasily Pereversev

AppImage Installer and Updater

MuseScore's AppImage has command line options to update and install itself, but there is no way to do these things via the GUI. This project would create an update solution for Linux along the lines of the Sparkle and WinSparkle frameworks that MuseScore uses for automatic updates on macOS and Windows respectively. The project would include an install wizard that would offer to integrate the AppImage with the desktop environment (GNOME, KDE, etc.) so that it appears in system menus. While the project would be built primarily for MuseScore, the code would be written and licenced in such a way that other Qt-based AppImage projects could use it too.

• Difficulty: Medium
• Skills: C++, Qt, AppImage
• Suggested by: Peter Jonas (@shoogle)
• Mentor: Peter Jonas (@shoogle)

Embed Third-Party Documents

MuseScore allows users to insert images in SVG, PNG and JPEG formats, which can be useful for adding complex notation that is not natively supported. However, there is no convenient way to make changes to these images after they have been inserted in MuseScore. Instead, users must edit the image in an external program, ideally using the original source file (e.g. Inkscape or Adobe Illustrator project file) rather than the image itself.

We don't want to add complex image editing features in MuseScore, but it would be great to have the option to right-click on an image and choose "Edit with Program X". MuseScore should allow project files for Program X to be embedded directly in the score along with the corresponding SVG, PNG, or JPEG image. When the user chooses to edit the image, Program X would be launched with the project file open in a temporary folder. MuseScore would monitor the project file for changes, and when it is saved, MuseScore would call Program X on the command line to generate a new SVG, PNG or JPEG image to replace the one currently displayed. The new image would be stored in the MSCZ score file along with the newly updated source file for Program X.

In the future, this process could be generalised to allow embedding third party audio, video, and rich text documents, as well as images. Advanced users might also like to specify their own custom script as both the embedded project file and as the "Program X" used to launch it. We would need to consider security implications very carefully before enabling that particular use case.

• Difficulty: Medium
• Skills: C++, Qt
• Suggested by: Peter Jonas (@shoogle)
• Mentor: Peter Jonas

Lyrics Editor

As described here, the Lyrics Editor would display all lyrics from the score as plaintext in an editable multiline text field. The contents of the text field would be doubly linked with the score, meaning that a change to lyrics in either the score or the Lyrics Editor would be reflected in the other. Users would be able to search for lyrics online and paste them into the lyrics editor, or copy lyrics from the editor to produce lyric booklets for choirs and church services.

The lyrics editor was partially implemented in PR #2326, but this was using the old Qt Widgets (C++) interface for MuseScore 3 and the design was far from optimal. The student would work with the in-house design team to come up with a improved design, and then implement it in the new Qt Quick (QML / JavaScript) interface for MuseScore 4.

Possible extensions: spell-checking, automatic hyphenation, verse extraction.

• Difficulty: Medium
• Skills: C++, Qt, QML, design
• Suggested by: Peter Jonas (@shoogle)
• Mentor: Peter Jonas (@shoogle)

Select/Copy/Paste Improvements

One of the most long-standing feature requests is to improve copy/paste to allow key and time signature changes, tempo texts, repeats, and other "system" elements to be copied. This would be optional, as sometimes you don't want those things copied. The actual implementation of this is not necessarily all that difficult, but the project would also involve determining a good design for presenting this to the user. This might involve the selection filter, but this too is in some need of redesign work, perhaps finding a way to combine it with the "Select" right-click menu, integrating the ideas of range and list selections, etc.

• Difficulty: Medium
• Skills: C++, Qt, QML, UI design
• Suggested by: Marc Sabatella (@MarcSabatella)
• Mentor: Marc Sabatella

Chord Symbol Style Editor

MuseScore allows you to select from several different options for the display of chord symbols, with some of the details controlled by an XML file. While custom XML files are supported, the process is cumbersome and not documented and really not an option for the average user. We could really use a WYSIWYG chord symbol style editor to allow a user to specify for herself how various chord symbols should be displayed. One was partially implemented many years ago but never incorporated into the program. It was limited in that you needed to specify each and every chord symbol separately - so C7 and C9 needed different customizations, as did C7b9 and C7b5, etc. A good style editor should be more rule-based, building on the semantic structure of a chord symbol and allowing a user to quickly specify rules to be followed by default but also individual overrides for specific chords. Probably at least some of the previous code could be reused.

• Difficulty: Medium
• Skills: C++, Qt, QML, UI design
• Suggested by: Marc Sabatella (@MarcSabatella)
• Mentor: Marc Sabatella

Woodwind fingerings

While piano and guitar have easy to notate fingerings using only numbers, most wind instruments still use drawings to represent fingerings. There is currently various plugins that implement in a not-so-user-friendly manner that ability for very few instruments. Some free fonts, like the fiati font (source here, demo here, include glyphs for a lot of instruments. These could be used as a basis (exporting the base diagrams as svg and using them as base). This new fingering element would work very similarly to the existing fretboard diagrams, which means keys could be toggled pressed or not pressed with a click.

• Difficulty: Medium to Hard
• Skills: C++, Qt, QML, UI design
• Suggested by: Marr11317
• Possible mentor: Yet to be determined

Export Metronome Sound

There have been user requests dating back some time (https://musescore.org/en/node/154666) to add a feature that allows users to export audio with the metronome sound included. The current workaround is to insert some sort of percussion part (ie. wood block) and use it to make a click track. I'm working on a plugin to automate this process for the 3.6.x versions of MuseScore; however, I think there could be an "Export with metronome sound" checkable option implemented in MuseScore 4 when users go to export a score as mp3, ogg, etc.

• Difficulty: Easy to medium
• Skills: C++, Qt, QML, UI design
• Suggested by: Dominic Occhietti
• Mentor: TBD

Smart Tempos

A tempo element is made up of text and/or a metronome marking. Examples:

• Allegro
• ♩. = 120
• Allegro (♩. = 120)

In MuseScore 3, the entire tempo element is editable text, including the metronome marking, which makes it very easy to create a corrupt tempo that doesn't work during playback. In addition, the "BPM" field in the Inspector always sets the tempo in terms of quarter-notes-per-minute regardless of time signature, rather than using the natural beat unit (e.g. dotted-quarter in 6/8). When a score is saved in MuseScore's MSCX format, the tempo is converted to quarter-notes-per-second for no apparent reason.

In MuseScore 4, we would like to make the metronome marking separate from the text part of the tempo. In the example above, users would be able to edit the "Allegro" text by double-clicking on it in the score, but the "(♩. = 120)" metronome marking would have to be edited via the Inspector or a special pop-up that would appear when the user single-clicks on a tempo marking in the score. There would be an option to hide the metronome marking to create a purely textual tempo, but the metronome marking would still be used internally for playback purposes.

The metronome marking would be saved in the MSCX file in the form of an equation, such as:

<Tempo>
    <equationVisible>1</equationVisible>
    <bracket>auto</bracket>
    <text>Allegro <equation>[4.]=120</equation></text>
</Tempo>

An advanced implementation would give users the option to edit the equation directly within MuseScore. This could provide a means to enter more exotic tempo markings, such as ones with tuplets in the metronome marking, or multiple notes tied together. This advanced equation syntax could be implemented as an extension if time is available at the end of the project.

Additional consideration to perhaps support markings as ♩. = ca 100

• Difficulty: Medium to Hard, depending on how far you get
• Skills: C++, Qt, QML
• Suggested by: Peter Jonas (@shoogle)
• Mentor: Peter Jonas (@shoogle)

Rubato: ritardando and accelerando

There have been user requests dating back 10 years for playback of accelerandode and ritardando (#9383: Rubato: ritardando and accelerando).
There's currently a plugin for this, https://musescore.org/en/project/tempochanges.
But this should really be a builtin function, similar to crescendo/diminuando.

• Difficulty: Easy to medium
• Skills: C++, Qt, QML, UI design
• Suggested by: many many users
• Mentor: TBD

Mixer & Tracks

Hello. A while ago, I created a series of descriptions and illustrations suggesting interesting features that could be implemented into Musescore 4's mixer design; the links to those posts are listed below. Since I am not part of the development of Musescore 4, I want to emphasize some assumption that I made when creating these concepts. These assumption includes that MS4 will eventually allow Audio / Midi recordings, importations, and automations; and it will allow 3rd party plugins such as EQs and Compressors.

*My apologies for writing this post as first person (if not appropriate for this feed); I couldn't come up a different method to authentically address this.

Comment Links:
1. Initial Post - https://musescore.org/en/node/305002#comment-1033813
2. Grouping - https://musescore.org/en/node/305002#comment-1033860
3. Mini Mixer and Other Tabs - https://musescore.org/en/node/305002#comment-1034079
4. FX Control - https://musescore.org/en/node/305002#comment-1034352

• Difficulty: Medium +
• Skills: C++, Qt, QML, UI design
• Suggested by: SketalDaz (@SketalDaz)
• Mentor: TBD
• Design support: TBD

Piano Roll Editor

Important: The internal team is still considering whether this is viable as a GSoC project. You are allowed to submit multiple proposals, so if you apply for this project idea, we recommend applying for something else too.

MuseScore 3 has a Piano Roll Editor (PRE) that can be accessed by right-clicking on any staff in the score. A piano roll is a simple graph of pitch against time, which is familiar to users of sequencer-type programs. MuseScore's PRE also includes a graph of velocity against time, which is useful for adjusting dynamics. The PRE allows for detailed control of playback without affecting the appearance of notation in the score. The PRE needs to be reimplemented from scratch in QML before it can be ported to MuseScore 4, where it would become the starting-point for a full sequencer implementation sometime in the future.

The current Piano Roll Editor is poorly designed and overloaded with functionality that is not strictly necessary. The internal team will assist the student in coming up with a new design for MuseScore 4. At a minimum, the new PRE will simply provide viewing of pitch and velocity graphs against time, but no editing capabilities. Ideally, the student would implement editing at least for velocity. Full editing for note duration and pitch would be enabled only if sufficient time is available at the end of the project.

• Difficulty: Hard
• Skills: C++, Qt, QML, UI design
• Suggested by: Peter Jonas (@shoogle)
• Mentor: Vasily Pereversev
• Design support: Martin Keary (@Tantacrul) and Jessica Williamson

Your idea

Click the 3 dots button at the top right and "Edit", then copy and paste an idea below and change the text with your new idea for GSoC 2020. Don't forget to remove the mentor's name (unless it's you).

Anybody is welcome to add an idea to the page, but newcomers are encouraged to discuss their idea on the MuseScore developers Telegram channel or via the developer mailing list first. Also check ideas from previous years.

Students

If you are a student keen to take part in GSoC, we strongly believe that the best project for you is the one you are most interested in and therefore most willing to do. It doesn't have to be one of the ones listed on this page; you can suggest your own.

Whichever idea you choose, you should speak to us first to check that it would be manageable before you go to the effort of writing a proposal. This is particularly important if you want to suggest your own project, as we would have to find a suitable mentor.

Check out the steps toward successful application.

Mentors

If you would like to be a mentor for GSoC then feel free to put your name down next to any projects you are interested in and that you think you are qualified to mentor. In order to meet Google's requirements for mentors, only experienced developers with a high level of familiarity with MuseScore's code are eligible. However, non-developers, and developers new to MuseScore, may be able to assist in an advisory role if they have specialist knowledge relevant to the project in question.

Community

Everybody is free to contribute ideas. You are also welcome to follow the progress of the students and offer constructive feedback once the projects are underway.

Post-its for miscellaneous ideas

One feature that MuseScore currently lacks is the ability to jot down and attach notes (annotations) to scores. Having the ability to attach little annotations of musical ideas to different parts of the main score may be beneficial for composers and musicians, as they can keep track of their thought process and come back to old ideas at their leisure. Perhaps the composer has some ideas for a section of music that might work in the context of the entire piece, but the composer hasn't gotten around to fleshing out the new ideas yet or likes another idea better at the moment.

Having the ability to attach little notes at different points in the score is a good way to brainstorm. Also, it could help organize things better than having a new project altogether or keeping a separate music notebook and writing down notes there. The post-its could be color coded, broken down into different sections, etc. Instead of creating scores for performance, musicians could create scores just for brainstorming, and gradually transform the score into a final score when they have enough ideas. The post-its could have the ability to contain text and to test different combinations of chord progressions, voice leading, and instrumentation. There could be bullet points for different musical ideas, color coded as the user desires. With "create post-it" mode enabled, the user could click on a particular point in the score and create a post-it there, and from there the user could write some notes in the little pop-up. The user could then close out and reopen the notes by clicking an icon that been created of a little post-it.

Difficulty: Medium
Skills: C++/Qt
Possible mentor: Marc Sabatella (@MarcSabatella)

Simplified lyric & chord symbols only

A simplified pop/rock input method for making lyrics & chord symbol (and/or chord tab) only scores, without worrying about a staff, melody or rhythm initially, but which would still could be easily updated to include notated melody with rhythm. Maybe using a minimal slimmed-down interface. And if could import basic ascii charts of lyrics chord symbols.

Difficulty: Medium
Skills: C++/Qt
Possible mentor: @ericfont

Diatonic instrument definition

One of the most common requests that is nearly impossible to implement in current versions of MuseScore is diatonic instruments such as the Shamisen and Appalachian Dulcimer. These instruments have a limited number of notes that can be played on a string due to their fret definitions. Current tablature does allow for the limited notes permitted to be played on a string.

I would suggest the instrument definitions be expanded to allow for detailed frets that can be applied to a given string. The definition should limit the actual note that can be played by the instrument and indicate an error similar to the current method if an illegal note is entered on both the standard and tablature clefs.

A possible way to do this is to create an interface that allows for defining new instruments to include string and fret definitions as well as individual notes for instruments such as diatonic harmonicas and accordions among others.

I am not qualified to be a mentor, but I would be more than willing to be a consultant on this project (@mike320), with programming mentoring from @TheOtherJThistle.

Difficulty: Hard
Skills: C++/Qt
Possible mentor: mike320 + James Thistlewood (JThistle/TheOtherJThistle)

Ornaments maker

A common request if for proper playback of ornaments, such as turns and trills with accidentals. There needs to be a framework created to allow the user to define an ornament and have it play back properly in MuseScore. One thing you cannot currently do is apply an accidental to an ornament.

The interface would allow the user to define the ornament, or line in the case of a trill line or prall line, based upon the key of C on a C note. The actual notes played when the ornament is encountered would be a transposition of these notes. So if the user defined a trill with a sharp above it to be played as D#-C-D#-C... (as was done in the baroque era), a trill on an G in a key with 4 or fewer sharps would result in the trill being played as A#-G-A#-G... The user would also be able to define the duration of each note played, allowing in the case of a trill for the notes played to be defined as a set duration such as 16th or 32nd notes according to the requirements of the music. Turns, pralls and so forth should also allow for accidentals to be added under the ornament to allow for defining proper playback of all ornaments used in western music.

I am not qualified to be a mentor, but I would be more than willing to be a consultant on this project (@mike320), with programming mentoring from @TheOtherJThistle.

Difficulty: Hard
Skills: C++/Qt
Possible mentor: mike320 + James Thistlewood (JThistle/TheOtherJThistle)

Keyboard real-time input

Author: @anatoly-os

I wish we could use keyboard (not MIDI-keyboard) for convenient real time note input. The focus of the project is composers who create music from scratch.

I will add the video which show the idea later.

When creating music, we usually have some melody in mind and want to express it with simple combination of notes and its duration. Real time input starts with the default tempo and fills the rests with notes specified by user. It is not necessary to hold letters (A-G) to enter the duration, the input mode fills the beats with the previously added note until rest or following note key will be pressed.

You still need to use letters to specify a pitch, but duration is set depending on how long you hold the button. It is like you are playing piano, but playing "keyboard" instead. So, there is a metronome, which counts the rythm. And you press and hold buttons to create a melody.

Difficulty: Medium
Skills: C++/Qt
Possible mentor: anatoly-os

Lyrics editor

As described here and partially implemented here, the Lyrics Editor would display all lyrics from the score as plaintext in an editable multiline text field. The contents of the text field would be doubly linked with the score, meaning that a change to lyrics in either the score or the Lyrics Editor would be reflected in the other. Users would be able to search for lyrics online and paste them into the lyrics editor, or copy lyrics from the editor to produce lyric booklets for choirs and church services. A more advanced implementation would use a tree view where each lyrics verse is represented by a branch in the tree.
Possible extensions: spell-checking, automatic hyphenation, verse extraction.

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: Peter Jonas (@shoogle)

Palette shortcuts

Another way to improve palette accessibility (and general usability for all users) is to allow the user to define keyboard shortcuts for individual palette elements. For example, the user might want to press Alt+D to enter a key signature of D major, or Ctrl+T to add a trill, etc. There could be an option to set shortcuts in the context menu that appears when you right-click on a palette. If the user tries to set a shortcut that has already be defined for another palette element then a warning should be displayed. An improved implementation would also check for conflicts with the shortcuts set in the main Preferences dialog. An ideal implementation would allow shortcuts defined anywhere in the program to be dynamically registered with the central list of shortcuts displayed in the main Preferences dialog, so that all shortcuts could be set and unset in one place, and to guarantee that conflicts are avoided (c.f. the Plugin Manager allows the user to define shortcuts to run plugins, but there is no collision detection with shortcuts defined elsewhere).

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: Peter Jonas (@shoogle)

Command macros

In some engraving situations, it is useful to apply several commands to a single object. One case like this is if you want to add a end/begin repeat barline. You want to add an end repeat and a start repeat to the same barline. It could be useful to create a framework to allow users to create their own macros stringing more than one command together. A macro can then be applied with a single click or keyboard shortcut.

• Difficulty Medium
• Skills C++/Qt
• Possible mentor: Louis Cloete (@Louis Cloete)

Chord symbol style editor

MuseScore supports the entry of chord symbols like Gm7, C7b9, etc. It has a pretty flexible system for entering the chords, where you can type pretty much a human musician might understand and MuseScore will do its best to understand it as well. However, there are only limited controls for actually displaying the chord symbol. MuseScore provides two preset options - Standard and Jazz - and does not allow you to customize, for instance, how large the "G" should be relative to the "m" or the "7" in Gm7, or how much subscripting should be applied to the "b9" in C7b9. There was some preliminary work done on an editor years ago that could be leveraged in producing a more complete facility. There are also some improvement that could be considered in how chord symbols are handled with respect to transposition, linked parts, fretboard diagrams, capo, Nashville notation, MIDI import, MusicXML, etc.

• Difficulty: Medium to Hard
• Skills: C++/Qt
• Possible mentor: Marc Sabatella (@MarcSabatella)

Text editing improvements

Text in frames and elsewhere currently allows for some basic formatting options, but lacks many capabilities one would want in order to do any serious text editing, like to create educational materials with significant text between the musical examples. While we would likely not ever compete with word processors, merely implementing word wrap, justification, and a few other controls could go a long ways toward allowing users to create documents completely within MuseScore.

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: Marc Sabatella (@MarcSabatella)

Page layout controls

MuseScore provides a number of global controls over page layout - you can set the page size and margins, staff size, control distance between staves, hide empty staves, etc. There are certain overrides possible like staff spacers to change the distance between two staves, and the staff type change element to change certain properties for individual staves mid-score. However, sometimes there is still a need to for more control - override global settings for individual pages, or particular systems. You cannot have the overall staff size or default staff distance slightly smaller on one page than another, or change between percussion and pitched on a single staff, or designate certain systems to not hide empty staves, not fill to the right margin, etc. Also, we provide measure spacing controls per-measure, but no easy way to say "fit the following measures on one system".

This project would involve an investigation of how we might best expose controls like this to the user and then to design and implement the facility.

• Difficulty: Hard
• Skills: C++/Qt
• Possible mentor: Marc Sabatella (@MarcSabatella)

Cross-staff notation improvements

MuseScore can do cross-staff notation by selecting a note/rest and pressing Ctrl+Shift+Up/Down. However, there're a few limitations.

• User cannot stretch notes in a single chord to more than one staff: selecting a note and pressing Ctrl+Shift+Up/Down will move the entire chord. The feature request of moving some notes in a chord to another staff while keeping other notes in the original staff was created a long time ago (#14687: Split chord across staves in cross-staff notation), and this kind of notation can be really useful when writing scores for piano and other instruments.
• Layout collisions between cross-staff notes and other notes sharing the same graphic staff: the layout of notes on the destination staff won't try to avoid cross-staff notes. The ideal situation would be graphically treating the cross-staff notes as if in a second voice, but things can also be a little different. Issues #114141: Notes collide between cross-staff and #293279: Cross-staff notes don't cause existing beams and stems on other stave to avoid it can be a good start for you.
• No correct playback for cross-staff (and also cross-voice) arpeggio. See #65806: Allow correct playback of cross-staff/voice arpeggios.
• Cannot move other elements (besides notes/rests) to another staff. See #280156: Add a way to move elements other than notes cross-staff (or do it automatically when notes are moved).

A complete list of issues related to cross-staff notation can be seen in #285233: [EPIC] Cross-staff notation issues. While working on them, it's necessary to keep backward file compatibility in mind.

• Difficulty: Medium to Hard, depending on how far you get
• Skills: C++/Qt (doesn't necessarily involve UI changes, but you have to understand the geometric graphing of score elements)
• Possible mentor:

Repeat-related symbols

The two-measure repeat sign with working playback has been one of the most-requested features ever, as is evident by the number of forum requests and length of this issue #10220: Add a two and four measure (multi-measure) repeat sign with playback at 164 replies and going back 8 years. This project would involve coding various multi-measure and related features, like

• Two-measure repeat
• Old style multi-measure rests
• Repeat previous bar N times markings

• Automatic counting of repeated measures

• Difficulty: Medium

• Skills: C++/Qt
• Possible mentor:

Braille export

This project would add Braille music notation to the list of formats available via File > Export. Prior knowledge of Braille music notation is not required as the basic rules are fairly straightforward and can be picked up in the early stages of the project. As with everything, the specifics of Braille music notation do get quite complicated and can even vary from country to country, so the student would not be expected to implement more than basic export functionality. However, the project would seek to identify the main hurdles that a full implementation would have to overcome, and potentially begin to explore solutions to these problems in the code. A secondary objective is to raise accessibility awareness in the developer community, and to leave behind a clear roadmap for future Braille development that would build on the foundations laid in this project.

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: Peter Jonas (@shoogle)

More realistic tempo playback

Having completed single-note dynamics, I've been thinking about ways we can improve playback.

One thing we could do is to allow the playback of rit. and accel. markings. These would have to be user customisable, for example what tempo to change to and how to interpolate between tempi.

This isn't just limited to these tempo markings, or even just to tempo markings. If you have any other playback improvement ideas, please let me know. I'm sure we can work to implement them as well.

I've worked a lot with playback, so I feel like I could mentor this fairly well :)

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: James Thistlewood (JThistle/TheOtherJThistle)

Realistic MIDI sound

As a composer who would like to use the sounds of MuseScore’s native instruments in the final product, I find it underwhelming that some instruments when transposed become indistinguishable or how multiple percussion instruments share the same sound. Improving and diversifying the sound options of these instrument as well as giving users more freedom to playback with their own sounds would expand music styles used.

This can be achieved by a small UI window which can read in sound and give the user controls for previewing the sound when it is modulated.

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: ???

Albums

The one significant feature that MuseScore 2 had and MuseScore 3 lacks are albums. This feature allowed you to build a larger work from multiple smaller ones. It could be used to build a complete sonata, symphony, or suite from several movements, or a songbook from dozens or even hundreds of individual songs. One reason the feature was eliminated is that it was quite limited - for instance, all component scores needed to have the same instrumentation, and the combined score would have only one global style. It was also pretty buggy.

It's past time to reintroduce this feature into MuseScore 3, and to hopefully improve upon the original implementation.

Difficulty: Medium
Skills: C++/Qt
Possible mentor: Marc Sabatella (@MarcSabatella)

Tree model for libmscore

Items in a tree model can have any number of child items, but they always have exactly one parent item (except the root item, which has no parent item by definition). Musical scores follow this model closely: a note's parent is the measure it belongs to, the measure's parent is its staff, and the staff's parent is the score itself. However, the model breaks down for "spanner" elements like ties. Is the tie's parent the note at the start of the tie or the note at the end? This can be resolved by thinking of the tie as two separate elements: a startTie and an endTie, both of which exist in the model, and a link between them that exists outside the model. Sometimes code can ignore the special cases, while at other times it is necessary to check whether an item is a tie before deciding how to handle it.

Decendants of the "scoreElement" class in libmscore follow the tree model to a certain extent. Every element has a parent element, but there is no generic way to access child elements. For example, you can do element->parent() to get its parent, but you cannot do element->child(n) to get the n-th child. Instead you have to already know what the element and the child are (e.g. chord->stem()). The structure of the score is also different to that described in the previous paragraph. In libmscore, the parent of a measure is the score, not the staff, which limits MuseScore's ability to represent polymeter music (a complex workaround is required). Finally, spanner elements like ties are not treated as described previously, and so fall outside the model. If these issues are corrected then it will massively simplify operations like drawing elements, saving to MSCX (i.e. writing to XML), and handling of polymeter scores. It would also enable us to make use of Qt's item view classes, which provide improved accessibility over the current ScoreView implementation.

• Difficulty: Medium to Hard (depending on how far you get)
• Skills: C++/Qt
• Possible mentor: Peter Jonas (@shoogle)

Selected Ideas

Plugin manager

Student: songchao → Blog
MuseScore functionality can be extended by plugins. Discovering the compatible plugins and installing them however is currently a manual job. The goal is to create an App Store-like Plugin Manager from which it is possible to discover, (un-)install, (auto-)update plugins in an easy manner. The Resource Manager currently used to handle language packs could be extended for this purpose, and indeed already has some bare-bones code for plugins.

Since many (a little of 40%) of the current 2.x plugins are available on GitHub; we should consider using their releases-API for those plugins. At the same time, locally installed plugins must still be listed and integrated as well.
Another matter to address is how to know if a plugin is compatible with the current MuseScore version.

• Difficulty: Medium
• Skills: C++/Qt
• Mentor: Joachim Schmitz (@Jojo-Schmitz)

Chord symbol playback

Student: Peter Hieu Vu → Blog

Playback of chord symbols is a huge can of worms, and MuseScore does not need to be in the business of trying to match the results of iReal Pro or other programs that specialize in generating realistic accompaniment. Still, some basic ability to hear chord symbols would be nice. There has been debate about whether this should actually generate notes on a staff that can be edited or just work in the background, also on what kind of rhythms to use, what kind of voicings, etc. A successful GSoC project would need to be very proactive in getting user input, coming up with a a good design, and then implementing the algorithm.

• Difficulty: Medium
• Skills: C++/Qt
• Mentor: Marc Sabatella (@MarcSabatella)

Improve Instrument Changes

Student: joshwd36 → Blog

The main goal of this project is to streamline the process of adding instrument changes. Currently, most of the functionality does exist in MuseScore, but you have to do every step manually. By the end of the summer, I would like the process changing an instrument to simply be to add an instrument change object, and use the instrument change dialog to select the new instrument.
The end goal is to handle textual hints, transposition and staff type changes automatically based of the chosen instrument.

• Difficulty: Medium
• Skills: C++/Qt
• Mentor: Peter Jonas (@shoogle)

Palette accessibility

Student: AnandHemachandran → Blog

MuseScore's palettes are not accessible to keyboard controls except via the palette search box. This is problematic for users who rely on a screen reader to tell them what is happening on the screen, such as people who are blind or partially sighted. A relatively straightforward solution is to replace each palette with a QListWidget in icon mode, and then enable tab access. However, since each palette is a separate widget, this means a lot of tabbing to get through all of them and back to the searchbox again. A better solution would be to use a QTreeWidget (i.e. a tree view), where the branches are palettes and the leaves are palette elements. However, there is no "icon mode" for tree views in Qt, so there would only be a single column of elements (or a fixed number of columns), which is visually not very efficient. The ideal implementation would make use of Qt's model-view classes, and extend QAbstractItemView to create a "category list view" (i.e. a tree view with an icon mode) where the number of columns is able to change dynamically as the user adjusts the size of the view.

• Difficulty: Medium to Hard, depending on how far you get
• Skills: C++/Qt
• Mentor: Peter Jonas (@shoogle)

Remaining proposals

Your idea

Click the 3 dots button at the top right and "Edit", then copy and paste an idea below and change the text with your new idea for GSoC 2019. Don't forget to remove the mentor's name (unless it's you).

Anybody is welcome to add an idea to the page, but newcomers are encouraged to discuss their idea on the MuseScore developers Telegram channel or via the developer mailing list first. Also check ideas from previous years.

Students

If you are a student keen to take part in GSoC, we strongly believe that the best project for you is the one you are most interested in and therefore most willing to do. It doesn't have to be one of the ones listed on this page; you can suggest your own.

Whichever idea you choose, you should speak to us first to check that it would be manageable before you go to the effort of writing a proposal. This is particularly important if you want to suggest your own project, as we would have to find a suitable mentor.

Check out the steps toward successful application.

Mentors

If you would like to be a mentor for GSoC then feel free to put your name down next to any projects you are interested in and that you think you are qualified to mentor. In order to meet Google's requirements for mentors, only experienced developers with a high level of familiarity with MuseScore's code are eligible. However, non-developers, and developers new to MuseScore, may be able to assist in an advisory role if they have specialist knowledge relevant to the project in question.

Community

Everybody is free to contribute ideas. You are also welcome to follow the progress of the students and offer constructive feedback once the projects are underway.

Post-its for miscellaneous ideas

One feature that MuseScore currently lacks is the ability to jot down and attach notes (annotations) to scores. Having the ability to attach little annotations of musical ideas to different parts of the main score may be beneficial for composers and musicians, as they can keep track of their thought process and come back to old ideas at their leisure. Perhaps the composer has some ideas for a section of music that might work in the context of the entire piece, but the composer hasn't gotten around to fleshing out the new ideas yet or likes another idea better at the moment.

Having the ability to attach little notes at different points in the score is a good way to brainstorm. Also, it could help organize things better than having a new project altogether or keeping a separate music notebook and writing down notes there. The post-its could be color coded, broken down into different sections, etc. Instead of creating scores for performance, musicians could create scores just for brainstorming, and gradually transform the score into a final score when they have enough ideas. The post-its could have the ability to contain text and to test different combinations of chord progressions, voice leading, and instrumentation. There could be bullet points for different musical ideas, color coded as the user desires. With "create post-it" mode enabled, the user could click on a particular point in the score and create a post-it there, and from there the user could write some notes in the little pop-up. The user could then close out and reopen the notes by clicking an icon that been created of a little post-it.

Difficulty: Medium
Skills: C++/Qt
Possible mentor: Marc Sabatella (@MarcSabatella)

Simplified lyric & chord symbols only

A simplified pop/rock input method for making lyrics & chord symbol (and/or chord tab) only scores, without worrying about a staff, melody or rhythm initially, but which would still could be easily updated to include notated melody with rhythm. Maybe using a minimal slimmed-down interface. And if could import basic ascii charts of lyrics chord symbols.

Difficulty: Medium
Skills: C++/Qt
Possible mentor: @ericfont

Diatonic instrument definition

One of the most common requests that is nearly impossible to implement in current versions of MuseScore is diatonic instruments such as the Shamisen and Appalachian Dulcimer. These instruments have a limited number of notes that can be played on a string due to their fret definitions. Current tablature does allow for the limited notes permitted to be played on a string.

I would suggest the instrument definitions be expanded to allow for detailed frets that can be applied to a given string. The definition should limit the actual note that can be played by the instrument and indicate an error similar to the current method if an illegal note is entered on both the standard and tablature clefs.

A possible way to do this is to create an interface that allows for defining new instruments to include string and fret definitions as well as individual notes for instruments such as diatonic harmonicas and accordions among others.

I am not qualified to be a mentor, but I would be more than willing to be a consultant on this project (@mike320), with programming mentoring from @TheOtherJThistle.

Difficulty: Hard
Skills: C++/Qt
Possible mentor: mike320 + James Thistlewood (JThistle/TheOtherJThistle)

Ornaments maker

A common request if for proper playback of ornaments, such as turns and trills with accidentals. There needs to be a framework created to allow the user to define an ornament and have it play back properly in MuseScore. One thing you cannot currently do is apply an accidental to an ornament.

The interface would allow the user to define the ornament, or line in the case of a trill line or prall line, based upon the key of C on a C note. The actual notes played when the ornament is encountered would be a transposition of these notes. So if the user defined a trill with a sharp above it to be played as D#-C-D#-C... (as was done in the baroque era), a trill on an G in a key with 4 or fewer sharps would result in the trill being played as A#-G-A#-G... The user would also be able to define the duration of each note played, allowing in the case of a trill for the notes played to be defined as a set duration such as 16th or 32nd notes according to the requirements of the music. Turns, pralls and so forth should also allow for accidentals to be added under the ornament to allow for defining proper playback of all ornaments used in western music.

I am not qualified to be a mentor, but I would be more than willing to be a consultant on this project (@mike320), with programming mentoring from @TheOtherJThistle.

Difficulty: Hard
Skills: C++/Qt
Possible mentor: mike320 + James Thistlewood (JThistle/TheOtherJThistle)

Keyboard real-time input

Author: @anatoly-os

I wish we could use keyboard (not MIDI-keyboard) for convenient real time note input. The focus of the project is composers who create music from scratch.

I will add the video which show the idea later.

When creating music, we usually have some melody in mind and want to express it with simple combination of notes and its duration. Real time input starts with the default tempo and fills the rests with notes specified by user. It is not necessary to hold letters (A-G) to enter the duration, the input mode fills the beats with the previously added note until rest or following note key will be pressed.

You still need to use letters to specify a pitch, but duration is set depending on how long you hold the button. It is like you are playing piano, but playing "keyboard" instead. So, there is a metronome, which counts the rythm. And you press and hold buttons to create a melody.

Difficulty: Hard
Skills: C++/Qt
Possible mentor: anatoly-os

Lyrics editor

As described here and partially implemented here, the Lyrics Editor would display all lyrics from the score as plaintext in an editable multiline text field. The contents of the text field would be doubly linked with the score, meaning that a change to lyrics in either the score or the Lyrics Editor would be reflected in the other. Users would be able to search for lyrics online and paste them into the lyrics editor, or copy lyrics from the editor to produce lyric booklets for choirs and church services. A more advanced implementation would use a tree view where each lyrics verse is represented by a branch in the tree.
Possible extensions: spell-checking, automatic hyphenation, verse extraction.

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: Peter Jonas (@shoogle)

Palette shortcuts

Another way to improve palette accessibility (and general usability for all users) is to allow the user to define keyboard shortcuts for individual palette elements. For example, the user might want to press Alt+D to enter a key signature of D major, or Ctrl+T to add a trill, etc. There could be an option to set shortcuts in the context menu that appears when you right-click on a palette. If the user tries to set a shortcut that has already be defined for another palette element then a warning should be displayed. An improved implementation would also check for conflicts with the shortcuts set in the main Preferences dialog. An ideal implementation would allow shortcuts defined anywhere in the program to be dynamically registered with the central list of shortcuts displayed in the main Preferences dialog, so that all shortcuts could be set and unset in one place, and to guarantee that conflicts are avoided (c.f. the Plugin Manager allows the user to define shortcuts to run plugins, but there is no collision detection with shortcuts defined elsewhere).

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: Peter Jonas (@shoogle)

Command macros

In some engraving situations, it is useful to apply several commands to a single object. One case like this is if you want to add a end/begin repeat barline. You want to add an end repeat and a start repeat to the same barline. It could be useful to create a framework to allow users to create their own macros stringing more than one command together. A macro can then be applied with a single click or keyboard shortcut.

• Difficulty Medium
• Skills C++/Qt
• Possible mentor: Louis Cloete (@Louis Cloete)

Chord symbol style editor

MuseScore supports the entry of chord symbols like Gm7, C7b9, etc. It has a pretty flexible system for entering the chords, where you can type pretty much a human musician might understand and MuseScore will do its best to understand it as well. However, there are only limited controls for actually displaying the chord symbol. MuseScore provides two preset options - Standard and Jazz - and does not allow you to customize, for instance, how large the "G" should be relative to the "m" or the "7" in Gm7, or how much subscripting should be applied to the "b9" in C7b9. There was some preliminary work done on an editor years ago that could be leveraged in producing a more complete facility. There are also some improvement that could be considered in how chord symbols are handled with respect to transposition, linked parts, fretboard diagrams, capo, Nashville notation, MIDI import, MusicXML, etc.

• Difficulty: Medium to Hard
• Skills: C++/Qt
• Possible mentor: Marc Sabatella (@MarcSabatella)

Text editing improvements

Text in frames and elsewhere currently allows for some basic formatting options, but lacks many capabilities one would want in order to do any serious text editing, like to create educational materials with significant text between the musical examples. While we would likely not ever compete with word processors, merely implementing word wrap, justification, and a few other controls could go a long ways toward allowing users to create documents completely within MuseScore.

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: Marc Sabatella (@MarcSabatella)

Page layout controls

MuseScore provides a number of global controls over page layout - you can set the page size and margins, staff size, control distance between staves, hide empty staves, etc. There are certain overrides possible like staff spacers to change the distance between two staves, and the staff type change element to change certain properties for individual staves mid-score. However, sometimes there is still a need to for more control - override global settings for individual pages, or particular systems. You cannot have the overall staff size or default staff distance slightly smaller on one page than another, or change between percussion and pitched on a single staff, or designate certain systems to not hide empty staves, not fill to the right margin, etc. Also, we provide measure spacing controls per-measure, but no easy way to say "fit the following measures on one system".

This project would involve an investigation of how we might best expose controls like this to the user and then to design and implement the facility.

• Difficulty: Hard
• Skills: C++/Qt
• Possible mentor: Marc Sabatella (@MarcSabatella)

Repeat-related symbols

The two-measure repeat sign with working playback has been one of the most-requested features ever, as is evident by the number of forum requests and length of this issue #10220: Add a two and four measure (multi-measure) repeat sign with playback at 164 replies and going back 8 years. This project would involve coding various multi-measure and related features, like

• two-measure repeat
• old style multi-measure rests
• repeat previous bar N times markings

• automatic counting of repeated measures

  • Difficulty: Medium
  • Skills: C++/Qt
  • Possible mentor:

Braille export

This project would add Braille music notation to the list of formats available via File > Export. Prior knowledge of Braille music notation is not required as the basic rules are fairly straightforward and can be picked up in the early stages of the project. As with everything, the specifics of Braille music notation do get quite complicated and can even vary from country to country, so the student would not be expected to implement more than basic export functionality. However, the project would seek to identify the main hurdles that a full implementation would have to overcome, and potentially begin to explore solutions to these problems in the code. A secondary objective is to raise accessibility awareness in the developer community, and to leave behind a clear roadmap for future Braille development that would build on the foundations laid in this project.

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: Peter Jonas (@shoogle)

More realistic tempo playback

Having completed single-note dynamics (coming in 3.1, hopefully), I've been thinking about ways we can improve playback.

One thing we could do is to allow the playback of rit. and accel. markings. These would have to be user customisable, for example what tempo to change to and how to interpolate between tempi.

This isn't just limited to these tempo markings, or even just to tempo markings. If you have any other playback improvement ideas, please let me know. I'm sure we can work to implement them as well.

I've worked a lot with playback, so I feel like I could mentor this fairly well :)

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: James Thistlewood (JThistle/TheOtherJThistle)

Guitar griff

The idea is simple. We want to improve guitar players experience, so we want to show guitar griff with 6 strings and visualise the frets on it. See an example in GuitarPro or TuxGuitar: https://www.youtube.com/watch?v=NU_FRFmJ3D4.

• Difficulty: Medium
• Skills: C++/Qt
• Possible Mentor: anatoly-os/cadiz1

Realistic MIDI sound

As a composer who would like to use the sounds of MuseScore’s native instruments in the final product, I find it underwhelming that some instruments when transposed become indistinguishable or how multiple percussion instruments share the same sound. Improving and diversifying the sound options of these instrument as well as giving users more freedom to playback with their own sounds would expand music styles used.

This can be achieved by a small UI window which can read in sound and give the user controls for previewing the sound when it is modulated.

• Difficulty: Medium
• Skills: C++/Qt
• Possible mentor: ???

MuseScore is part of Google Summer of Code (GSoC) 2018! If you are a student and you have aspirations to help improve the open source MuseScore notation software during the summertime, this is a unique opportunity to work together with the MuseScore developers and get paid for it. Learn how GSoC works and read through the student manual

If you are considering applying, we have a list of ideas you can choose from. We'd love if you apply with your own idea. Don’t hesitate to contact the potential mentors from the ideas list via MuseScore's Join GSoC 2018 forum page, via the developer mailing list, or by chatting on IRC (#musescore on freenode.net, but be aware that mentors aren't awake at all hours of the day). We also have a document listing the Steps Toward a Successful Application, make sure to read it!

Don't let yourself be scared off by the knowledge prerequisites; you don’t need to be an expert in all domains, and there is some time for learning within the GSoC period. However, familiarity with Qt/C++ and interest in music and music notation will be helpful. If you still have doubts, read Am I good Enough?

Resources:

• Application Template
• GSoC 2018 official website
• GSoC Student Guide
• MuseScore developer handbook
• Ideas for GSoC 2018
• Steps Toward a Successful Application

Update: Google Summer of Code 2017 is over. Read about an intermediate state of GSoC 2017 (a final report hasn't been written).

MuseScore is part of Google Summer of Code (GSoC) 2017! If you are a student and you have aspirations to help improve the open source MuseScore notation software during the summertime, this is a unique opportunity to work together with the MuseScore developers and get paid for it. Learn how GSoC works and read through the student manual

If you are considering applying, we have a list of ideas you can choose from. We'd love if you apply with your own idea. Don’t hesitate to contact the potential mentors from the ideas list or contact us via IRC (#musescore on freenode.net), via the developer mailing list. We also have a document listing the Steps Toward a Successful Application, make sure to read it!

Don't let yourself be scared off by the knowledge prerequisites; you don’t need to be an expert in all domains, and there is some time for learning within the GSoC period. However, familiarity with Qt/C++ and interest in music and music notation will be helpful. If you still have doubts, read Am I good Enough?

Resources:

• Application Template
• GSoC 2017 official website
• GSoC Student Guide
• MuseScore developer handbook
• Ideas for GSoC 2017
• Steps Toward a Successful Application

Update: Google Summer of Code 2016 is over. Read all about the results of GSoC 2016.

MuseScore is part of Google Summer of Code (GSoC) 2016!

.

Applications are now over and Google announced the selected students. MuseScore has 4 students.

Improving default playback

Johannes Wegener (hpfmn) will improve the default playback of MuseScore by updating our SF2 synthesizer (Fluidsynth) and improving our new SFZ synthesizer (Zerberus). Goals are updating fluidsynth to include features and fixes that went into upstream since the fork, adding legato support to fluidsynth (likely via Midi CC68), adding midi CC11 support to midi rendering (for rendering single note/chord (de)crescendo) and overall add a lot more opcodes to zerberus (mainly looping support and ADSR). Johannes will be mentored by Werner Schweer (wschweer).

Johannes' fork of MuseScore on GitHub: https://github.com/hpfmn/MuseScore
Johannes' blog for GSoC 2016: https://musescore.org/en/user/527826/blog/

Semi-Realtime MIDI note entry

Peter Jonas (shoogle) will implement a new method of entering notes into MuseScore via computer/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 the computer as though they were giving a live performance, with additional steps taken to ensure the accuracy of the resulting notation. This should make the process of entering notes significantly faster. Peter will be mentored by Nicolas Froment (lasconic).

Peter's fork of MuseScore on GitHub: https://github.com/shoogle/MuseScore
Peter's blog for GSoC 2016: https://musescore.org/en/user/57401/blog

Annotations

Ruchit Agrawal (shredpub) will add tools to enable annotations within a score in MuseScore. These annotations could be textual or graphical, and would be very helpful in music education settings as well as for practice purposes. His will be mentored by Marc Sabatella.

Ruchit's fork of MuseScore on GitHub: https://github.com/shredpub/MuseScore
Ruchit's blog for GSoC 2016: https://musescore.org/en/user/61850/blog

GSoC 2016: voice to part tool and extended Implode/Explode tool

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).

Felix's fork of MuseScore on GitHub: https://github.com/Rockettwo/MuseScore
Felix's blog for GSoC 2016: https://musescore.org/en/user/124871/blog/

Resources:
* GSoC 2016 official website
* GSoC Student Guide
* MuseScore developer handbook
* IRC (#musescore on freenode.net)
* developer mailing list

Update March 2nd: Unfortunately MuseScore was not accepted for the 2015 edition of GSoC. We'll try again next year!

Your proposal

We strongly believe that the best proposal for you is the one you'll do. If you have any suggestions, come onto the IRC channel #musescore on freenode.net, or contact us on the developer mailing list.

Also check ideas from previous years

Copy paste an idea below and change the text with your new idea for GSoC 2015

Virtual singer

Several users have requested a virtual singer in MuseScore. This feature would make MuseScore sing the lyrics in a score. It's useful for singers in choirs who like to rehearse with actual synthesized lyrics.

There are several specialized (open source) software projects and libraries which do "sing synthesis".

• See this message on the developer mailing list with several interesting links
• Harmony Assistant has a virtual singer plugin
• Vocaloid. The software is very popular in Japan, where one of the voices of the software and the virtual character on the software box, Hatsune Miku, has even made large concerts.
• A free competitor is Utau. The license of UTAU is unclear to me.
• On the same topic, see Cadencii, Aquestone VSTi, Cantor2, Realitone Blue
• WORLD seems to be a good open source start
• Festival, the open source text to speech engine has a singing mode. See also this
• Flite and Flinger based on Festival
• An attempt using a now closed web API named Canoris and MuseScore
• Sinsy, an open source MusicXML to singing voice converter, working only for Japanese.

An external tool that could process a MIDI, or MusicXML file created by MuseScore and make an audio file would be good for singers to practise along.

• Difficulty: Hard
• Skills: C++/Qt
• Possible mentor: Nicolas Froment (@lasconic)

Explorer/Finder plugins to display scores information

MuseScore 2.0 now saves a thumbnail of the first page in the MSCZ file. A plugin for the different OS file explorer (Windows, Mac OS X, others) could use this thumbnail and maybe other metadata to make the display of scores better looking.

• Difficulty: Medium
• Skills: C++ ?
• Possible mentor: Nicolas Froment (@lasconic)

Context-sensitive help

Learning how to use MuseScore can be pretty challenging. A way to lower the barrier is by adding a context-sensitive help system which works in two ways. One way is to directly obtain explanatory information about any widget you come across in the UI. The other way is to perform a keyword search which directly jumps you straight where you need to be in the UI. Mac OS offers a Spotlight For Help search field,, but not only does this need to work for all platforms and it also needs to work for the menu, toolbars, popup and docked windows and the palette.

• Difficulty: Medium
• Skills: Qt
• Possible mentor: Werner Schweer

OMR

Many users use MuseScore to transcribe scores from paper. This project would be about aiding this use case by providing a side-by-side view of the digital score and a scanned score. A very limited implementation of this project (see screencast) has already been coded (see github) but much more work is needed to make it ready for general usage.

• Difficulty: Hard
• Skills: Qt
• Possible mentor: Werner Schweer

Timeline

When a score is growing, it's sometimes hard to know where you are located in the score, which part you worked on already etc... The idea would be to create a new panel, potentially to replace the navigator, which gives an abstract view of the score, showing squares for each measure on each instrument, with a different color if the measure is empty or not. Potentially, having one row for rehearsal mark, for tempo markings, time signatures, key signatures etc...

• Difficulty:Medium to Hard
• Skills: Qt
• Possible mentor: ...

Keyboard layout and shortcut management

Many shortcuts in MuseScore do have conflicts due to different international keyboard layouts. Example of such a conflict can be found with the French keyboard. To solve this problem, MuseScore needs a system which can detect the client keyboard layout and auto select the appropriate shortcut list. The developer challenge is to make this work for all international keyboard and if needed create for each of them a custom shortcut list. Additional challenges are the differences between Mac OS X and Windows/Linux. See #47361: [Mac OS X] Insert measure keyboard shortcut doesn't exist
More related issue:
* http://musescore.org/en/node/48846

• Difficulty: Medium
• Skills: Qt
• Possible mentor: ...

Chord symbols playback

It's currently possible to add chord symbols on top of a staff in MuseScore. These symbols are ignored on playback. It's a frequent feature request to be able to realize these chord symbols as notes in a staff or to optionally "play" the symbols while listening the score. A simple implementation would just play the chord for the whole duration of the measure or until the next chord symbols.

• Difficulty: Easy - Medium
• Skills: Qt
• Possible mentor: Marc Sabatella

MuseScore has been selected for Google Summer of Code 2014 and has been allocated five students to work on

• Accessibility with focus on visually impaired musicians
• More flexible selection facility
• Enhancing and Testing the Import of Guitar Pro Files
• Implementation of full JACK support
• Swing Playback

Read all about the results of GSoC 2014.

MuseScore was selected for Google Summer of Code 2013 and was allocated two students to work on:

• MIDI import improvements
• MuseScore and Emscripten

Read all about the results of GSoC 2013.

Your proposal

We strongly believe that the best proposal for you is the one you'll do. If you have any suggestions, come on IRC channel #musescore, or contact us on the developer mailing list

Instrument Editor

• read instrument description files (done)
• build a GUI to display and edit all instruments
• show list of instruments
• display all attributes of currently-selected instrument
• make all attributes editable
• create new instrument, use currently-selected instrument as a starting point
• remove instrument
• change currently-selected instrument
• save instrument descriptions
• save as

Difficulty: Easy to Medium
Skills: C++ / Qt. No detailed knowledge of MuseScore internals is required, except for the InstrumentTemplate class usage. The code is mostly independent of MuseScore core development.
Estimated LOC required is 4000.
Possible mentor: lasconic

Beam mode editor

A UI to edit the rules of beam groups and a way to assign the rules to measure, staff etc... similar to time signature (measure based, different by staff)

Difficulty: Moderate
Skills: C++ / Qt. A bit of knowledge of MuseScore internals.
Possible mentor: lasconic

Symbol Editor

Create an editor for MuseScore specific graphical symbols which are in SVG format.
A specialized (simplified) variant of this project is to create an editor for note heads.

Difficulty: Moderate to Hard
Skills: C++ / Qt. Requires some knowledge of MuseScore internals.

Integrate Breakpad

What is BreakPad
"Breakpad is a library and tool suite that allows you to distribute an application to users with compiler-provided debugging information removed, record crashes in compact "minidump" files, send them back to your server, and produce C and C++ stack traces from these minidumps. Breakpad can also write minidumps on request for programs that have not crashed. Breakpad is currently used by Google Chrome, Firefox, Google Picasa, Camino, Google Earth, and other projects."

Difficulty: Moderate to Hard
Skills: C++ / Qt
Possible mentor: lasconic

Your proposal

We strongly believe that the best proposal for you is the one you'll do. If you have any suggestion pass by the IRC channel #musescore or contact us on the developer mailing list

Implement a plugin manager in MuseScore

See plugin manager

• Define a plugin package and write documentation for plugin developers
• Create interface in MuseScore to list, install, uninstall plugins
• Need to deal with security
• Bonus: Update and compatibity management

Difficulty: Moderate to Hard
Skills: C++ / Qt
Possible mentor: lasconic

Offer self installable language packs on musescore.org

MuseScore software is translated in more than 20 languages thanks to the drupal based site at http://translate.musescore.org The languague files are provided as qm file on this website, but fur a lot of users it would be more convenient to download an auto installable language file.
Difficulty: Moderate
Skills: Depending on your proposition C++ / CMake / NSIS
Possible mentor: lasconic

Setup automated testing

MuseScore being an interactive software, it needs UI testing to improve his stability. MuseScore community has setup a wiki page to gather information about this topic. Your role will be to choose the right tool, write testing scenarii etc...
Difficulty: Moderate to hard
Skills: Depending on your proposal
Possible mentor: david

Improve MIDI file import

Improvements in this area could include:

• Triplet handling
• Voice and staff separation

Difficulty: Hard
Skills: AI, C++, Music
Possible mentor: werner
Additional information: Current state of MIDI import by Kevin Hylee.

Enhance the Audio Widget Library for better user experience

The Audio Widget Library contains the controls for Volume, Mixer etc... Users will benefit a more usable and good looking set of controls.
Difficulty: Easy
Skills: C++, Qt, ergonomy
Possible mentor: lasconic

Your proposal

We strongly believe that the best proposal for you is the one you'll do. If you have any suggestion pass by the IRC channel #musescore or contact us on the developer mailing list

Add fretboard & tabstaff support in MuseScore

Difficulty: Hard
Skills: C++ / Qt graphics, guitar theory
Possible mentor: Werner
Status: Fretboards partially implemented in development builds for MuseScore. See http://musescore.org/en/node/5262#comment-17026 Implemented

Extend the Qt Script based plugin framework

The plugin framework is still very young but there are already some plugins. Plugin developers have a lot of ideas to bring more features to MuseScore.
Difficulty: Moderate
Skills: C++ / Qt
Possible mentor: lasconic
Status: Implemented

Implement a plugin manager in MuseScore

See plugin manager

• Define a plugin package and write documentation for plugin developers
• Create interface in MuseScore to list, install, uninstall plugins
• Need to deal with security
• Bonus: Update and compatibity management

Difficulty: Moderate to Hard
Skills: C++ / Qt
Possible mentor: lasconic
Status: Implemented

Offer self installable language packs on musescore.org

MuseScore software is translated in more than 20 languages thanks to the drupal based site at http://translate.musescore.org The languague files are provided as qm file on this website but a lot of users it would be more convenient to download an auto installable language file.
Difficulty: Moderate
Skills: Depending on your proposition C++ / CMake / NSIS
Possible mentor: lasconic

Automated upgrade of MuseScore

In MuseScore 0.9.6, a automated check for upgrade has been added. For next version, users would be able to check for update, download the upgrade package, install it and restart MuseScore
Difficulty: Moderate to hard
Skills: C++
Possible mentor: thomas_
Status: Implemented

Setup automated testing

MuseScore being an interactive software, it needs UI testing to improve his stability. MuseScore community has setup a wiki page to gather information about this topic. Your role will be to choose the right tool, write testing scenarii etc...
Difficulty: Moderate to hard
Skills: Depending on your proposal
Possible mentor: david

Improve MIDI file import

Improvements in this area could include:

• Triplet handling
• Voice and staff separation

Difficulty: Hard
Skills: AI, C++, Music
Possible mentor: werner

Enhance the Audio Widget Library for better user experience

The Audio Widget Library contains the controls for Volume, Mixer etc... Users will benefit a more usable and good looking set of controls.
Difficulty: Easy
Skills: C++, Qt, ergonomy
Possible mentor: lasconic

Play progressive dynamic and tempo changes

Currently MuseScore plays dynamic and tempo changes but can't deal with ritardando or crescendo
Difficulty: Easy to Hard depending on the proposal
Skills: C++, Qt
Possible mentor: lasconic
Status: Partly implemented (crescendo but not ritardando)

So, you want to help develop and improve MuseScore?

Welcome to a passionate and dedicated team of volunteers from around the world.

This is how it generally works:

If you see an area that could benefit from improvement, then jump right in!

• There are a number of issues that have been identified as a good entry point for beginners here.
• If you become unsure, ask questions.
• If you are about to make a significant, or potentially controversial change, discuss it beforehand.
• Share your improvements early and openly. That way, people can let you know if you're on the right track.

See How to write a good bug report: step-by-step instructions

Note: This page is from 2010 and out of date. Nightly builds can be downloaded from https://musescore.org/en/download#Nightly-versions. If want to run in "debug" mode, execute MuseScore from a terminal with " -d" as a command line option . However, this doesn't print out all the qDebug messages. If you want that, you will have to self compile MuseScore: https://musescore.org/en/developers-handbook/compilation.

A special "debug" version of MuseScore displays messages about each step that is happening inside the software. It can be useful for finding the source of bugs or problems with the software. The instructions below show how to use a debug version that is pre-built.

Important: the debug version is not a stable release and is only intended for testing a specific problem. Please use other versions of MuseScore for creating or editing normal scores.

Instructions for Windows

Download the "debug" version of MuseScore.
http://prereleases.musescore.org/windows/nightly/mscore-debug.7z

After you download the file, you will need to decompress the file using 7-Zip (as explained on the Windows nightly builds page ).

When the "debug" version is running it displays detailed information in a separate window called a "command prompt". The "command prompt" usually appears as a small window with white text on black background.

1. Open the uncompressed "mscore-debug" folder
2. Double-click "runDebug.bat". This should open the main MuseScore window and the debug window
3. Follow the exact steps that are causing problems for you in MuseScore and then choose File > Quit

The command prompt should remain open after you close the main MuseScore window. It is sometimes helpful to share the contents of the command prompt text when discussing a bug. However, the text is often lengthy so it is probably best to only share it if requested or if you notice something important. Copying text from the command prompt is different from any other program in Windows so the remaining steps describe this procedure.

1. Right click on the command prompt window and choose "Mark"
2. Click and drag to select the text. Make sure you get all the text
3. Press Enter. The text is now copied
4. You can now paste this text in other programs via the normal methods (Edit > Paste)

This page is a duplicate of Command line options in the MuseScore 2 Handbook (actually the other way round), which is outdated and wrong. A more complete and correct version is in Command line options of the MuseScore 3 handbook

You can launch MuseScore from the command line by typing

mscore <options> <filename>

<options> and <filename> are optional.

The following options are available

-v

Displays the current version and revision numbers for MuseScore (Linux only)

-d

Starts MuseScore in debug mode

-D

Enables the plugin script debugger

-s

Disables the integrated software synthesizer

-m

Disables MIDI input

-n

Starts with the new score wizard regardless of preference setting for start mode (0.9.6 or later)

-L

Starts MuseScore in debug layout mode

-I

Displays all MIDI input on the console

-O

Displays all MIDI output on the console

-o <filename>

Exports the currently opened file to the specified <filename>. The file type depends on the filename extension. This option switches to the "converter" mode and avoids any graphical interface. You can also add a filename before the -o if you want to import and export files from the command line. For example mscore "My Score.mscz" -o "My Score.pdf"

-r <dpi>

Determines the output resolution for the output to "*.png" files in the converter mode. The default resolution is 300 dpi

-S <style>

Loads a style file; useful when you convert with the -o option

-p <name>

execute named plugin

-F

Use only the standard built-in presets or "factory-settings". For details, see Revert to factory settings

-e

Enable experimental features

-i

Load icons from the file system. Useful if you want to edit the MuseScore icons and preview the changes

-w

writeWorkspaceFile and converterMode

-c <pathname>

set config path

-t

enable Test Mode

-a <driver>

use audio driver: jack alsa pulse portaudio

Qt Toolkit Options

-style = style

Determines the style of the GUI application. Possible values are "motif", "windows" and "platinum". Depending on the platform other styles may be available

-style style

As above

-stylesheet = ss

Sets the application stylesheet. The value of "ss" is a path to a file that contains the stylesheet

-stylesheet ss

As above

See Translation instructions.

Welcome to MuseScore development news and digest blog

[2020-01-25]

FYI, processing scores on server was broken with 3.4 update. We had to create separate branch with the hotfix from pr #5639 (thanks to Howard!). Now, we are preparing hotfix update 3.4.1 and going to roll out it later today to prevent further bug reports asap

[2019-12-03]

We decided to revert the changes to the MuseScore_General soundfont due to the regressions.

Current soundfont version is 0.1.6.

[2019-03-06]

To collect artifacts from AppVeyor, add "collect_artifacts" to the commit message title. Read more

[2019-02-15]

AppVeyor updated Windows images. We are now able to build Windows packages of MuseScore 3 with Qt 5.12.

Thanks to @shoogle's PR, we now have both 32 and 64-bit nightly builds of MuseScore 3 based on Qt 5.12.

[2019-02-14]

We do have known issues with our CDN provider, so we temporarily switched all links to GitHub URLs. If you are not able to download the update or the package is incorrect, please download the packages directly from GitHub:

• Windows
• Linux
• MacOS

[2018-11-23]

We again exceeded maximum allowed artifact storage size on AppVeyor. Sent the request to AppVeyor's support.
This is the reason of failed AppVeyor checks.

FIXED at UTC 12:22

[2018-10-30]

Alpha 2 is very close to its release state.
We applied new categories in the issue tracker (see https://musescore.org/en/node/277397).

GSoC 2018 Project "Score Diff Tool" was merged to master. Welcome testing!

[2018-10-26]

A lot of pending PRs were merged yesterday including GSoC 2018 Project "Tours"

[FIXED] There is a known issue that Tour widget appears before closing Start Center window. We are working on the fix.

[2018-10-05]

As you probably know, we changed the file format to make Diff Tool work.
The last available builds which can open the old files from development version are:

• Linux
• Windows
• Mac

If you are testing issues in the tracker or you need to update your own files:

• Open the MuseScore version mentioned in the downloading links above
• Open old file you want to convert
• Save (or Save As) the file

After saving, the file can be opened in recent development builds as well as in all further alpha/beta/release versions.

[2018-09-20]

More than 1000 new users tried 3.0 alpha! Welcome aboard, brave people. :)

We changed the MuseScore file format a month ago to facilitate the introduction of a new tool: a scores comparator which shows the diff between two scores. From now on, you cannot open files created in early 3.0 development versions, so to use your files, open them in 3.0 alpha build and select "Save As... new file".

[2018-09-13]

We updated the authorization engine on the website which may affect different user scenarios related to personal settings.
Should you find something is broken, please let us know.

[2018-09-12]

MuseScore 3.0 alpha announced!

Highlight of the day:

• Werner is implementing optimized algorithm for collision detection. You can check out the actual (pretty good) state on Windows 64-bit, Mac and Linux 64-bit.

[2018-09-11]

We again exceeded maximum allowed artifact storage size on AppVeyor. Sent the request to AppVeyor's support.

UPD: AppVeyor increased the limit for us.

[2018-09-10]

Created new 3.0alpha branch based on the current master.
If you already did a checkout of the previous 3.0alpha branch, please force a new checkout with the recent changes.

[2018-09-09]

Reviewed all existing pull requests.
Closed outdated and already fixed ones.

Added new label "Priority" to define PRs which are aligned with the current most requested features.

[2018-09-08]

We made good progress and will keep working on the following issues organized in epics which are mostly about positioning elements and text:

• Positioning of the text in the layout
• Issues related to tempo elements including playback issues
• Displaying elements of the scores created in 1.X versions of MuseScore
• Displaying and positioning elements of the scores created in 2.X versions of MuseScore

We mostly finished solving issues related to continuous view and text editing:

• Text editing issues
• Continuous view related issues

[2018-09-06]

3.0alpha branch has been created.

We are preparing a MuseScore 3.0 public alpha release. Links to the packages are going to be put on the download page. This release is supposed to show the current state and the significant progress in 3.0 development as well as attract more users to test the editor.

All pull requests must be created against master as usual.

This generic guide covers the steps to build MuseScore that are the same on all platforms. See the platform-specific guides for details that only apply to your platform.

Note to editors: Please do not duplicate information on this page in the specific guides. Where information is already given in multiple guides consider moving it to this page instead.

Prerequisites

Install Git and follow the steps in Git Workflow to get MuseScore's code repository on your machine.

Install CMake, Qt, and the other depedencies (or you can try to compile without them and then install them as needed based on error messages you see in the terminal).

All programs must be installed to a location mentioned in your PATH environment variable.

Basic steps

Once you have MuseScore's code and dependencies on your machine, the steps to compile are the same as for any CMake project. The following commands work on all platforms (Windows, macOS, Linux) and in all shells (Bash, PowerShell, CMD, etc.). Subsequent sections of this guide go into more detail about what the commands actually do.

mkdir my_build_dir                              # 1. Create build directory
cd my_build_dir
cmake .. -DCMAKE_INSTALL_PREFIX=my_install_dir  # 2. Configure (Mac: add `-GXCode`)
cmake --build .                                 # 3. Build
cmake --build . --target install                # 4. Install (optional)

These commands are likely to fail the first time you try. Pay attention to error messages displayed in the terminal output as they give clues about how to proceed.

Note to developers: Please ensure that error messages include information about what the problem is and also how to fix it. This reduces the need for people to rely on a written tutorial.

1. Create build directory

mkdir my_build_dir
cd my_build_dir

The build directory is where compiled code will go. You can name the build directory whatever you like.

Tip: You can create multiple build directories for different configurations of the project (e.g. different platforms, compilers, git branches, or build types such as Release and Debug). This saves having to do a clean build every time you switch configuration.

2. Configure

cmake .. -G[generator] -D[option]=[value]  # configure

During the configure step, CMake reads build rules from the top-level CMakeLists.txt and uses them to generate a native build system. This is just a new set of build rules that will work with whichever operating system, processor architecture, compiler toolchains, and IDE you happen to be using.

Note: Build rules are also taken from other CMakeLists.txt and *.cmake files in subdirectories mentioned in the top-level file.

CMake Generators

By default, CMake tries to guess which native tool you want to build with. If you want it to generate code for a different tool then you can tell it to do so using the -G[generator] option at the configure stage. On macOS, only the XCode generator is currently supported, so you must use it as follows:

cmake .. -GXCode -D[option]=[value]  # configure for XCode (only on macOS)

On other platforms you can use any available generator, or you can leave out the -G option to make CMake use the default one.

The CMake manual has a list of all generators and cmake --help will show the ones that are available on your system.

CMake Variables

You can pass options and variables to the configure step using the -D[variable]=[value] syntax. For example:

cmake .. -DCMAKE_INSTALL_PREFIX=my_install_dir  # configure with variable

This sets the CMake variable CMAKE_INSTALL_PREFIX to the value my_install_dir, which means that during the install step the compiled binary and accompanying resources (fonts, translations, templates, etc.) will be copied to a directory called my_install_dir inside your build directory.

Built-in variables

CMake's online documentation has a complete list of built-in variables. Here are some of the key ones:

• CMAKE_INSTALL_PREFIX - directory to install the compiled program and accompanying resources.
  • The default locations are /usr/local on UNIX and C:/Program Files/${PROJECT_NAME} on Windows, but it's a good idea to use a relative path instead as this avoids the need for root/admin privileges during the install step.
• CMAKE_BUILD_TYPE - whether to create a Release or a Debug build.
  • Developers usually set this to Debug because Release discards symbols necessary for debugging. Windows users might prefer RelWithDebug as this enables optimisations that increase performance while still retaining debug symbols.
• CMAKE_MAKE_PROGRAM - full path to native build tool (or just the tool's name if it's in PATH).
  • You don't have to set this unless the tool has a non-standard name or location. MinGW users must set it to mingw32-make.exe.

Project variables

MuseScore defines it's own options and variables mostly in the top-level CMakeLists.txt. Examples:

• BUILD_64 - Enable 64 bit builds.
  • Default is ON. Has no effect except with MSVC on Windows.
• MSCORE_INSTALL_SUFFIX - string to append to the name of the mscore binary to prevent conflicts.
  • Has no effect except on Linux where MSCORE_INSTALL_SUFFIX=foo would give mscorefoo.
  • Default value is "" (i.e. the empty string) so binary is just called mscore.
  • Use values that start with -portable to enable AppImage builds on Linux.

Project variables are set on the command line with the -D option in the same way as other CMake variables:

cmake .. -DBUILD_64=OFF  # configure with option

If you need to call CMake with lots of options then you could create a shell script or batch file to make it easy to run the same commands again in the future. You may notice that there are some scripts in repository root folder that do this already (see the Makefiles and msvc_build.bat). These are provided as a convenience, but it is better to avoid them and write your own if you can. CMake's purpose is to abstract the build process so that it is the same on all platforms. Providing a separate script for each platform undermines this purpose and discourages developers from learning how to use CMake properly.

3. Build

cmake --build .  -j[CPUs]

During the build step, CMake runs the native build tool on the generated build system. This compiles the C++ code and creates the mscore binary.

Note: You could run the native tool yourself by calling make, xcodebuild or MSBuild.exe directly, but then you'd have to learn how to use that tool and all the options it takes. Fortunately, CMake provides the handy --build option that calls the native tool for you with all the right options.

Parallel builds

CMake 3.12 and later versions have a -j[number] option to set the number of build jobs to launch in parallel. For the shortest build time, set the number equal to the number of CPU cores available on your machine. Alternatively, you can set the environment variable CMAKE_BUILD_PARALLEL_LEVEL.

4. Install

cmake --build . --target install

During the install step, CMake again run the native build tool on the generated build system, but this time it specifically tells the tool to build the install target. The install target copies the compiled binaries and accompanying resources to the install directory specified in the configure step.

If you attempt to install to a system folder such as /usr/local or C:\Program Files then you will need to run the install command as root/admin privileges. This means using sudo on Unix or running from an Administrator prompt on Windows.

Note: CMake 3.15 and later versions have a dedicated --install option that does the same thing, but you can still use the old syntax if you prefer.

cmake --install .  # install with CMake 3.15 or later

Installing the project is optional. You can run the compiled mscore binary without installing it first but you won't be able to load the soundfont or templates untill you install.

Subsequent builds

You'd need to recompile the project whenever the code changes, but you don't have to go through all the steps from the beginning. You can usually get away with just running the build and install steps on subsequent builds. This applies even if you edit one of the CMakeLists.txt or *.cmake files; the build system will detect this during the build step and then rerun the configure step automatically.

Incremental builds

The build system CMake generates is clever enough to only recompile code files that have actually changed. This is known as an incremental build.

Clean builds

Occasionally it may be necessary to start again from scratch. This is known as a clean build. You have to do this if you want to use a different compiler, and you might find that it fixes other problems too.

You can use either of the following commands from within the build directory to clean it:

cmake --build . --target clean  # clean (i.e. delete compiled binaries)
cmake --build . --clean-first   # clean and then build

Alternatively, you can simply create a new build directory and run the configure step from inside it. Make sure you delete any old build directories that you no longer need because they take up quite a lot of space.

Note: These instructions are for building MuseScore using the Microsoft Visual Studio 2019 (VS) integrated development environment with the Microsoft Visual C++ (MSVC) compiler. If you are familiar with the QtCreator IDE or want a better experience editing .ui files, see the instructions for Qt Creator and MSVC instead.

Maintainers: This guide is currently valid for Visual Studio 2019. Please update it for future VS versions rather than creating a new one.

1. Prerequisites

You will need the MuseScore source code, as well as several programs and libraries, to be able to build MuseScore with Visual Studio.

1.1 MuseScore source code

• Check out the MuseScore source code (see the suggested workflow).
• Make sure that the path to your MuseScore checkout folder:
  • isn't too long;
    • Long paths can cause build errors. The longest path in the source tree is ~235 characters (may be different at time of reading). Windows MAX_PATH is 260, but could be shorter in certain instances.
  • doesn't contain any spaces; and
  • doesn't contain any non-ASCII letters (e.g., a Cyrillic username).
• If you're using VS2017: Not recommended. Modify CMakeSettings.json and replace all occurrences of Visual Studio 16 2019 with Visual Studio 15 2017. Make sure not to commit these changes to any pull requests.

1.2 Visual Studio

These instructions are for building MuseScore with VS2019. Any edition of this version of Visual Studio should work, including the Community edition, which is full-featured and free to use for open-source projects.

Whether or not you already have Visual Studio installed, please read these instructions carefully, as you might need to install some additional components.

• If you do not already have VS2019 installed, download Visual Studio Community.
• When you run the Visual Studio installer (either for the first time, or after installing, to change options), you will get eventually to the Workloads tab. Make sure the Desktop development with C++ option is selected.
  
• Switch to the Individual components tab and make sure the following options are all selected:
  • VS2019:
    • Code tools:
      • Git for Windows
      • Help Viewer
    • Compilers, build tools, and runtimes:
      • C++ CMake tools for Windows
      • MSVC v142 - VS 2019 C++ x64/x86 build tools (v14.25) (or the latest version available)
      • Windows SDK, depending on your OS:
        • Windows 10 SDK (10.0.20348.0 or later)
          • This version contains necessary WinRT libs
          • If the above SDK does not show up in the VS Installer, you can find the appropriate SDK at the Microsoft SDK Archive.
        • Windows 11 SDK (latest)
      • Uncategorized:
      • GitHub Extension for Visual Studio
    • Note that as of 484f8dc, 09Oct2020, Qt 5.15 (and a C++17 capable toolchain, which with MSVC 2019 is a given) is required for the master branch.
• Now, let it install (or update), grab a coffee (or a tea, a soda, a beer… whatever you prefer), and be patient.
• Once Visual Studio has been installed, start it and link it with your Microsoft account. (If you don't have one, create one).
• Go to Extensions > Manage Extensions (Tools > Extensions > Manage Extensions in older VS versions). On the left side of the dialog, select Online, then enter “qt” in the search box at the top right, and select and install Qt Visual Studio Tools. Although this is not strictly needed, it can be handy later.
  
• While you are here, you can go to Tools > Options… and review and edit the editor options to your liking. (This can be done per-language, and there are tons of settings!)

1.3 CMake

CMake is used for generating the Visual Studio solution and project files needed for building MuseScore.

If you're building a standard build, Visual Studio will automatically use its own internal copy of CMake, so you don't need to download it separately.

If you're building an advanced build, you will need to download and install CMake.

(For information on the difference between standard and advanced builds, see building.)

• Download and install CMake.
• Add the CMake bin subfolder to the Path environment variable; typically, this will be %ProgramFiles%\CMake\bin.

1.4 Qt

You will need the Qt libraries, minimum version 5.15.2, to be able to build MuseScore. For the 3.x branch Qt 5.9 is sufficient (but the others work too, but as of 583c71c, 01Dec2020, the builds don't run when build with Qt 5.15, they crash on start or when opening a pre-3.6 score... no longer the case fortunately since at least 3.6RC), for the master branch as of 484f8dc (09Oct2020) you'd need 5.15. Go for 5.15.2, the latest and last publicly available Qt 5 release (MuseScore isn't yet ready for Qt 6, or the other way round).

• Go to Download Qt: Get Qt Online Installer and follow the steps to download and launch the online installer.
• If you're not in the US or Europe, you'll probably want to launch the installer with a specific mirror, as per https://wiki.qt.io/Online_Installer_4.x#Selecting_a_mirror_for_opensour…
• Install Qt in the default location.
• Ensure you select custom install
• Choose a Qt version (5.15.2, but see above) and install the following components for that version:
  • MSVC 2019 64-bit (Qt 5.15)
  • Qt WebEngine (not needed anymore for the master branch)
  • Qt Network Authorization
  • Optional, for 32-bit builds of MuseScore: MSVC 2017 32-bit (not available for Qt 5.9.9; instead, install MSVC 2015 32-bit, which will also work for VS2017 and VS2019, or MSVC 2015 32-bit for Qt 5.15)
  • Optional, to make debugging easier: Qt Debug Information Files (not available for Qt 5.9.9)
• Add the path of the Qt bin subfolder (e.g., C:\Qt\5.12.9\msvc2019_64\bin) to the PATH environment variable.
  Tip: If you get CMake “can't find resource” failures later on, it's probably because the path of the Qt bin subfolder has not been correctly added to the PATH environment variable.
• Remove the MinGW C:\Qt\5.*\mingw*\bin folder from the PATH environment variable, if present.

1.5 JACK

NOTE: as of 1220175, 04Dec2020, JACK is no longer needed nor supported in the master branch, however it is needed if you wish to build 3.6.2 or earlier.

• Download the 64-bit Windows installer for the latest version of JACK.
• Install JACK in the default location.

1.6 7-Zip

You will need a utility that handles .7z compressed files. 7-Zip is open-source, free, and quite powerful, but there are alternatives that will work as well.

1.7 Additional dependencies

There are several additional dependencies:

• LAME
• libogg
• libsndfile
• libvorbis
• libvorbisfile
• Portaudio
• WinSparkle
• zlib

All of these are open-source projects. Although it is possible to download them individually and build them yourself to create the required libraries, it is much easier to use prebuilt libraries and include files.

• Download dependencies.7z.
• Extract the contents of dependencies.7z into the MuseScore checkout folder. (This will create a new dependencies subfolder within.)

NOTE: as of 1220175, 04Dec2020, LAME and PortAudio are no longer needed nor supported in the master (4.0) branch. They are still needed if you wish to build 3.6.2 or earlier versions.

2. Building

Before you can build MuseScore, you need to download and install all of the prerequisites.

MuseScore can be built in three different configurations:

• Release: Runs fast with all performance optimizations enabled, but very difficult to debug.
• Debug: Very easy to debug, but runs very slow because all performance optimizations have been disabled.
• RelWithDebInfo: A compromise between Release and Debug. Runs faster than Debug but is more difficult to debug; conversely, easier to debug than Release but runs somewhat slower.

For each of these three configurations, MuseScore can be built for either 32-bit or 64-bit Windows.

A standard build of MuseScore uses the RelWithDebInfo configuration for 64-bit Windows. To build this, follow the procedure for a standard build.

To build MuseScore in other configurations, or for 32-bit Windows, follow the instructions for advanced builds.

2.1 Standard build

• Open Visual Studio.

• Go to File > Open > Folder… and open the MuseScore checkout folder.

  Visual Studio will automatically begin to generate a CMake cache, which will include the Visual Studio solution and project files.

  In Visual Studio, a solution is a collection of projects, grouped together, and sharing some basic characteristics. A project corresponds to a specific output being generated (such as an executable or a library). A project can exist by itself or within a solution, and a solution can contain one or more projects. CMake creates a single solution, with a different project for each logical component of MuseScore. The MuseScore solution contains over two dozen projects.

  CMake cache generation will take a while. Watch the Output window and wait for the completion message to appear: CMake generation finished.

  If everything has worked as it should, Visual Studio will have created a Visual Studio solution file called mscore.sln inside the msvc.build_x64 subfolder of the MuseScore checkout folder, along with a collection of Visual Studio project files (*.vcxproj).

• The recommended process for running/building is:

  • Go to File > Close Folder to close the MuseScore checkout folder.
  • Go to File > Open > Project/Solution…, then navigate to the msvc.build_x64 folder and open the mscore.sln Visual Studio solution file.

  The Solution Explorer window should look like this:

  

  Note the small red “minus sign” icons to the left of each project. Those icons mean that the project files are being excluded from the Git repository. Any directories or files with this icon are excluded and will not be included in any commits that you make.

• In the Solution Explorer window, select the mscore project, then go to Build > Build mscore. (Alternatively, right-click the mscore project and choose Build from the popup menu.)

  Building will take a while. Visual Studio will automatically build all of the other projects that mscore depends on. Watch the Output window and wait for the completion message to appear:
  ========== Build: 25 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

• In the Solution Explorer window, select the INSTALL project, then go to Build > Build INSTALL. (Alternatively, right-click the INSTALL project and choose Build from the popup menu.)

  Watch the Output window and wait for the completion message to appear:
  ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

  Note: Make sure MuseScore4.exe is not running when building INSTALL.

2.2 Advanced builds

To generate an advanced build, use the msvc_build.bat batch file at a Command Prompt instead of building from within Visual Studio.

1. Exit Visual Studio if it's running.
2. Delete the msvc.build_x64 or msvc.build_x86 and msvc.install_x64 or msvc.install_x86 subfolders of the MuseScore checkout folder or run msvc_build.bat clean
3. Make sure that CMake is installed and that its bin subfolder has been added to the PATH environment variable.
4. Make sure that the bin subfolder of an appropriate build of Qt (e.g., 32-bit for a 32-bit build) is the one that has been added to the Path environment variable.
5. Open the msvc_build.bat batch file in a text editor (such as Notepad) to read the instructions in the comments at the beginning of the file.
6. Run the msvc_build.bat batch with the options you thing to need, e.g. msvc_build.bat RelWithDebInfo 32.

3. Running

Before you can run MuseScore, you must build it.

Run MuseScore4.exe from inside the msvc.install_x64\bin or msvc.install_x86\bin subfolder of the MuseScore checkout folder. (Do not run the copy of MuseScore4.exe inside the msvc.build_x64\main\RelWithDebInfo or msvc.build_x86\main\RelWithDebInfosubfolder of the MuseScore checkout folder.)

4. Debugging

Before you can debug MuseScore, you must build it.

• Start Visual Studio and open the mscore.sln solution file.
• Click the ▶ Local Windows Debugger button on the main toolbar, or go to Debug > Start Debugging, or press F5.
• Watch the Output window for debug messages.

This guide is for compiling MuseScore from the source code for testing and/or contributing purposes. If you just want to test (and not contribute code changes) then you may find using a pre-compiled Development Build easier than compiling.

You shouldn't use this method to install MuseScore for everyday score editing. Instead, get the latest official release from the Downloads page. (Of course, if there's no package for your distribution then you have no choice but to compile.)

Get the source code

MuseScore uses Git for version control. Use these commands to get MuseScore's source code for building and testing purposes. (If you want to make changes to the code then substitute the clone URL for the URL of your own fork of MuseScore on Github, and also read Git Workflow.)

To get the latest code:

git clone git://github.com/musescore/MuseScore.git
cd MuseScore

Note: the "git clone" command will put the code in a new folder called "MuseScore", so we use "cd" to enter the MuseScore directory. All subsequent commands in this guide should be run from the "MuseScore" directory.

To get a specific branch or tag:

# Fetch only the files required by (for example) the v2.0.2 tag:
# Note: Simply remove "--depth 1" if your git doesn't have that argument.
git clone --depth 1 git://github.com/musescore/MuseScore.git --branch v2.0.2
cd MuseScore

This is useful if you were forced to compile MuseScore because no package was available for your distribution, or if you are building a package. Tags are more stable than development branches so their use is recommended in this situation.

Beware, the rest of this page might be deprecated

Please refer to the README.md in the git repository to get relevant information!

Build an executable file

Firstly, you should update the revision number that will be displayed in MuseScore's Help → About dialog. This is useful for tracking issues so this step should be done by everyone, including package maintainers. Simply do:

make revision

If you don't already have a copy of MuseScore installed on your machine then you can compile the usual way:

# This causes conflicts if multiple versions are present and therefore is NOT RECOMMENDED
make
sudo make install

This creates an executable file /usr/local/bin/mscore which can be run by typing mscore in the terminal.

However, if you do have (or plan to have) another version of MuseScore installed (e.g. via your distribution's package manager) then you'll probably want to be able to distinguish between them, so do this instead:

# Use SUFFIX and LABEL if multiple versions are installed to distinguish between them
make SUFFIX="-self" LABEL="Self Build"
sudo make SUFFIX="-self" LABEL="Self Build" install

NOTE: make install is required, even for development. Because when runtime, built executable (CMAKE_BINARY_DIR/mscore/mscore) needs some installed files, for example, soundfonts, which is located at `/usr/local/share/mscore-VERSION/sound/`. Running the built executable without make install will cause crash.

This creates an executable file /usr/local/bin/mscore-self which can be run by typing mscore-self in the terminal. Alternatively, you can click on the relevant icon from your desktop launcher:

The label "Self Build" allows you to distinguish your compiled version from any other versions you might have installed (e.g. official releases or nightly builds). You can set SUFFIX and LABEL to anything you want (but no spaces in SUFFIX).

Additional information

You can stop reading here if you want. The following section is not required. However, it may give you some tips about custom installation or optional post-installation tasks.

Custom installation path

Note: it is no longer necessary to use PREFIX to avoid $PATH conflicts when installing multiple versions (you can use SUFFIX and LABEL instead). Of course, you might have other reasons for using PREFIX.

If you want to install MuseScore elsewhere (not in the default location /usr/local), you can specify the path as follows:

make revision
make PREFIX=$HOME/software
make PREFIX=$HOME/software install

In this example, a local installation (only for the current user; no root privileges needed) is done. The resulting executable file is bin/mscore, located in the folder specified during build. For the above example, this gives $HOME/software/bin/mscore.

Keeping the source code up-to-date

Note: for more info about the development process with git, see Git Workflow .

The source code previously downloaded with git can be updated locally. Only new commits will be retrieved:

cd MuseScore
git pull

Note about the first command: the folder MuseScore is the one created by git and where you performed the compilation.

After updating you will need to compile again using:

# Remember to change SUFFIX and LABEL here if you set them to something else previously
make revision
make SUFFIX="-self" LABEL="Self Build"
sudo make SUFFIX="-self" LABEL="Self Build" install

'make' is clever and it will only get the compiler to compile the new files; unchanged files and files where no dependency has changed will not be recompiled, so it should be much faster than the initial compile. However, sometimes errors occur during compilation and it will be necessary to start again from scratch. To do this you must delete all of the intermediate object files (of which there are many!) that are created in the source code folder during compilation. Fortunately, there is a simple command to do this for you:

make clean

The next time you try to compile the code, it will start anew.

Note: before using make clean you should read the notes for "Uninstalling MuseScore" (immediately below).

Uninstalling MuseScore

There is a Makefile target to uninstall, so removing MuseScore is effortless:

sudo make uninstall

Obviously you must run this from within the MuseScore source code folder (created by git) where you performed the compilation.

Note:

• You should always run make uninstall before you run make clean because it is not possible to do so afterwards.
• When running make uninstall or make clean it is not necessary to specify any variables (PREFIX, SUFFIX, etc.) even if you specified them during compilation.
• In the past there have been occasions where make uninstall was unavailable or broken on the latest development branch. In such cases, your last resort is to use a more arbitrary and dirty way to uninstall:
  xargs rm < install_manifest.txt

Tools for editing and debugging

MuseScore is a sophisticated program made up of millions of lines of code split among thousands of files. Although it is possible to edit the code in any text editor and build from the command line, there are specialised tools to make the challenge of coding and spotting errors in such a huge project much easier to manage:

Before Debugging

These are some of the problems that you may or may not face while completing the next section.

1. The compile time for debug build will vary from 10 minutes (8 core system) to 1 hour (single core) depending on the number of cores that your system has.

2. One should disable the ClangCodeModel in the top bar under Help > Plugins > C++ otherwise you may get many C++ errors/issues. These don't prevent a build but may result in missing important warnings and real errors.

Parallel Build

If you have a multi-core/threading processor, compilation can be sped up significantly by allow Qt Creator to launch multiple parallel build processes. To achieve this, you can set -j$(shell getconf _NPROCESSORS_ONLN 2>/dev/null || getconf NPROCESSORS_ONLN 2>/dev/null || echo 1) in the Tool arguments for both the Build Steps as the Deployment Steps. You can also manually set the number of threads, e.g. -j8.
On a quad-core hyperthreading processor you could go up to `-j8` to maximize the processor load. It might be wise to set the number to be one lower than your maximal number of processes, allowing you to perform another program while the build is running.

Qt Creator IDE - method 1

This is the normal way (but not necessarily the best way) to configure Qt Creator for a CMake project. The advantage of this method is that Qt Creator does most of the setup and configuration for you. The disadvantage is that the CMake configuration can break from time-to-time when MuseScore's CMakeLists.txt are changed. This method also makes it more difficult to compile MuseScore from the Terminal should you need to do so.

• If you haven't already, checkout MuseScore's code using Git (see main compilation guide above).
• Within Qt Creator, open ./CMakeLists.txt as your project file.
• When QT Creator asks for command line options for cmake, use
  -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=DEBUG
• When QT Creator asks to Choose CMake Executeable, it's probably located at
  /usr/bin/cmake

To install MuseScore so all features will be available (e.g. SoundFonts and templates) do the following:
In "Build settings" set the Cmake setting CMAKE_INSTALL_PREFIX to install. Remember to click "Apply Configuration Changes".
In "Run settings" add a deploy step where target is install (cmake --build . --target install). Then add a "Custom Executable" run configuration with executable set to %{buildDir}/install/bin/mscore (if that does not work, try %{sourceDir}/install/bin/mscore).

Qt Creator IDE - method 2

This method bypasses Qt Creator's built-in handling of CMake and simply specifies some Terminal commands to build and run MuseScore. This makes it easier to build MuseScore outside of Qt Creator and ensures that you always use an up-to-date CMake configuration.

• If you haven't already, checkout MuseScore's code using Git (see main compilation guide above).
• Within Qt Creator, go to File → New File or Project
• Select "Import Project" and "Import Existing Project". Click "Choose".
• Name: "MuseScore_Linux", location: "~/src/MuseScore" (or wherever the Git repo is on your system). Click "Next".
• Add *.ui to the list of file types to be shown, and * to the list of types to be hidden (hides everything else) and then apply the filter.
• Uncheck all directories except libmscore, mscore and mtest and then click "Next".
• [Optional] Add the project to Git version control and click "Finish". (I prefer to use Git from the command line.)
• Now click the "Projects" button on the left side of the Qt Creator window and modify the build and run configurations as follows:

Build settings

Build directory:
    ~/src/MuseScore (or wherever the code is located)

Build steps:
    make revision
    make installdebug PREFIX=install SUFFIX=-qt LABEL="Qt Creator Build" UPDATE_CACHE=FALSE

Clean steps:
    make uninstalldebug
    make clean

Build environment:
    Use System Environment

Run settings

Executable: build.debug/install/bin/mscore-qt  (this file won't exist until you run the build for the first time)
Working directory: %{buildDir}

Using the Makefile means that you always use the same build configuration as Travis. If the CMake options are changed by a PR then your configuration is updated automatically when you fetch and merge the changes from upstream.

Eclipse CDT

1. Download Eclipse CDT bundle or install the CDT on a previous eclipse install.
2. Edit ./CMakeLists.txt and change Project name to something different than "mscore" (if not, Eclipse will not find the mscore binary to run)
3. Create a musescore_build directory in the workspace and run Cmake to generate Eclipse project
   mkdir musescore_build
cd musescore_build
cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug ../MuseScore

4. Open Eclipse.
   • Import project using Menu File → Import
   • Select General → Existing projects into workspace
   • Browse where your build tree is and select the root build tree directory. Keep "Copy projects into workspace" unchecked.
   • You get a fully functional eclipse project. Be patient, Eclipse will index all cpp files and build the project.
5. To debug, right click on the project and choose Debug as → Local C/C++ Application
6. Go to debugger tab, share libraries tab and uncheck Load shared library symbols automatically and Stop on shared library events
7. You should be able to debug.
8. If you lack sound, in Preferences → I/O, you can try to check PortAudio, APi: Alsa, Device: Pulse

More information: http://www.cmake.org/Wiki/Eclipse_CDT4_Generator

This page contains only the compilation instructions that are specific to Ubuntu 12.04 LTS.

Tested working on: Ubuntu 12.04 LTS Desktop and Server editions.

Install dependencies

Install GCC 4.8+

GCC 4.8 or higher is needed. On Ubuntu 12.10 and higher, it's the default compiler. On Ubuntu 12.04, you will need to install it.

sudo add-apt-repository -y ppa:ubuntu-toolchain-r/test
sudo apt-get  update
sudo apt-get install g++-4.8
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 40 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8

Install Qt 5.3.2

Download and install Qt 5.3 from http://qt-project.org/downloads
Add Qt bin directory in your $PATH.

For 32-bit:

echo "PATH=~/Qt5.3.2/5.3.2/gcc/bin:$PATH" >> ~/.bashrc
source  ~/.bashrc

or for 64-bit:

echo "PATH=~/Qt5.3.2/5.3.2/gcc_64/bin:$PATH" >> ~/.bashrc
source  ~/.bashrc

Install remaining dependencies

sudo apt-get install git cmake
sudo apt-get install alsa libsndfile1 
sudo apt-get install libasound2-dev portaudio19-dev libsndfile1-dev zlib1g-dev libfreetype6-dev
sudo apt-get install lame libmp3lame-dev
sudo apt-get install libssl-dev

In Ubuntu 13.04 you need to install these additional libraries:

sudo apt-get install libdrm-dev libgl1-mesa-dev

Note: In some cases, libgl1-mesa-dev(and/or libegl1-mesa-dev) needs to be installed in Ubuntu 12.04 desktop edition too. Install this library if you get the following error while making:

Failed to find "GL" in "".

Optional

sudo apt-get install libpulse-dev
sudo apt-get install doxygen

Get the source code and compile

Now follow the generic instructions for compiling on Linux.

This page contains only the compilation instructions that are specific to Ubuntu and related Debian-based distributions.

Tested working on: Ubuntu 16.04 LTS, 18.04 LTS, and 20.04 LTS

It should also work with the various Ubuntu flavours, including Ubuntu MATE, Ubuntu Studio, Kubuntu and Xubuntu, etc.
It should work on derivatives such as Linux Mint, and it may also work on the corresponding Debian and Debian-derived distributions like Raspian.

Install dependencies

Recent distributions have up-to-date versions of most of the necessary packages in the default repositories.

sudo apt-get install git cmake g++
sudo apt-get install libasound2-dev portaudio19-dev libmp3lame-dev libsndfile1-dev libportmidi-dev
sudo apt-get install libssl-dev libpulse-dev libfreetype6-dev libfreetype6

If you get an error message like this while compiling:

Failed to find "GL" in "".

Then try installing these additional libraries:

sudo apt-get install libdrm-dev libgl1-mesa-dev libegl1-mesa-dev

Important Note: It is as of November 2020 necessary to install Qt 5.15, or later to compile the master branch. 5.9 or later is necessary for 3.x with plugins.

MuseScore uses Qt to achieve a consistent look and feel across different platforms (Mac, Windows & Linux). Qt is updated more frequently than any other dependency. Having an out-of-date version of Qt is the most common cause of problems as far reaching as strange window behavior, keyboard shortcuts not working, or the code failing to compile outright.

If your repository has Qt version 5.15 (or 5.9 for 3.x), or later, you can get Qt from your repository:

sudo apt-get install qtbase5-dev qttools5-dev qttools5-dev-tools qtwebengine5-dev \
qtscript5-dev libqt5xmlpatterns5-dev libqt5svg5-dev libqt5webkit5-dev \
qtbase5-private-dev libqt5x11extras5-dev qtdeclarative5-dev qtquickcontrols2-5-dev

Might need these too:

sudo apt-get install qml-module-qtquick-controls2 qml-module-qtquick-window2 qml-module-qtquick2 qml-module-qtgraphicaleffects qml-module-qtqml-models2 libqt5quicktemplates2-dev qtquickcontrols2-5-dev libqt5x11extras5 libqt5x11extras5-dev libqt5networkauth5 libqt5networkauth5-dev qtbase5-private-dev

If musescore compiles but you get a warning message while compiling about QuickTemplates2, you may get an empty Palette in Musescore. If so, check to see if "/usr/lib/x86_64-linux-gnu/cmake/Qt5QuickTemplates2" exists. If not, try copying:
/usr/lib/x86_64-linux-gnu/cmake/Qt5QuickControls2/Qt5QuickControls2Config.cmake
/usr/lib/x86_64-linux-gnu/cmake/Qt5QuickControls2/Qt5QuickControls2ConfigVersion.cmake
to
/usr/lib/x86_64-linux-gnu/cmake/Qt5QuickTemplates2/Qt5QuickTemplates2Config.cmake
/usr/lib/x86_64-linux-gnu/cmake/Qt5QuickTemplates2/Qt5QuickTemplates2ConfigVersion.cmake

And replace all mentions of "QuickControls2" with "QuickTemplates2".

If your repository does not have 5.15 (5.9), or later then follow these steps to install it:
(Note that having two different versions of Qt installed can cause difficulties. If you installed using "apt-get install" above, then you may want to remove that before following these steps.)

1. Download the latest version of Qt (5.15 as of November 2020) from https://www.qt.io/download-open-source. The file you download is actually an installation script called something like "qt-unified-linux-x64-2.0.3-online.run". (It will be called something different for 32-bit machines).
2. Move the installer (file you downloaded) to your Home directory and open a terminal window (Ctrl+Alt+T on Ubuntu).
3. Give the installer execute permissions:
   sudo chmod +x qt-unified-linux-x64-2.0.3-online.run
4. Run the installer ("sudo" is not required if you choose to install to your Home directory in Step 5):
   sudo ./qt-unified-linux-x64-2.0.3-online.run
5. Choose the "Custom installation" option and make sure "Qt WebEngine" is included in the list of packages at Qt > Qt 5.15.x. Write down the installation directory (default: "/opt/Qt". You can choose somewhere else if you want but make sure it doesn't have spaces anywhere in the path). Finish the install.
6. In your file browser, navigate to the installation directory and find the path to the Qt "bin" directory. (Mine is "/opt/Qt/5.8/gcc_64/bin". This will be different on different machines.)
7. Add the "bin" directory to your $PATH environment variable so that MuseScore knows where it is. (Modify the following command with the correct path as appropriate.):
   echo 'export PATH=/opt/Qt/5.8/gcc_64/bin:$PATH' >> ~/.bashrc
8. Load your new $PATH variable.
   source ~/.bashrc

You can check the Qt installation and version by typing "qmake -version" in a terminal.

If you experience any problems with MuseScore, first check you have the latest copy of the MuseScore source code, and then check you have the latest copy of Qt. Only once you have confirmed this (and done the same for the other dependencies) should you consider creating a bug report in the issue tracker.

Compiling the code

Now follow the Compile instructions (Linux & BSD) - Git.

The remaining steps on this page are optional. Read them if you experience problems or wish to completely uninstall MuseScore and it's dependencies.

Uninstall dependencies

Remember all the packages installed previously in order to compile MuseScore? Actually, even more were installed because each installed package has its own dependencies. If you don't want them anymore, here's how to remove them.

When you proceed with the installation, apt-get outputs in the terminal the complete list of packages that are to be installed. If you copy this list, the packages can be easily removed later with this command:

sudo apt-get remove --purge LIST

If you did not copy this output and still want to remove all the packages, it's a little more complicated but still feasible. For each command entered, for example:

sudo apt-get install git cmake g++

an entry is added in the following log file: /var/log/apt/history.log. Open it with a text editor and find the relevant entry. Example:

Start-Date: START DATE OF INSTALLATION
Commandline: apt-get install git cmake g++
Install: libstdc++-4.9-dev:amd64 (4.9.1-15ubuntu1, automatic), libc-dev-bin:amd64 (2.19-10ubuntu1, automatic), g++:amd64 (4.9.1-4ubuntu2), g++-4.9:amd64 (4.9.1-15ubuntu1, automatic), liberror-perl:amd64 (0.17-1.1, automatic), git-man:amd64 (2.1.0-1, automatic), git:amd64 (2.1.0-1), cmake:amd64 (2.8.12.2-0ubuntu5), cmake-data:amd64 (2.8.12.2-0ubuntu5, automatic), linux-libc-dev:amd64 (3.16.0-16.22, automatic), libc6-dev:amd64 (2.19-10ubuntu1, automatic)
Upgrade: MAY BE THERE BUT IT'S NOT RELEVANT
End-Date: END DATE OF INSTALLATION

Text that must be copied follows the key Install:

libstdc++-4.9-dev:amd64 (4.9.1-15ubuntu1, automatic), libc-dev-bin:amd64 (2.19-10ubuntu1, automatic), g++:amd64 (4.9.1-4ubuntu2), g++-4.9:amd64 (4.9.1-15ubuntu1, automatic), liberror-perl:amd64 (0.17-1.1, automatic), git-man:amd64 (2.1.0-1, automatic), git:amd64 (2.1.0-1), cmake:amd64 (2.8.12.2-0ubuntu5), cmake-data:amd64 (2.8.12.2-0ubuntu5, automatic), linux-libc-dev:amd64 (3.16.0-16.22, automatic), libc6-dev:amd64 (2.19-10ubuntu1, automatic)

To remove these packages:

sudo apt-get remove --purge $(echo "TEXT COPIED ABOVE" | sed -r 's/\s\([^\)]+\),?//g')

IMPORTANT: by doing so, you may remove some Qt packages needed to run MuseScore. The following command should ensure that you have all that is required:

sudo apt-get install libqt5core5a libqt5gui5 libqt5network5 libqt5xml5 libqt5xmlpatterns5 \
libqt5svg5 libqt5printsupport5 libqt5webkit5

Note about lrelease

When we invoke make, a call to the executable lrelease is done during the process. However, it's not the command /usr/bin/lrelease from the package qtchooser but the one from qttools5-dev-tools. That's why the package qttools5-dev-tools is added in the list of dependencies to install. If it was not installed, the following error would occur during the make invocation:

make[4]: Entering directory '/path/to/MuseScore/build.release'
/bin/sh: 1: /usr/lib/x86_64-linux-gnu/qt5/bin/lrelease: not found
CMakeFiles/lrelease.dir/build.make:49: recipe for target 'CMakeFiles/lrelease' failed
make[4]: *** [CMakeFiles/lrelease] Error 127
make[4]: Leaving directory '/path/to/MuseScore/build.release'

and the following during the make install invocation:

CMake Error at share/locale/cmake_install.cmake:36 (FILE):
  file INSTALL cannot find
  "/path/to/MuseScore/share/locale/mscore_af.qm".
Call Stack (most recent call first):
  share/cmake_install.cmake:43 (INCLUDE)
  cmake_install.cmake:45 (INCLUDE)


Makefile:62: recipe for target 'install' failed
make[1]: *** [install] Error 1
make[1]: Leaving directory '/path/to/MuseScore/build.release'
Makefile:92: recipe for target 'install' failed
make: *** [install] Error 2

This page contains only the compilation instructions that are specific to openSUSE distributions.

Install the tools required for building MuseScore:


sudo zypper install -y git gcc7 gcc-c++ make cmake


Install the dependencies required by building MuseScore:


sudo zypper install -y alsa-devel libpulse-devel libjack-devel portaudio-devel libQt5Core-devel \
libQt5Gui-devel libQt5Network-devel libQt5Test-devel libQt5QuickControls2-devel \
libQt5Xml-devel libqt5-qtsvg-devel libQt5Sql-devel libQt5Widgets-devel \
libQt5PrintSupport-devel libQt5Concurrent-devel libQt5OpenGL-devel libqt5-linguist-devel \
libQt5Help5 libqt5-qttools-devel libqt5-qtwebengine-devel libmp3lame-devel \
libsndfile-devel portmidi-devel libvorbis-devel


Remark regarding qmake

On openSUSE, the tool qmake is refering to the Qt4 version of this tool. However, since MuseScore is using Qt5, the tool qmake-qt5 should be used!
This can be done by editing the file build/FindQt5.cmake and change line 38
find_program(QT_QMAKE_EXECUTABLE qmake)
into
find_program(QT_QMAKE_EXECUTABLE qmake-qt5)

An alternative is to create a script qmake in you path with the contents:

#!/bin/bash --noprofile
exec qmake-qt5 ${*}

Compiling the code

Now follow the generic instructions for compiling on Linux.

Tested on

These instructions are tested on
* openSUSE 15.1
* openSUSE Tumbleweed as per September 9th, 2019

Note on openSUSE Tumbleweed

Please note openSUSE Tumbleweed is a rolling release with the most recent release of the used packages. At this moment (September 12th, 2019) the installed version of Qt5 is Qt5 5.13.1. This version causes several compile warnings but the resulting executable runs.
To use the recommended version of Qt5, installed the required Qt packages from another source, e.g. the openSUSE download site.

This page contains only the compilation instructions that are specific to Fedora and related RPM-based distributions.

Tested working on: Fedora 21 and 22

Install dependencies:

# Note: Use "yum" instead of "dnf" on older systems.
sudo dnf install -y gcc gcc-c++ qt-devel pulseaudio-libs-devel alsa-lib-devel jack-audio-connection-kit-devel qt5-qtbase-devel qt5-qttools-libs-designercomponents qt5-qttools-devel portaudio-devel poppler-qt5-devel qt5-qtdeclarative-devel qt5-qtscript-devel qtermwidget-qt5-devel qt5-qtwebkit-devel qt5-qtxmlpatterns-devel qt5-qtquick1-devel qt5-qtsvg-devel qt5-qttools-devel qt5-qttools-static lame-devel libsndfile-devel freetype-devel texlive-scheme-basic qt5-qtwebengine qt5-qtwebengine-devel libvorbis-devel

Tested working on Fedora 28 :

sudo dnf install -y gcc gcc-c++ qt-devel pulseaudio-libs-devel alsa-lib-devel jack-audio-connection-kit-devel qt5-qtbase-devel qt5-qttools-libs-designercomponents qt5-qttools-devel portaudio-devel poppler-qt5-devel qt5-qtdeclarative-devel qt5-qtscript-devel qtermwidget-qt5-devel qt5-qtwebkit-devel qt5-qtxmlpatterns-devel qt5-qtsvg-devel qt5-qttools-devel qt5-qttools-static lame-devel libsndfile-devel freetype-devel texlive-scheme-basic qt5-qtwebengine qt5-qtwebengine-devel libvorbis-devel portmidi-devel qt5-qtnetworkauth qt5-qtnetworkauth-devel qt5-qtquickcontrols2 qt5-qtquickcontrols2-devel qt5-qtx11extras qt5-qtx11extras-devel qt5-qtbase-private-devel

Now follow the generic instructions for compiling on Linux.

Run:

sudo pacman -S --needed alsa-lib freetype2 libpulse libsndfile libvorbisfile.so portaudio portmidi qt5-base qt5-declarative qt5-quickcontrols qt5-quickcontrols2 qt5-graphicaleffects qt5-networkauth qt5-svg qt5-tools qt5-webengine qt5-xmlpatterns zlib lame cmake doxygen git qt5-script texlive-core make gcc jack pkgconfig

By now, you have the packages you need. You'll be able to continue for Linux/BSD compiling process at Compile instructions (Linux and BSD) - Git

(Tested on Manjaro Linux 21.1.3 (x86_64), with kernel labeled as "5.13.15-1-MANJARO". September 19, 2021)

Use these instructions to compile MuseScore master branch with QtCreator and Qt 5.15 (the minimum supported Qt version) on macOS 10.13+.
See the Versions Reference page for which macOS versions are supported by Qt 5.15.

Setting up the development environment

1. Install Xcode developer tools

   • If you have XCode: Preferences -> Download and install the Command line Tools.
   • else run in the terminal: xcode-select --install

2. Download and install Qt for open source with Qt online installer
   Select at least two modules: macOS and QtWebEngine
   

3. Install the dependencies. If you are new to macOS development or do not have a preference, we suggest Homebrew,

   $ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
   $ brew install libogg libsndfile libvorbis pkg-config portaudio jack lame cmake git
    

   If you prefer MacPorts, choose the DMG of your OS and install MacPorts.
   Open a terminal and enter the following (in your home):
   $ sudo port install git libsndfile pkgconfig lame portaudio jack cmake

Setting up the project

1. Clone the project from GitHub
   git clone <your_fork_url>

2. Open the QtCreator and select File -> Open File or Project then choose file CMakeLists.txt

3. Configure project

   • create the directories in project: build.debug for debug, build.release for release etc
   • choose appropriate paths in the settings

4. switch to Projects mode and change CMake configuration:

   • uncheck option BUILD_PCH
   • check option BUILD_UI_MU4
   • create directory install in the current build folder ( for the debug: build.debug/install )
   • choose created directory in the option: CMAKE_INSTALL_PREFIX
   • Push the button Apply Configuration Changes

5. Run CMake

6. Build the project

Use these instructions to compile MuseScore master branch with Xcode and Qt 5.12 on macOS 10.12+. See the Versions Reference page for which macOS versions are supported by Qt 5.12.
As of 484f8dc, 09Oct2020, Qt 5.15 (and a C++17 capable toolchain) is required for the master branch. This excludes macOS 10.12 (and lower). The 3.x branch will stay in Qt 5.9 though.

Setting the build and development environment

1. Install the latest version of Xcode from the Mac App Store.

2. Launch Xcode and accept the licence.

3. In Xcode, go to Preferences -> Download and install the Command line Tools. With Xcode 5, you might need to run xcode-select --install instead.

4. Install the dependencies. If you are new to macOS development or do not have a preference, we suggest Homebrew,

      $ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
      $ brew install libogg libsndfile libvorbis pkg-config portaudio jack lame cmake git uncrustify

If you prefer MacPorts, choose the DMG of your OS and install MacPorts.
Open a terminal and enter the following (in your home):
$ sudo port install git libsndfile pkgconfig lame portaudio jack cmake qt513

5. Install Qt. It's possible to do this via Homebrew or MacPorts, but the recommened way is to use the Qt Online Installer (open source version, not commercial), which is available from the link at the bottom of this page. Open the DMG and double-click the installer (no need to drag to your Applications folder). You'll have to sign-in / create a Qt account and agree to terms (probably as "an individual not working for any company" unless a company is paying you to work on MuseScore). When asked, do a Custom Installation. Under Qt 5.15.2 (i.e. the latest non-Qt 6 version), make sure the components labelled macOS and Qt WebEngine are selected. Also, at the bottom of the window, under Developer and Designer Tools, make sure that CMake and Ninja are selected.

6. Add Qt's binary folder to your PATH environment variable. To do this, open the hidden text file ~/.bash_profile (if that file exists), or alternatively use ~/.profile. If neither file exists then create ~/.profile. Append the following line to the file you just opened:

    export PATH="${PATH}:${HOME}/Qt/<QT_VERSION>/clang_64/bin"

Make sure you substitute <QT_VERSION> for the actual version you installed. E.g. for Qt 5.15.2:

    export PATH="${PATH}:${HOME}/Qt/5.15.2/clang_64/bin"

You must update the version number in this file every time you update Qt itself via the MaintainanceTool.

7. Clone the repository from GitHub into your home directory:

      $ cd ~
      $ git clone git://github.com/musescore/MuseScore.git
 

If you plan to contribute to MuseScore, you can setup your own fork on GitHub and clone it instead. See the Git Workflow page.

Building MuseScore

1. In a terminal, enter:
   $ cd MuseScore
2. Set the revision SHA1 for this build
   $ make -f Makefile.osx revision
3. Start the actual compilation. It takes more than one hour on a MacBook 2 GHz but it's pretty fast on a MacBook Pro Core i7 (4 to 5 minutes max).
   $ make -f Makefile.osx release
4. Call the install target. The bundle is copied from the Release directory into the applebuild directory. All resources (such as help and templates) are added to it
   $ make -f Makefile.osx install
5. The package step. This target calls a script derived from this one. It creates a self-contained bundle, thanks to macdeployqt, by adding and stripping the Qt libraries into the MuseScore bundle. It also adds Qt plugins, PortAudio and libsndfile. A DMG file is the result
   $ make -f Makefile.osx package

Debugging and developing MuseScore

If you are a developer, look at the xcode target in the makefile. It generates a xcodeproj file. You can open this xcodeproj file and use the Apple IDE for tasks such as modifying, debugging and compiling MuseScore code.

Run
$ make -f Makefile.osx xcode

Then open the xcodeproj bundle in Xcode
$ open build.xcode/mscore.xcodeproj

In Xcode, run the ALL_BUILD scheme. It will compile all the files. Then run the install scheme. It will install the required files (fonts, images etc...) for runtime. Debug by running the mscore scheme.

If MuseScore won't start

You may get this error message on the Xcode Console when you try to run the mscore scheme:


This application failed to start because it could not find or load the Qt platform plugin "cocoa".


This mean MuseScore can't find the Qt plugins. You need to edit the mscore scheme to set the environment variable QT_PLUGIN_PATH to point to your Qt plugins directory. The default value for Qt 5.12 is:

      QT_PLUGIN_PATH=~/Qt/5.12.9/clang_64/plugins

The actual value you need to set depends on your Qt version (which you can find with qmake -v) and where you installed it earlier on. You may also need to expand the tilde (~) to it's full value /Users/<username> to point to your home directory.

If MuseScore doesn't start for any other reason then try reverting to factory settings, but make sure you revert the compiled mscore debug build rather than the official version if you have it installed.

Debugging in Xcode 5+

In Xcode 5+, you might need to uncheck “Allow debugging when using document Versions Browser” in Product-->Edit Scheme .. -->Run mscore.app. Otherwise --NSDocumentRevisionsDebugMode YES gets passed to MuseScore, and it doesn't know how to handle it.

In Xcode > 5, you'll find the menu item elsewhere. Product-->Scheme->Edit Scheme..
Select Run (on the left hand side), and select Options along the top of the form.
Then you'll find "Allow debugging when using document Versions Browser" in the form. Uncheck the checkbox.

Contributing

The preferred way to contribute is via a Pull Request on GitHub. Patches are also welcome on the Developer Mailing List, or on the Issue Tracker.

Building a release for distribution

# may no longer be relevant as this is for 10.7. Please review and remove this comment or the paragraph
Dependencies built with Homebrew will not run on older versions of macOS. Here is a zip file with the dependencies as "bottles" built on Mac OS X 10.7. They can be installed with
brew install {file}.tar.¹