Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(33)

Unified Diff: Documentation/included/gsoc.itexi

Issue 338320043: Web: Update GSoC pages
Patch Set: Another fix for getting make to run Created 6 years, 2 months ago
Use n/p to move between diff chunks; N/P to move between comments. Please Sign in to add in-line comments.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « no previous file | no next file » | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
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
« no previous file with comments | « no previous file | no next file » | no next file with comments »

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b