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
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
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.
- 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.