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 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.
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.
- Read all applicable information on the program’s website, particularly the students’ manual. Make sure you fulfil all of Google’s prerequisites and are willing to join the program as a full-time commitment over the coding period of three months.
- Please get in touch with us as soon as possible if you are interested in applying with a project. Mentor availability may change without notice, project proposals may need fine-tuning, and many other reasons might require us to reject or ignore an application that hasn’t been discussed before.
- We do not know in advance how many "slots" we will have available for projects, so please be aware that you may find yourself in competition with other applicants or not. Interested or even enthusiastic response from our mentors is no guarantee of eventually being accepted, and not being accepted does not necessarily indicate a negative evaluation of your application. If we have to decide between different applicants there may be various aspects to consider.
- Integration in the LilyPond community is a fundamental part of GSoC, and we expect our students to make substantial efforts to become community members. Within the bonding period we expect you to write a blog post about your project (either on Scores of Beauty or on any other blog) and to be active on our mailing lists, introducing yourself but also communicating about unrelated tasks. This goes beyond the mere setting up of a working environment and familiarizing yourself with the relevant code, but we think it is crucial for the GSoC project to be mutually satisfying.
- If you are accepted to the program you will have one mentor explicitly assigned to your project. With this mentor you will have to agree upon a communication strategy, be it emails, chatrooms, issue trackers or voice/video chats. Regular communication is absolutely crucial for the success of a GSoC project so you are stricly required to keep talking to your mentor. But keep in mind that your mentor has explicitly taken over the responsibility for your project, and while unlike you he isn’t paid for this activity you are still entitled to get regular attention from him.
- In order to get support from your mentor you have to give him a chance to follow your progress and efforts. Therefore it is important to regularly commit your changes to the versioning repository you are working on. Don’t hesitate making unfinished code available because you are afraid of criticism, and don’t suppress questions because you think they might be considered stupid. But ideally your code should at any time be accompanied by compatible testing code. Your mentor may not be able to properly assess your code by only reading it without the opportunity to apply it in a real example.
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.