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 and 2016 and encourage students to apply for the 2017 program.

If you are interested to apply for the program with LilyPond as a project, please read the information below and don’t hesitate to write us on our developer mailing list (see Contact). The student application window is March 20 to April 3, 2017, but we strongly encourage you to get in touch with our community ahead of that.

Project Ideas List

Below is a list of GSoC project ideas (last update: January 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 Contact). 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.

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

Improve internal chord structure

The internal representation of LilyPond chords is not powerful enough to capture the nomenclature of jazz chords. Currently the chord has a root, a bass and an inversion. It would be nice to be able to handle stacked or polychords, minor/major, etc. In order to do this, an internal representation with the ability to capture the essence of complex chords must be developed. As a bonus, once the internal representation is developed, the output formatting of chord names can be improved.

Difficulty: Easy/medium

Requirements: Scheme (Guile), but the level necessary can be easily learned

Recommended: Chord theory and naming

Mentor: Carl Sorensen

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

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

Rewrite LibreOffice LilyPond Extension with Python

The OOoLilyPond extension made it possible to conveniently include LilyPond score snippets in Writer, Draw and Impress documents while keeping source and image together. After many years without development an initial effort has started to make the extension compatible again with current versions of LibreOffice and LilyPond.

However, as the LibreOffice ecosystem has changed substantially it is now possible to rewrite the extension with Python and PyQt. This will not only be more powerful in general but will allow the integration of functionality from Frescobaldi, such as for example syntax highlighting, entry helpers, score wizards or musical transformations.

Difficulty: easy/medium

Requirements: Python, PyQt, LilyPond basics, LibreOffice extension basics

Recommended knowledge: Familiarity with Frescobaldi code based or willingness to learn during bonding period

Mentor(s): Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)

Automated testing and documentation for openLilyLib

openLilyLib is an extension framework for LilyPond code providing a “snippets” repository and a suite of integrated packages such as for example page layout tools or scholarly annotations. It is very powerful and promising, but to really get off the ground two features are missing: automated testing and documentation generation.

Automated testing is necessary to ensure modifications to functionality don’t break other functions within the library. There is already some Automated Testing of the “snippets” repository with Github’s Travis server, but this has to be reconsidered and extended to cover the standalone packages too.

In order to be usable for a wider range of LilyPond users on a “consumer level” openLilyLib needs proper documentation. This documentation has to be generated from the sources, so a system is needed that requires package authors to document the input files and provide additional usage examples, from which documentation is generated. Ideally but not necessarily this is implemented as a Git hook, i.e. automatically upon each update to the repository. We don’t prescribe the tools and approaches to be used, but the most widely used language in the LilyPond domain is Python, so there would be some bias towards that. Alternatively a Scheme solution could be fine so generating the documentation would actually be triggered by “compiling” a certain LilyPond input file. In general it is advisable to make use of proven concepts and tools from other languages.

The eventual output of the documentation should be a static HTML site that can be viewed locally and/or uploaded to a website. But it would be beneficial if the tool would first generate an intermediate representation (e.g. a JSON file with additional media files) from which a Single Page Application could retrieve content for display on openLilyLib’s website. Development of such a SPA can be part of the GSoC project, but is optional.

Difficulty: medium

Requirements: Python or Scheme, static website generator(s) or (Node.js based) dynamic web application technology. Continuous Integration (can be learned during the bonding period)

Mentors: Urs Liska, Matteo Ceccarello


Improving MusicXML import and export functions:

File interchange between LilyPond and other applications using MusicXML is still a difficult matter. To import MusicXML it has to be converted manually by the musicxml2ly script. Export to MusicXML is only available as a rudimentary feature inside Frescobaldi. In order to provide natural interchange between LilyPond and MusicXML based applications there’s the need of actual import functionality and a dedicated export backend.

Importing XML shall provide file, line and column to add origin attributes to generated objects. That way point and click can be made available in Frescobaldi or other supported IDEs.

Exporting XML shall be realized with an exporter class like the MIDI export. This may be based on the work already done in GSoC 2015 by David Garfinkle. It should be checked if it is possible to use another XML library than the one provided by guile-2 in order to have this feature available in current LilyPond (which is based on guile-1.8).

Difficulty: medium

Requirements: MusicXML, Python, Scheme, basic LilyPond knowledge

Recommended: Familiarity with other scorewriters (for cross-testing)

Mentor: Jan-Peter Voigt

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 Attic. We list projects there that are still considered valuable but for which there are currently no mentors available.

Other languages: deutsch, español, français, italiano, 日本語, nederlands.
About automatic language selection.


Thanks to for hosting Valid HTML 4.01 Transitional