@ref{News}: news from the LilyPond project.
@item
-@ref{Attic}: announcements and changelogs from past versions.
+@ref{Attic}: announcements and changelogs from past versions,
+old news, etc.
@end itemize
@divEnd
Once a bug has been added to the tracker, you can comment it to add
more information about it.
-You may also mark the bug so that you automatically receive emails when
-any activity on the bug occurs. This requires you have a google account
-login.
+In order to be automatically notified about any activity on the
+tracker issue, you may subscribe by clicking the envelope
+symbol next to the issue title.
+Commenting and subscribing require being logged in with a sourceforge account.
@divEnd
@divClass{column-center-bottom}
Interested developers:
@table @asis
-@item @email{dak@@gnu.org, David Kastrup}
-Donations are required to let me continue my current fulltime work on
-LilyPond. I focus on user and programmer interface design, coherence,
-implementation, simplification, documentation, and debugging.
+@item @email{lilypond-devel@@gnu.org, LilyPond developer list}
+Since no developer currently is listed for commercial development,
+your best bet is asking on the developer list.
@c Format
@c @item @email{name@@adress.domain, Name}
@divClass{column-center-top}
@subheading What is Google Summer of Code?
-@uref{https://developers.google.com/open-source/gsoc/, GSoC} is a global
-program that offers students stipends to write code for free software
-and open source projects during the summer. It is an excellent
+@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 and 2015 and encourage students to
-apply for future summers.
+We have had GSoC participants in 2012, 2015 and 2016 and encourage
+students to apply for the 2017 program.
-If you have questions or would like to apply, send us an email on our
-developer mailing list (see @ref{Contact}).
+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 @ref{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.
@divEnd
-@divClass{column-center-middle-color2}
+@divClass{column-center-middle-color2 bigger-subsubheadings}
@subheading Project Ideas List
-Below is a list of suggested projects for GSoC or for anyone who is
-interested in helping to improve LilyPond. (Last updated: February 2016)
-
-Mentor availability varies from project to project and from year to year.
-Send us an email on our developer mailing list (see @ref{Contact}), and
-we will help you find a mentor for a project that fits your interests
-and skills.
-
-If you have ideas for a GSoC project that is not listed below you can
-send us an email as well. 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 like those listed below.
+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 @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.
A full list of all the current open issues can be found
@uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
-@divEnd
-@divClass{column-center-middle-color3}
-@subheading Improve internal chord structure
+@subsubheading 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
representation is developed, the output formatting of chord names can
be improved.
-@strong{Difficulty:} Easy/medium
-@strong{Requirements:} Scheme (Guile), but the level necessary can be
+@emph{Difficulty:} Easy/medium
+
+@emph{Requirements:} Scheme (Guile), but the level necessary can be
easily learned
-@strong{Recommended:} Chord theory and naming
-@strong{Mentor:} Carl Sorensen
-@divEnd
+@emph{Recommended:} Chord theory and naming
-@divClass{column-center-middle-color3}
-@subheading ScholarLY
-
-ScholarLY is a library in
-@uref{https://openlilylib.org, openLilyLib} that provides functionality
-for annotating scores, making it possible to manage scholarly workflows
-completely in the context of the score document. So far it is possible
-to enter annotations of different types, produce clickable messages in
-the console output and export to text and LaTeX files.
-
-There are numerous feature requests to turn this library into an
-even more powerful and comprehensive tool. Some examples: Inserting
-music examples, producing footnotes, automatically applying styles
-to the annotated item (e.g. dash a slur, parenthesize an accidental),
-creating reports with point-and-click entries. For a full description
-of this project suggestion please visit
-@uref{https://github.com/openlilylib/scholarly/wiki/GSoC, this Wiki page}.
-
-@strong{Difficulty:} medium
-@strong{Requirements:} Scheme, possibly LaTeX, (optionally Python)
-@strong{Recommended:} Experience with or interest in scholarly
-edition and collaborative workflows.
-@strong{Mentor:} Urs Liska
+@emph{Mentor:} Carl Sorensen
-@divEnd
-@divClass{column-center-middle-color3}
-@subheading Adding variants of font glyphs
+@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
@end itemize
@divEnd
-@strong{Difficulty:} easy
-@strong{Requirements:} MetaFont, C++, good eye for details
-@strong{Recommended knowledge:} basic LilyPond knowledge
-@strong{Mentor:} Werner Lemberg
+@emph{Difficulty:} easy
-@divEnd
+@emph{Requirements:} MetaFont, C++, good eye for details
-@divClass{column-center-middle-color3}
-@subheading Grace notes
+@emph{Recommended knowledge:} basic LilyPond knowledge
-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://sourceforge.net/p/testlilyissues/issues/34/,bugs} in
-LilyPond.
+@emph{Mentor:} Werner Lemberg
-@strong{Difficulty:} medium
-@strong{Requirements:} C++, MIDI
-@strong{Recommended:} familiarity with LilyPond internals
-@strong{Potential Mentors:} Mike Solomon (not available for GSoC 2016),
-Carl Sorensen
-@divEnd
+@subsubheading Contemporary Notation
-@divClass{column-center-middle-color3}
-@subheading Improve default beam positioning
+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.
-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.
+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.
-@strong{Difficulty:} medium
-@strong{Requirements:} C++, experience with writing heuristics
-@strong{Recommended knowledge:} aesthetic sense
-@strong{Potential Mentors:} Mike Solomon (not available for GSoC 2016),
-Carl Sorensen
+@emph{Difficulty:} medium
-@divEnd
+@emph{Requirements:} Scheme (interaction with LilyPond internals),
+contemporary notation techniques
-@divClass{column-center-middle-color3}
-@subheading Allow spanners to cross voices
+@emph{Recommended:} sense of building hierarchical frameworks
-Currently all sorts of spanners (ties, slurs, dynamics, text spanners,
-trills etc.) have to be ended in the context they were started. However,
-this doesn't reflect the reality of notation in most polyphonic settings.
-Awkward workarounds with hidden voices are currently necessary to achieve
-cross-voice spanners.
+@emph{Mentors:} @emph{NN,} Urs Liska
-New ways of addressing this issue should be explored, for example by
-@divClass{keep-bullets}
-@itemize
+@subsubheading Rewrite LibreOffice LilyPond Extension with Python
-@item specifying a “target context” where the end of the spanner is
-expected
+The @uref{http://ooolilypond.sourceforge.net/, OOoLilyPond} extension
+made it possible to conveniently include LilyPond score snippets in
+OpenOffice.org/LibreOffice Writer, Draw and Impress documents while
+keeping source and image together. After many years without development
+an initial effort has started to make the extension compatible again
+with current versions of LibreOffice and LilyPond.
-@item explicitly specifying the ending object with an ID
+However, as the LibreOffice ecosystem has changed substantially it is
+now possible to rewrite the extension with Python and PyQt. This will
+not only be more powerful in general but will allow the integration of
+functionality from @uref{http://frescobaldi.org, Frescobaldi}, such as
+for example syntax highlighting, entry helpers, score wizards or musical
+transformations.
-@end itemize
-@divEnd
+@emph{Difficulty:} easy/medium
-This feature would solve many problems that are commonly faced with
-piano music and combined parts.
+@emph{Requirements:} Python, PyQt, LilyPond basics, LibreOffice
+extension basics
-@strong{Difficulty:} medium (?)
-@strong{Requirements:} C++, Scheme
-@strong{Potential Mentor:} Urs Liska
-@divEnd
+@emph{Recommended knowledge:} Familiarity with Frescobaldi code based
+or willingness to learn during bonding period
-@divClass{column-center-middle-color3}
-@subheading Help improve compilation behavior
+@emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
-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.
-@strong{Difficulty:} medium
-@strong{Requirements:} C++
-@strong{Potential Mentors:} Reinhold Kainhofer (not available for GSoC
-2016), Joe Neeman
+@subsubheading Automated testing and documentation for openLilyLib
-@divEnd
+@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.
-@divClass{column-center-middle-color3}
-@subheading MusicXML
+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)
+
+@emph{Mentors:} Urs Liska, Matteo Ceccarello
+
+
+@subsubheading MusicXML
Improving MusicXML import and export functions:
-@divClass{keep-bullets}
-@itemize
+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.
-@item
-Handle basic musical content export like the MIDI export (i.e. using
-dedicated exporter classes, derived from the translator class).
+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.
-@item
-Build the XML tree of the basic musical content, add a connection from
-music event to XML tag.
+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).
-@item
-Let all LilyPond engravers do their job.
+@emph{Difficulty:} medium
-@item
-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).
+@emph{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge
-@item
-Add an XML output backend, which can then add layout information for
-each output object to the XML tags.
+@emph{Recommended:} Familiarity with other scorewriters (for cross-testing)
+
+@emph{Mentor:} Jan-Peter Voigt
-@end itemize
@divEnd
-There are several possibilities for this project, including building upon
-the MusicXML export project from GSoC 2015.
-@strong{Difficulty:} medium
-@strong{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge
-@strong{Potential Mentors:} Reinhold Kainhofer, Mike Solomon (both not
-available for GSoC 2016)
+@divClass{column-center-middle-color2}
+@subheading Information for Applicants/Participants
-Familiarity with other scorewriters (for cross-testing) would also help.
+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.
-@divEnd
+@itemize
-@divClass{column-center-middle-color3}
-@subheading Improve slurs and ties
+@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.
-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.
+@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.
-@strong{Difficulty:} hard
-@strong{Requirements:} C++, experience with writing heuristics
-@strong{Recommended knowledge:} LilyPond knowledge, aesthetic sense
-@strong{Potential Mentors:} Mike Solomon, Janek Warchoł (both not available for
-GSoC 2016)
+@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.
-@divEnd
+@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{http://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
@node Authors
@unnumberedsec Authors
@node News
@unnumberedsec News
-@divClass{heading-center}
-@warning{Many old announcements and changelogs can be found in
-the @ref{Attic}}
-@divEnd
-
-@include web/news-front.itexi
-
-@include web/news.itexi
+@include web/news-new.itexi
+@divClass{column-center-bottom}
+@subheading Old News
+Older news can be found in the @ref{Attic}, along with older
+announcements and changelogs
+@divEnd
@node Attic
@unnumberedsec Attic
@divEnd
-@divClass{column-center-bottom}
+@divClass{column-center-middle-color3}
@subheading Thanks
Thanks to developers, contributors, bug hunters and suggestions for
@divEnd
-@divClass{column-center-bottom}
+@divClass{column-center-middle-color3}
@subheading Changelogs
Developers' changelogs by version:
@miscLink{CHANGES-0.0,v0.0}
@divEnd
+
+@divClass{column-center-middle-color2 bigger-subsubheadings}
+@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 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://sourceforge.net/p/testlilyissues/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
+
+@divClass{column-center-middle-color2}
+@subheading Old News
+
+Older news items dating back to July 2003. Newer news can be found on
+the @ref{News} page.
+@divEnd
+
+@include web/news-old.itexi
projects / lilypond.git / blobdiff