Project ideas for GSoC
This page lists project ideas for Google Summer of Code (GSoC).
Once this year's GSoC projects are announced in May, community developers are welcome to take on any projects that were not selected. Please note that the internal team's capacity to assist will be limited during the GSoC period, as we will be assisting the GSoC contributors with their projects.
Anyone can suggest ideas for GSoC projects. If you're not a GSoC candidate, please add your suggestion at the bottom of this page.
If you're a GSoC candidate and you have your own idea for a project, you may want to keep it secret from the other applicants. If that's the case, click on one of the mentors in the Discord server and use the option to send them a message. Tell us about your idea before you go to the effort of writing a proposal.
If we tell you your idea is suitable, that doesn't necessarily mean we will select it for GSoC. We recommend that applicants pick at least one of the approved ideas to submit as a backup proposal.
MuseScore's internal team considers these projects suitable for Google Summer of Code.
Questions about these projects should be asked on the linked discussion pages. One question per thread, except follow-up questions.
Agencies such as RNIB use MuseScore to produce Modified Stave Notation (MSN) tailored to suit individuals with specific visual or educational needs. Typically, this involves increasing the staff size and line thickness to aid low vision users, but other modifications are possible, such as changing note colours or using different shaped noteheads altogether.
All of these things can be done in MuseScore already, but the tools to do so are located in different places, and some are quite tricky to use.
How MSN is currently created in MuseScore (click to show/hide)
|
The goal of this project is to enable users to choose from a list of standard accessibility profiles, such as:
- Normal
- Large print
- Extra large print
- Solfege noteheads
- Figurenotes (stage 3)
These profiles would be displayed in Preferences or a new Accessibility panel. When one of these profiles is enabled, all the necessary settings would be applied automatically. The goal is to make it simple enough for ordinary users to do it themselves, so they no longer have to rely on agencies like RNIB to do it for them. This would free up RNIB's resources to focus on helping people with more challenging needs.
A necessary part of this project is extending the style system (as in Format > Style) to handle notehead shape and colour so that these settings can survive edits to the score. A stretch goal would be to have an option to apply profiles in a non-portable way so they don't affect how the score looks on other devices.
In addition to developer mentoring, this project requires working closely with our design team, who will provide designs and test your implementation.
| Size | Large (~350 hours) |
| Difficulty | Medium to Hard |
| Skills | C++, Qt, QML, CSS |
| Suggested by | Peter Jonas (@shoogle) |
| Possible mentor | Peter Jonas (@shoogle) / Casper Jeukendrup (@cbjeukendrup) |
Published music often contains textual content, such as:
- Frontmatter (cover page, copyright, table of contents, preface, etc.)
- Annotations (performance instructions, stage directions, editorial comments)
- Libretto (spoken dialog between songs)
- Backmatter (appendices, endnotes, index, list of related works).
Conversely, text documents on music topics often contain small passages of music (e.g. scales or extracts from a larger work). These documents are usually created by inserting images of music into a standard word processor or desktop publishing app, but this makes the music unplayable (by the computer) and inaccessible (to screen readers, and low vision users who wish to increase the staff size). Ideally such documents should be created in a program that understands music notation.
It is possible to create mixed-content (text + music) documents in MuseScore (see example) but the process is far from straightforward. This project would seek to improve the situation by implementing two or more of the following features:
- Tables
- Hyperlinks
- Footnotes
- Text wrapping at page and frame boundaries
- Spacing (1.0, 1.15, 1.5, 2.0, etc.)
- Justification (equal length lines)
- Image alignment
In addition to developer mentoring, this project requires working closely with our design team, who will provide designs and test your implementation.
| Size | Small (~90 hours) to Large (~350 hours) depending on features chosen |
| Difficulty | Medium to Hard |
| Skills | C++, Qt, QML, text formatting |
| Suggested by | Peter Jonas (@shoogle) |
| Possible mentor | Peter Jonas (@shoogle) / Casper Jeukendrup (@cbjeukendrup) |
While piano and guitar fingerings are often noted with numbers alone, most wind instruments use drawings to represent fingerings. Currently, some plugins offer this feature for a few instruments, but they are not very user-friendly. Ideally this functionality would be built into MuseScore, similarly to guitar fretboard diagrams or harp pedal diagrams.
Free fonts such as Fiati (source, demo) have symbols for many instruments. These fonts could be used directly or converted to SVG format for inclusion in MuseScore. The new fingering element would function like existing fretboard diagrams, allowing users to indicate keys as pressed or not pressed with a click.
As an optional extension to the project, pressed keys could be determined automatically based on the instrument and the note being played. This would enable fingering diagrams to update automatically if the instrument or note is subsequently changed (e.g. if the score is edited or transposed).
In addition to developer mentoring, this project requires working closely with our design team, who will provide designs and test your implementation.
| Size | Large (~350 hours) |
| Difficulty | Medium |
| Skills | C++, Qt, QML |
| Suggested by | Rémi Marche (@ecstrema) |
| Possible mentor | Casper Jeukendrup (@cbjeukendrup) |
If you have an idea for a potential GSoC project, feel free to add it below. Use the ideas above as a template, but don't include a possible mentor.
The internal team will review these suggestions. If we feel they are suitable we will move them to the approved section and assign a mentor.
GSoC candidates, please be aware that these ideas have not been approved by the internal team.