en/included/gsoc.itexi

@c -*- coding: utf-8; mode: texinfo; -*-
@c This file is part of community.itexi
@c It's been moved here to reduce maintenance burden on translators.  It's up
@c to translators the choice of translating this section of community.itexi or
@c not (as GSoC students are required to speak english, a translated page is
@c not needed).

@c Current proposals for Google Summer of Code
@macro gsocCurrent

@divClass{column-center-top}
@subheading What is Google Summer of Code?

@uref{https://summerofcode.withgoogle.com/, 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 @uref{http://www.gnu.org/, GNU project}.

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

@divEnd

@divClass{column-center-middle-color2 bigger-subsubheadings}
@subheading 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 @ref{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
@emph{not} responsible for discussing the implementation or reviewing
the code.  Instead they will on the one hand discuss the @emph{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
@uref{https://gitlab.com/lilypond/lilypond/-/issues, here}.


@subsubheading Adopt the SMuFL music font encoding standard

For several years now a new standard for music fonts has been around:
@uref{http://www.smufl.org/, 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.

@emph{Difficulty}: Easy/medium

@emph{Requirements}: C++ and willingness to get familiar with LilyPond
internals.

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

@emph{Mentors:} Werner Lemberg, Abraham Lee


@subsubheading Adding variants of font glyphs

@divClass{keep-bullets}
@itemize

@item
Adding @q{on} and @q{between} staff-line variants.

@item
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 @q{hole} within
it.

@end itemize
@divEnd

@emph{Difficulty:} easy

@emph{Requirements:} MetaFont, C++, good eye for details

@emph{Recommended knowledge:} basic LilyPond knowledge

@emph{Mentor:} Werner Lemberg


@subsubheading 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 @uref{http://frescobaldi.org, 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
@uref{https://github.com/wbsoft/python-ly, python-ly} repository.

@emph{Difficulty:} easy to hard (depending on the targeted improvements)

@emph{Requirements:} Python, MusicXML

@emph{Mentor}: Peter Bjuhr


@subsubheading 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
@uref{http://lists.gnu.org/archive/html/lilypond-devel/2017-11/msg00037.html,
this discussion} and
@uref{https://openlilylib.org/public/beam-subdivisions.pdf, this
work-in-progress document}).

In the course of this assessment it has been found that LilyPond's
conception of @emph{tuplets} is somewhat flawed as well (see
@uref{http://lists.gnu.org/archive/html/bug-lilypond/2017-11/msg00016.html,
this discussion}), and that this has to be fixed as well.

@emph{Difficulty:} medium

@emph{Requirements:} C++

@emph{Recommended knowledge:} Good musical and mathematical understanding
of timing issues

@emph{Mentors:} Urs Liska, Carl Sorensen


@subsubheading Frescobaldi Extensions

Starting with the current release 3.1
@uref{http://frescobaldi.org, 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 @emph{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 @uref{https://openlilylib.org, openLilyLib}
infrastructure.

@emph{Difficulty:} easy/medium

@emph{Requirements:} Python, (PyQt)

@emph{Optional:} GUILE Scheme (if functionality involves LilyPond
internals)

@emph{Mentor:} @emph{Urs Liska}


@subsubheading 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
@uref{https://github.com/openlilylib/notation-fonts, 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.

@emph{Difficulty:} medium

@emph{Requirements:} Scheme, aesthetic competence

@emph{Recommended:} sense of building hierarchical frameworks

@emph{Optional:} C++ (for font loading internals)

@emph{Mentor:} @emph{Abraham Lee}

@emph{Community Mentor:} @emph{Kieren MacMillan}


@subsubheading Contemporary Notation

LilyPond is very good at creating non-standard notation.  Having to
@emph{code} every graphical element instead of simply @emph{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 @uref{https://github.com/openlilylib/oll-core, openLilyLib}
library system the student will create a fundamental infrastructure
and building blocks to make creating contemporary notation easier.
Additionally (at least) @emph{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.

@emph{Difficulty:} medium

@emph{Requirements:} Scheme (interaction with LilyPond internals),
contemporary notation techniques

@emph{Recommended:} sense of building hierarchical frameworks

@emph{Mentors:} @emph{NN,} Urs Liska


@subsubheading  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 @uref{http://frescobaldi.org, 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.


@emph{Difficulty:} hard

@emph{Requirements:} LilyPond/Scheme, Python/PyQt

@emph{Optional:} C++ if it's necessary to modify LilyPond itself

@emph{Mentors:} NN (, Urs Liska)

@emph{Community Mentor:} Kieren MacMillan

@divEnd


@divClass{column-center-middle-color2}
@subheading 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.

@itemize

@item
Read all applicable information on the program's website, particularly
the
@uref{https://developers.google.com/open-source/gsoc/resources/manual,
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.

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

@item
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
@emph{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.

@item
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 @emph{bonding period} we expect you to write a blog
post about your project (either on @uref{https://lilypondblog.org, 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.

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

@item
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 @emph{reading} it without the
opportunity to apply it in a real example.

@end itemize

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

@divEnd
@end macro


@c Inactive proposals for Google Summer of Code
@macro gsocInactive
@subheading Inactive Google Summer of Code project suggestions

The following list describes GSoC projects that had been proposed
in recent years and which are still considered valuable but for
which we currently don't have mentors available.


@subsubheading Automated testing and documentation for openLilyLib

@uref{https://github.com/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 @uref{https://openlilylib.org, website}.  Development of
such a SPA @emph{can} be part of the GSoC project, but is optional.

@emph{Difficulty:} medium

@emph{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)


@subsubheading MusicXML

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 @code{musicxml2ly} script.  Export @emph{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
@uref{https://github.com/DavidGarfinkle/Lilypond_MusicXMLexport, 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).

@emph{Difficulty:} medium

@emph{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge

@emph{Recommended:} Familiarity with other scorewriters (for cross-testing)

@subsubheading Improve slurs and ties

The engraving quality of slurs and ties is often unsatisfactory. Ties
@q{broken} by clef or staff changes are not handled well.  The project
could include collecting and sorting examples of bad output, deciding on
the intended output and writing code to improve them.

@emph{Difficulty:} hard

@emph{Requirements:} C++, experience with writing heuristics

@emph{Recommended knowledge:} LilyPond knowledge, aesthetic sense


@subsubheading Grace notes

Fix problems with synchronization of grace notes.  Grace notes can
interfere with LilyPond's timing and cause odd effects, especially when
multiple staffs are used where some have grace notes and others don't.
This is one of the longest-standing and one of the more embarrassing
@uref{https://gitlab.com/lilypond/lilypond/-/issues/34/, bugs} in
LilyPond.

@emph{Difficulty:} medium

@emph{Requirements:} C++, MIDI

@emph{Recommended:} familiarity with LilyPond internals


@subsubheading Improve default beam positioning

For regular, cross-staff, broken and kneed beams.  Beaming should depend
on context and neighbor notes (see section 2.2 of
@uref{http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon%2C_Jean-Pierre%29,
this book}).  If possible also reduce beaming-computation time.

@emph{Difficulty:} medium

@emph{Requirements:} C++, experience with writing heuristics

@emph{Recommended knowledge:} aesthetic sense


@subsubheading Help improve compilation behavior

Automatic code analysis tools, like valgrind memory leak detection or
callgrind code profilers, provide valuable information about possible
flaws in our C++ code.  Cleaning up warnings would allow us to automate
the rejection of any patch which introduced extra warnings.

@emph{Difficulty:} medium

@emph{Requirements:} C++

@divEnd

@end macro