Index: Documentation/included/gsoc.itexi |
diff --git a/Documentation/included/gsoc.itexi b/Documentation/included/gsoc.itexi |
index 3a0a36b719e25a5f338b5b53076bc2520270f57a..47ce2de5213462b244a617a01e8627922d6f07f5 100644 |
--- a/Documentation/included/gsoc.itexi |
+++ b/Documentation/included/gsoc.itexi |
@@ -23,7 +23,7 @@ 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 |
-will be updated in time before the 2018 season will start. |
+is current for the 2018 program. |
@divEnd |
@@ -69,7 +69,7 @@ internals. |
@emph{Recommended}: Interest and experience in working with font files. |
A little bit of METAFONT. |
-@emph{Mentors}: Werner Lemberg, Abraham Lee |
+@emph{Mentors:} Werner Lemberg, Abraham Lee |
@subsubheading Adding variants of font glyphs |
@@ -98,32 +98,6 @@ it. |
@emph{Mentor:} Werner Lemberg |
-@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 Rewrite LibreOffice LilyPond Extension with Python |
The @uref{http://ooolilypond.sourceforge.net/, OOoLilyPond} extension |
@@ -151,82 +125,84 @@ or willingness to learn during bonding period |
@emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice) |
-@subsubheading Automated testing and documentation for openLilyLib |
+@subsubheading Fix Beaming Patterns/Beam Subdivisions and Tuplets |
-@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. |
+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}). |
-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 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. |
-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. |
+@emph{Difficulty:} medium |
-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{Requirements:} C++ |
-@emph{Difficulty:} medium |
+@emph{Recommended knowledge:} Good musical and mathematical understanding |
+of timing issues |
-@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) |
+@emph{Mentor(s):} Urs Liska, Carl Sorensen |
-@emph{Mentors:} Urs Liska, Matteo Ceccarello |
+@subsubheading Contemporary Notation |
-@subsubheading MusicXML |
+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. |
-Improving MusicXML import and export functions: |
+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. |
-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. |
+@emph{Difficulty:} medium |
-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. |
+@emph{Requirements:} Scheme (interaction with LilyPond internals), |
+contemporary notation techniques |
-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{Recommended:} sense of building hierarchical frameworks |
+ |
+@emph{Mentors:} @emph{NN,} Urs Liska |
+ |
+ |
+@subsubheading Extending scholarly editing features |
+ |
+The @uref{https://github.com/openlilylib/scholarly, scholarLY} |
+extension package provides a powerful infrastructure for scholarly |
+editions. With this package it is possible to encode annotations, |
+to export them for critical reports, or to produce editorial |
+highlighting in the score (e.g. dashing, parenthesizing etc.), |
+footnotes etc. |
+ |
+As a GSoC project substantial enhancements can be made to the |
+package. Our suggestion is an infrastructure to encode |
+@emph{variants} (alternative readings, corrections, regularizations), |
+as outlined in |
+@uref{https://github.com/openlilylib/scholarly/issues/61, this issue}. |
+It could naturally be extended by the ability to produce music examples |
+from annotations, to be used in footnotes or reports. |
@emph{Difficulty:} medium |
-@emph{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge |
+@emph{Requirements:} Scheme, ability to assess an extensive existing |
+package |
-@emph{Recommended:} Familiarity with other scorewriters (for cross-testing) |
+@emph{Recommended:} familiarity with scholarly editing |
-@emph{Mentor:} Jan-Peter Voigt |
+@emph{Mentors:} @emph{NN,} Urs Liska |
@divEnd |
@@ -317,6 +293,82 @@ 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) |
+ |
+@divEnd |
+ |
+ |
@subsubheading Improve slurs and ties |
The engraving quality of slurs and ties is often unsatisfactory. Ties |