Skip to content

GSoC

Jump to bottom
Urs Liska edited this page Jan 26, 2016 · 3 revisions

ScholarLY is one of LilyPond's suggested projects for the Google Summer of Code 2016. This document outlines the current state of the library and necessary as well as optional parts of such a GSoC application.

Although already very useful, ScholarLY is currently quite limited compared to its potential functionality. This is what the GSoC project should tackle. There is a pretty clear vision as to where development should go, and there is a distinct list of feature requests (although this could presumably be extended endlessly ...).

However, this is not an all-or-nothing development: more or less any step that is achieved will be vailable afterwards and may have simplified the next step. Not all tasks are equally suited for a GSoC project, and some require a different skill sets. We will be able to define the course of action and to choose a list of to-be-tackled tasks. In the course of the program we will then work through the list from top down to the bottom as far as we can get.

Current Functionality

The main component of ScholarLY that is already in place is the annotate module loaded with

\include "openlilylib"
\useLibrary ScholarLY
\useModule ScholarLY.annotate

This allows the inclusion of different kinds of annotations within a LilyPond input file. Annotations affect a specified grob (GRaphical OBject) and contain a set of mandatory and optional arguments as well as optionally unknown arguments.

The behaviour of annotations is highly configurable and can contain:

  • determining the current position in the score (measure, position in measure)
  • highlighting the affected items with colors
    (additionally LilyPond's point-and-click works together with this)
  • printing clickable messages to the console output that link back to the input code
  • exporting annotations to plain text files
  • exporting annotations to files that can be included in LaTeX documents
  • filtering and sorting the annotations to be output

Feature Requests

Functions to reflect editorial decisions in the engraving

Usually editorial decisions are reflected by typographical means such as using dashed lines, smaller font size, parentheses and the like. ScholarLY should have a set of stylesheet-like music functions for this purpose. So the first task is to define a set of functions that correspond to editorial decisions such as additions, emendations etc. The user interface to these functions should be consistently designed, and the visual appearance has to be sufficiently configurable to great detail.

These functions have to be usable standalone, but they should also be triggered by annotations (so there's a direct link between an item, an attached annotation, the corresponding entry in the critical report, and the visual representation in the score.

Enhancements to the annotations

  • Insert music examples in annotations
    It is often a necessity to add music examples to annotations. There should be an interface allowing arbitrary numbers of \score blocks to be inserted in annotation messages. When annotations are exported these should be compiled and the content replaced with an include link to the resulting file.
  • Allow annotations to produce footnotes
  • Allow annotations to print graphical comments
  • Enhance support for attributing annotations to multiple authors
  • Additional text formats
    Free-form properties (such as the message) should have different options regarding the input language. Besides plain text these fields should also be able to properly parse LaTeX and Markdown (with included HTML) syntax.
  • Provide support for custom annotation properties
    Users should be allowed to configure special support for custom annotation types.

Enhancements to the processing of annotations

  • Make LaTeX output more robust
  • Add output formats:
    • Markdown
    • HTML
    • Scheme
      Scheme is crucial for the attempt of later producing the critical report directly.
  • Produce PDF/HTML reports with point-and-click links
  • Produce critical reports in LilyPond
    It should be possible to produce a critical report as part of the LilyPond compilation. This may imply writing out to temporary files and re-running LilyPond (like with LaTeX's table of contents etc.).

Optional tasks

There are a few tasks that might not be suitable for a GSoC project, but they are on the roadmap anyway.

LaTeX package

There should be a LaTeX package that can be used to typeset critical remarks from the output of ScholarLY's annotations. This package will be quite complex as it has rather sophisticated requirements:

  • Support templating or other means of configuring the output appearance
  • Possibly support filtering and sorting
    (so it has to go a bit in the direction of e.g. bibTeX)
  • Support printing included music examples
  • provide an interface so the user can support custom annotation or property types

Frescobaldi User Interface

Frescobaldi should get a graphical user interface to support annotations:

  • Entering annotations through the context menu
  • have a dialog assist in entering/editing annotations
  • provide a tool to browse, filter and sort annotations (with the option of editing any annotation or to jump to the originating input).

The LaTeX package is a pretty integral part of ScholarLY, and it should only be omitted from a GSoC project if it would otherwise not work out. The Frescobaldi interface OTOH is something that wouldn't natively fit into the GSoC project but could be added if the student expresses explicit interest in that area (and knows Python).

Clone this wiki locally