Skip to content

Project ideas for GSoC

Peter Jonas edited this page Mar 20, 2024 · 3 revisions

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.

Suggesting a new idea

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.


Approved ideas

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.


Accessibility profiles

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)
Feature Adjusts Scope Portable? Survives edits?
Format > Page settings Staff & page size Current score ✔️ ✔️
Format > Style Symbol size, line thickness, text styles Current score ✔️ ✔️
Preferences > Appearance Page & background colour All scores ✔️
Properties panel Notehead colour, shape & 'scheme' Individual notes ✔️
Color Notes plugin (built-in) Notehead colour All existing notes ✔️
Figurenotes plugin (source) Notehead shape and colour All existing notes ✔️
  • Portable means the setting is saved into the score file. Non-portable changes only affect how the score looks within MuseScore on one device, whereas portable changes affect how it looks on all devices, as well as how it looks when printed and exported to visual formats like PDF, SVG, and PNG.

  • Survives edits means that the setting will remain active and correct regardless of future changes to the score (e.g. if you add more notes or re-pitch existing ones).

The goal of this project is to enable users to choose from a list of standard accessibility profiles, such as:

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)

Rich text formatting

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)

Woodwind fingerings

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)

Dynamics popup

Users frequently need to replace one dynamic marking with another, or enter a sequence of dynamics, such as mezzo-piano that crescendos (via a hairpin) into forte.

To facilitate this workflow, this project would implement a new popup widget that would appear whenever a dynamic marking or hairpin is selected in the score. The popup would enable users to swap out a dynamic, or add a new one that closely follows it. If the user chooses a hairpin, it would automatically be snapped to the existing dynamic, and vice versa.

In addition to developer mentoring, this project requires working closely with our design team, who will provide designs and test your implementation.

Size Medium (~175 hours)
Difficulty Medium
Skills C++, Qt, QML
Suggested by Bradley Kunda (@bkunda)
Possible mentor Casper Jeukendrup (@cbjeukendrup)
dynamic_popup

Suggested ideas

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.

Testing

Translation

Compilation

  1. Set up developer environment
  2. Install Qt and Qt Creator
  3. Get MuseScore's source code
  4. Install dependencies
  5. Compile on the command line
  6. Compile in Qt Creator

Beyond compiling

  1. Find your way around the code
  2. Submit a Pull Request
  3. Fix the CI checks

Misc. development

Architecture general

Audio

Engraving

Extensions

Google Summer of Code

References

Clone this wiki locally