Google Summer of Code

What is Google Summer of Code?

GSoC is a global program that offers students stipends to write code for free software and open source projects during the summer. For three months students work to complete a given task as part of the project’s community and under the guidance of experienced mentors. The program is an excellent opportunity for students to gain experience with real-world software development and make a contribution that benefits everyone. It brings new contributors to LilyPond and enables students who are already involved to become more involved. LilyPond participates in GSoC as part of the GNU project.

We have had GSoC participants in 2012, 2015, 2016 and 2017. This site is current for the 2018 program.

Project Ideas List

Below is a list of GSoC project ideas (last update: May 2017), but if you have other ideas for a project you may complete within the three months of the program you’re welcome to make a suggestion on our developer mailing list (see Kontakt). There are a number of areas where LilyPond could be improved, and our development team is always willing to help those who would like to tackle a project similar to those listed below. As mentor availability varies from project to project and from year to year it is wise to get in touch with us as early as possible.

Per 2018 we have installed the new role of “Community Mentor”. We aim at assigning one Community Mentor to each active project who is not responsible for discussing the implementation or reviewing the code. Instead they will on the one hand discuss the design of the planned features from the (power) user perspective, and they will look after the communication between student and mentor, and between the two and the community.

A full list of all the current open issues can be found here.

Adopt the SMuFL music font encoding standard

For several years now a new standard for music fonts has been around: SMuFL, which is also discussed as becoming part of a future W3C standard for music encoding. As a FLOSS tool LilyPond should adhere to such an open standard instead of using an isolated solution like it does today. Adopting SMuFL will help integrating LilyPond with the world of music notation software and eventually give LilyPond users access to a wider selection of notation fonts.

Making LilyPond compliant to SMuFL includes remapping of the glyphs that are built from METAFONT sources, adjusting the glyphs’ metrics to SMuFL’s specifications, and finally updating the way LilyPond looks up and positions the glyphs. As an optional part of this project LilyPond’s font loading mechanism could be modified to use notation fonts installed as system fonts instead of inside the LilyPond installation.

Difficulty: Easy/medium

Requirements: C++ and willingness to get familiar with LilyPond internals.

Recommended: Interest and experience in working with font files. A little bit of METAFONT.

Mentors: Werner Lemberg, Abraham Lee

Adding variants of font glyphs

  • Adding ‚on‘ and ‚between‘ staff-line variants.
  • Shorter and narrower variants of some glyphs for example, accidentals. Another, more specific example could be an ancient notation breve notehead coming in two variants one with a small or big ‚hole‘ within it.

Difficulty: easy

Requirements: MetaFont, C++, good eye for details

Recommended knowledge: basic LilyPond knowledge

Mentor: Werner Lemberg

Improve/Extend Export to MusicXML

There is experimental support for exporting scores to MusicXML. So far there is limited coverage that should be extended, and the export should become more robust with regard to unconventionally organized input files. Several strategies can be thought of in that regard.

Significant progress in coverage has been made in a GSoC Project hosted by Frescobaldi in 2017, but there is still much to be done that could make a nice GSoC project.

Working in this project will mainly be done in the python-ly repository.

Difficulty: easy to hard (depending on the targeted improvements)

Requirements: Python, MusicXML

Mentor: Peter Bjuhr

Fix Beaming Patterns/Beam Subdivisions and Tuplets

Subdivision is an important way to improve the readability of beamed music. However, despite several attempts at fixing it LilyPond still does not always produce correct results. In order to properly fix this issue it seems necessary to rewrite the responsible code from the ground up. Much work has already been done assessing the issue (see this discussion and this work-in-progress document).

In the course of this assessment it has been found that LilyPond’s conception of tuplets is somewhat flawed as well (see this discussion), and that this has to be fixed as well.

Difficulty: medium

Requirements: C++

Recommended knowledge: Good musical and mathematical understanding of timing issues

Mentors: Urs Liska, Carl Sorensen

Frescobaldi Extensions

Starting with the current release 3.1 Frescobaldi has an extension API that allows the easy integration of arbitrary functionality in the editing environment. These could range from, say, document statistics and accounting functionality to fancy features like a built-in video chat client or a stock market ticker.

We would welcome project suggestions about arbitrary Frescobaldi extensions of appropriate complexity that add substantial functionality for working with LilyPond scores which might not be suitable to be included into Frescobaldi itself.

As suggestions and examples may serve: a project management extension that can manage repetoire of arbitrary complexity, handle the generation of template files and the compilation process. Or an extension to manage the openLilyLib infrastructure.

Difficulty: easy/medium

Requirements: Python, (PyQt)

Optional: GUILE Scheme (if functionality involves LilyPond internals)

Mentor: Urs Liska

Support for Style Sheets

LilyPond’s engraving output can be tweaked to the least detail, and one important addition in recent years was the ability to use alternative notation fonts. It is possible to create reusable modules for “house styles”, but this project aims at bringing this to a new level by creating a convenient extension package with support for creating, applying, and sharing modular style sheets. We are looking for a hierarchical structure that allows to mix and match style elements for “house” (e.g. “my-personal-style”, “client-a”, “client-b” etc.), score type, paper size etc.

Work can be built upon the existing notation-fonts openLilyLib package. We would like to see a further improvement of the loading mechanism for notation fonts (for example a better separation of loading notation and text fonts) as part of the project, and optionally (this would involve working on Lilypond’s C++ code) support for notation fonts that are installed system-wide.

Difficulty: medium

Requirements: Scheme, aesthetic competence

Recommended: sense of building hierarchical frameworks

Optional: C++ (for font loading internals)

Mentor: Abraham Lee

Community Mentor: Kieren MacMillan

Contemporary Notation

LilyPond is very good at creating non-standard notation. Having to code every graphical element instead of simply drawing it may seem cumbersome but is in fact a strong asset. New notational functionality can be provided with consistent appearance, automatic layout and a natural syntactic interface.

Within the openLilyLib library system the student will create a fundamental infrastructure and building blocks to make creating contemporary notation easier. Additionally (at least) one concrete package is developed to cover specific contemporary notation, such as for example the style of a given composer, extended playing techniques for a specific instrument or a certain category of effects.

Difficulty: medium

Requirements: Scheme (interaction with LilyPond internals), contemporary notation techniques

Recommended: sense of building hierarchical frameworks

Mentors: NN, Urs Liska

Implement a System to Handle Scores System by System

One strategy that may improve the issue of LilyPond’s compilation time is to handle scores in a system-by-system manner through partial compilation. This project explores one approach to achieve this and may lay the ground for future development towards a “LilyPond server”. It is very ambitions because it involves working with LilyPond’s internals and optionally a reference user interface in Frescobaldi.

The idea behind this project is the implementation of a music viewer that doesn’t display pages but sees a scores as a continuous sequence of systems that are stitched together. LilyPond can produce such a sequence of files, and it can be made aware of the moments of each line break. That way only systems have to be recompiled that are affected by a modification, thus saving significant waiting times. Optionally there could be new engraving modes in LilyPond that don’t try to optimize the line breaking, saving even more time, at least while in content editing mode.

The project is fairly complex and has many more aspects than could be listed on this page. So if you are interested in this please get in touch with us as early as possible to evaluate options and discuss the topics before you write an application.

Difficulty: hard

Requirements: LilyPond/Scheme, Python/PyQt

Optional: C++ if it’s necessary to modify LilyPond itself

Mentors: NN (, Urs Liska)

Community Mentor: Kieren MacMillan

Information for Applicants/Participants

In order to have a satisfying experience with GSoC applicants are strongly advised to thoroughly read the following recommendations. Some of these are relevant for the application process, others for the time within the project.

There is a list of inactive projects in the Abstellkammer. We list projects there that are still considered valuable but for which there are currently no mentors available.


Valid HTML 4.01 Transitional