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.

Note: The accepted mentoring organizations will be announced on February 27, so only then we will officially know that we can participate in this year’s program.

We have had GSoC participants in 2012, 2015 and 2016 and encourage students to apply for future summers.

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

  • Handle basic musical content export like the MIDI export (i.e. using dedicated exporter classes, derived from the translator class).
  • Build the XML tree of the basic musical content, add a connection from music event to XML tag.
  • Let all LilyPond engravers do their job.
  • Link each output object (i.e. each stencil or group of stencils) to the music cause (and thus to the XML tag in the XML tree).
  • Add an XML output backend, which can then add layout information for each output object to the XML tags.

There are several possibilities for this project, including building upon the MusicXML export project from GSoC 2015.

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.