@c -*- coding: utf-8; mode: texinfo; -*- @ignore Translation of GIT committish: FILL-IN-HEAD-COMMITTISH When revising a translation, copy the HEAD committish of the version that you are working on. For details, see the Contributors' Guide, node Updating translation committishes.. @end ignore @include included/acknowledge.itexi @include included/authors.itexi @include included/helpus.itexi @node Community @unnumbered Community @divClass{link-headings} @divClass{column-center-top} @subheading Interacting with the community @itemize @item @ref{Contact}: get help, discuss, and keep in touch! @item @ref{Tiny examples}: these are @emph{highly} recommended when discussing LilyPond. @item @ref{Bug reports}: something went wrong. @end itemize @divEnd @divClass{column-left-bottom} @subheading Making LilyPond better @itemize @item @ref{Help us}: your assistance is requested. @item @ref{Sponsoring}: financial contributions. @item @ref{Development}: for contributors and testers. @item @ref{Google Summer of Code}: ideas for Google Summer of Code (GSoC). @item @ref{Authors}: the people who made LilyPond what it is today. @item @ref{Acknowledgements}: projects and institutions that support LilyPond @end itemize @divEnd @divClass{column-right-bottom} @subheading Miscellaneous @itemize @item @ref{Publications}: what we wrote, and have had written about us. @item @ref{News}: news from the LilyPond project. @item @ref{Attic}: announcements and changelogs from past versions, old news, etc. @end itemize @divEnd @divEnd @divClass{hide} @menu * Contact:: * Tiny examples:: * Bug reports:: * Help us:: * Sponsoring:: * Development:: * Google Summer of Code:: * Authors:: * Acknowledgements:: * Publications:: * News:: * Attic:: @end menu @divEnd @node Contact @unnumberedsec Contact @divClass{column-left-bottom} @subheading User Discussions and Help @subsubheading User mailing list: @code{lilypond-user@@gnu.org} This mailing list is the main place for users to discuss and help each other. @quotation @uref{http://lists.gnu.org/mailman/listinfo/lilypond-user, lilypond-user subscribe and info} @uref{http://lists.gnu.org/archive/html/lilypond-user/, user archive1} @uref{http://www.mail-archive.com/lilypond-user@@gnu.org/, archive2} @uref{http://dir.gmane.org/gmane.comp.gnu.lilypond.general, archive3} @uref{http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.general, send to lilypond-user with gmane} @end quotation @warning{When asking questions, please use @ref{Tiny examples}!} @subsubheading LilyPond Snippet Repository The LilyPond Snippet Repository is a large collection of user-submitted examples, which can freely be copied and used in your own works. See what other people have written, and add your own! @example @uref{http://lsr.di.unimi.it} @end example Particularly instructive examples from LSR are included in our official documentation, in @ref{Snippets}. @subsubheading IRC Some level of support is provided on our IRC channel, @example @uref{irc://irc.freenode.net/lilypond, #lilypond@@irc.freenode.net} @end example This channel has no public archive, so any question that may be useful for others would better be posted to one of the mailing lists. @html
irc name:
@end html @subsubheading Other languages @quotation @uref{http://lists.gnu.org/mailman/listinfo/lilypond-user-fr, French mailing list} @uref{http://www.lilypondforum.de/, German forum} @uref{http://groups.google.com/group/lilypond-brasil, Portuguese group} @uref{http://lists.gnu.org/mailman/listinfo/lilypond-es, Spanish mailing list} @end quotation @divEnd @divClass{column-right-top} @subheading The LilyPond Blog Read our community blog, @q{Scores of Beauty}: @example @uref{http://lilypondblog.org} @end example @subsubheading Releases mailing list: @code{info-lilypond@@gnu.org} This mailing list is a low-volume, read-only list which receives notifications of new releases. @quotation @uref{http://lists.gnu.org/mailman/listinfo/info-lilypond, info-lilypond subscribe and info} @uref{http://lists.gnu.org/archive/html/info-lilypond/, info archive1} @uref{http://www.mail-archive.com/info-lilypond@@gnu.org/, archive2} @uref{http://dir.gmane.org/gmane.comp.gnu.lilypond.announce, archive3} @c don't include gmane posting here. -gp @end quotation @divEnd @divClass{column-right-bottom} @subheading Developer Discussions and Translations @subsubheading Developer mailing list: @code{lilypond-devel@@gnu.org} Developer discussions take place on this list. Patches can also be sent here. @quotation @uref{http://lists.gnu.org/mailman/listinfo/lilypond-devel, lilypond-devel subscribe and info} @uref{http://lists.gnu.org/archive/html/lilypond-devel/, devel archive1} @uref{http://www.mail-archive.com/lilypond-devel@@gnu.org/, archive2} @uref{http://dir.gmane.org/gmane.comp.gnu.lilypond.devel, archive3} @uref{http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.devel, send to lilypond-devel with gmane} @end quotation @subsubheading Bug mailing list: @code{bug-lilypond@@gnu.org} Bug reports and discussions should be sent here. Do not send patches to this list. @quotation @uref{http://lists.gnu.org/mailman/listinfo/bug-lilypond, bug-lilypond subscribe and info} @uref{http://lists.gnu.org/archive/html/bug-lilypond/, bug archive1} @uref{http://www.mail-archive.com/bug-lilypond@@gnu.org/, archive2} @uref{http://dir.gmane.org/gmane.comp.gnu.lilypond.bugs, archive3} @c don't include gmane posting here. -gp @end quotation @warning{Before sending a message to the bug list, please read our guidelines for @ref{Bug reports}.} @subsubheading Translation mailing list: @code{translations@@lilynet.org} All discussions about translating LilyPond manuals should be sent here. Do not send patches to this list. @quotation @uref{http://lilypond-translations.3384276.n2.nabble.com/, Translation mailing list archive} @end quotation @divEnd @node Tiny examples @unnumberedsec Tiny examples @divClass{column-center-top} @subheading What are @qq{Tiny examples}? A tiny example is an example from which @strong{nothing} can be removed. @divEnd @divClass{column-left-bottom} @subheading Why create them? @divClass{keep-bullets} @itemize @item The simpler the example is, the quicker potential helpers can understand it and help you. @item A tiny example demonstrates that you have put effort towards solving the problem yourself. When people send huge portions of input, it looks like they don't care if we help them or not. @item Creating a tiny example helps you to understand what is happening. Many false problem reports can be avoided by attempting to create a tiny example; if you cannot replicate a @qq{bug} in a tiny example, then the problem was probably an insufficient understanding of LilyPond, not an actual bug! @end itemize @divEnd @divEnd @divClass{column-right-bottom} @subheading How to create them? @divClass{keep-bullets} @itemize @item Include the @code{\version} number. @item Make it small! Examples about spacing or page layout might require many bars of music, but most issues can be reproduced using less than a single measure. @item When trying to create an example, try commenting out @w{(@code{%} or @code{%@{ @dots{} %@}})} sections of your file. If you can comment something while still demonstrating the main idea, then remove the commented-material. @item Avoid using complicated notes, keys or time signatures, unless the bug is about the behavior of those items. @item Do not use @code{\override} or @code{\set} commands unless the bug is about those specific commands. @item Optionally, attach an image showing the desired graphical output. @end itemize @divEnd @divEnd @divClass{column-center-bottom} @subheading How tiny should they be? Is the code below a minimal example? @example \version "2.14.1" \include "english.ly" \score @{ \new Staff @{ \key d \major \numericTimeSignature \time 2/4 16 8. %% Here: the tie on the D's looks funny %% Too tall? Left-hand endpoint is not aligned with the B tie? ~ 8 [ ] @} @} @end example Well, it is not very big, but a truly minimal example is here: @example \version "2.14.1" @{ % middle tie looks funny here: 8. ~ 8 @} @end example Very few tiny examples exceed 10 lines of code - quite often 4 lines are enough to demonstrate the problem! @divEnd @node Bug reports @unnumberedsec Bug reports @divClass{heading-center} If you have input that results in a crash or wrong output, then that is a bug. @divEnd @divClass{column-center-top} @subheading Step 1: Known bugs We may already know about this bug. Check here: @example @uref{http://sourceforge.net/p/testlilyissues/issues/} @end example @warning{Please @strong{DO NOT} add bug reports directly to the bug tracker. Once an issue has been added to the tracker, feel free to add more information to that report.} @divEnd @divClass{column-left-bottom} @subheading Step 2: Creating a bug report If you have discovered a bug which is not listed, please help us by creating a bug report. @warning{We only accept reports in the form of @ref{Tiny examples}. We have very limited resources, so any non-minimal example will be rejected. Almost every bug can be demonstrated in four notes or less!} Here is an example of a good bug report: @example % Accidentals should be printed for only % the first note in a tie, but this version % prints flats on both notes. \version "2.10.1" \relative c'' @{ bes1 ~ bes1 @} @end example @divEnd @divClass{column-right-bottom} @subheading Step 3: Sending a bug report Once you have verified that the issue is not already known and created a bug report, please send it to us! @divClass{keep-bullets} @itemize @item If you are subscribed to the @uref{mailto:bug-lilypond@@gnu.org, bug-lilypond@@gnu.org} mailing list, send an email like normal. @item If you are not subscribed, you can still post a bug report with the @uref{http://post.gmane.org/post.php?group=gmane.comp.gnu.lilypond.bugs, gmane lilypond.bugs web interface}. However, there is a strict @qq{no top-posting} check on the gmane interface, which is often incorrectly triggered by lilypond files. To avoid this, please add: @example > I'm not top posting. @end example @noindent (you @emph{must} include the @code{>} ) to the top of your bug report. @end itemize @divEnd @divEnd @divClass{column-center-bottom} @subheading Step 4: Wait for a response Once your bug report has been sent to the list, our Bug Squad will examine it; they may ask you for more information. You will be notified when the report will be added to the bug tracker. Please allow up to 4 days, as we have a limited number of volunteers for this task. Once a bug has been added to the tracker, you can comment it to add more information about it. 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} @subheading Optional help: show the desired behavior Once an issue has been added to the tracker, it can be very helpful if we can see the desired output. Feel free to add input code and/or images (possibly created with other tools) which demonstrate what you think it should look like! @divEnd @node Help us @unnumberedsec Help us @divClass{column-center-top} @helpusNeed @divEnd @divClass{column-left-top} @divClass{keep-bullets} @helpusSimple @divEnd @divEnd @divClass{column-right-top} @helpusAdvanced @divEnd @node Sponsoring @unnumberedsec Sponsoring @divClass{keep-bullets} @divClass{column-left-top} @subheading Bounties In the past, @itemize @item some users have paid for new features @item some developers have added new features for hire @end itemize The LilyPond project does not organize such efforts; we neither endorse nor discourage such agreements. Any contracts between private individuals is the business of those individuals, not ours. @divEnd @divClass{column-right-top} @subheading Guidelines Any user wanting to offer money in exchange for work should bear in mind the following points: @itemize @item LilyPond developers may advertise their services on the lilypond email lists from time to time. @item Any agreements between private individuals should include the normal precautions when conducting business: who pays, how much do they pay, with what method of payment, and upon what set of conditions. We suggest that any ambiguity or uncertainty in these questions should be resolved before any work begins. @end itemize @divEnd @divClass{column-center-bottom} @subheading Interested developers Here is a list of people who have expressed an interest in bounties. Note that the amount of work done by individuals varies quite a bit throughout the years. We do not guarantee that this list is up-to-date, nor do we guarantee that the people listed here have any ability. The only criteria is "XYZ asked to be listed on this page". Looking at the git history is a good way to determine who the most active and experienced developers are. Statistics up to version @versionDevel{}: @multitable @columnfractions .3 .3 .3 @item @uref{http://lilypond.org/~graham/gitstats-all/, overall history} @tab @uref{http://lilypond.org/~graham/gitstats-1year/, past year} @tab @uref{http://lilypond.org/~graham/gitstats-3months/, past three months} @end multitable Interested developers: @table @asis @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} @c area of interest (256 chars max) @end table @divEnd @divEnd @node Development @unnumberedsec Development @divClass{heading-center} @ifclear web_version @heading Development for LilyPond @version @end ifclear @ifset web_version @heading Development for LilyPond @versionDevel @end ifset @c we normally don't allow named references, but in this case @c it's good to emphasize the "stable" part. -gp @warning{These are @emph{unstable development} versions. If you have the slightest doubt about how to use or install LilyPond, we urge you to use the @ref{Download, stable Download}, and read the @ref{Manuals, stable Manuals}.} @divEnd @divClass{column-center-top} @subheading Release numbers There are two sets of releases for LilyPond: stable releases, and unstable development releases. Stable versions have an even-numbered @q{minor} version number (e.g., 2.8, 2.10, 2.12). Development versions have an odd-numbered @q{minor} version number (e.g., 2.7, 2.9, 2.11). @divEnd @divClass{column-left-top} @subheading Download Instructions for git and compiling are in the Contributor's Guide. @quotation @uref{http://git.sv.gnu.org/gitweb/?p=lilypond.git, lilypond git repository} @end quotation Documentation writers and testers will generally want to download the latest binary: @quotation @downloadDevelLinuxNormal @downloadDevelLinuxBig @downloadDevelLinuxPPC @downloadDevelFreeBSDNormal @downloadDevelFreeBSDBig @downloadDevelDarwinNormal @downloadDevelDarwinPPC @downloadDevelWindows @downloadDevelSource @end quotation @divEnd @divClass{column-right-top} @subheading Contributor's Guide LilyPond development is a fairly complicated matter. In order to help new contributors, and to keep the whole system (mostly) stable, we have written a manual for development tasks. @docLinksBare{Contributor's Guide, contributor, @rcontribnamed{Top,Contributor's Guide}, @manualDevelContributorSplit, @manualDevelContributorBig, 500 kB, @manualDevelContributorPdf, 2.8 MB} @divEnd @divClass{column-center-top} @subheading Regression tests @divClass{keep-bullets} @ifclear web_version @itemize @item @uref{../../input/regression/collated-files.html, Regression tests}: This release's regtests. (@uref{../../input/regression/collated-files.pdf, pdf version}) @item @uref{../../input/regression/musicxml/collated-files.html, MusicXML tests}: This release's musicXML tests. (@uref{../../input/regression/musicxml/collated-files.pdf, pdf version}) @item @uref{../../input/regression/abc2ly/collated-files.html, abc2ly tests}: This release's abc2ly tests. (@uref{../../input/regression/abc2ly/collated-files.pdf, pdf version}) @item @uref{../../input/regression/lilypond-book/collated-files.html, lilypond-book tests}: This release's lilypond-book tests. (@uref{../../input/regression/lilypond-book/collated-files.pdf, pdf version}) @end itemize @end ifclear @ifset web_version @subsubheading Development version @itemize @item @regtestDevel (@regtestDevelPdf{}) @item @regtestDevelXml (@regtestDevelXmlPdf{}) @item @regtestDevelAbc (@regtestDevelAbcPdf{}) @item @regtestDevelLilypondBook (@regtestDevelLilypondBookPdf{}) @end itemize @subsubheading Stable version @itemize @item @regtestStable (@regtestStablePdf{}) @item @regtestStableXml (@regtestStableXmlPdf{}) @item @regtestStableAbc (@regtestStableAbcPdf{}) @item @regtestStableLilypondBook (@regtestStableLilypondBookPdf{}) @end itemize @end ifset @subsubheading All versions @itemize @item @uref{http://lilypond.org/test, Comparisons between regression tests} @item @uref{http://lilypond.org/downloads/binaries/test-output/, Archive of all regression tests} @end itemize @divEnd @divEnd @divClass{column-center-bottom} @subheading Manuals @ifclear web_version @warning{These manuals are for LilyPond @version{}; the latest manuals can be found at @url{http://lilypond.org}} @end ifclear @divClass{normal-table} @multitable @columnfractions .3 .3 .3 @headitem Introduction @item @docLinkSplit{Learning,learning,@manualDevelLearningSplit} @tab @docLinkBig{Learning,learning,@manualDevelLearningBig} @tab @docLinkPdf{Learning,learning,@manualDevelLearningPdf} @item @docLinkSplit{Glossary,music-glossary,@manualDevelGlossarySplit} @tab @docLinkBig{Glossary,music-glossary,@manualDevelGlossaryBig} @tab @docLinkPdf{Glossary,music-glossary,@manualDevelGlossaryPdf} @item @docLinkSplit{Essay,essay,@manualDevelEssaySplit} @tab @docLinkBig{Essay,essay,@manualDevelEssayBig} @tab @docLinkPdf{Essay,essay,@manualDevelEssayPdf} @end multitable @multitable @columnfractions .3 .3 .3 @headitem Regular @item @docLinkSplit{Notation,notation,@manualDevelNotationSplit} @tab @docLinkBig{Notation,notation,@manualDevelNotationBig} @tab @docLinkPdf{Notation,notation,@manualDevelNotationPdf} @item @docLinkSplit{Usage,usage,@manualDevelUsageSplit} @tab @docLinkBig{Usage,usage,@manualDevelUsageBig} @tab @docLinkPdf{Usage,usage,@manualDevelUsagePdf} @item @docLinkSplit{Snippets,snippets,@manualDevelSnippetsSplit} @tab @docLinkBig{Snippets,snippets,@manualDevelSnippetsBig} @tab @docLinkPdf{Snippets,snippets,@manualDevelSnippetsPdf} @end multitable @multitable @columnfractions .3 .3 .3 @headitem Infrequent @item @docLinkSplit{Web,web,@manualDevelWebSplit} @tab @docLinkBig{Web,web,@manualDevelWebBig} @tab @docLinkPdf{Web,web,@manualDevelWebPdf} @item @docLinkSplit{Changes,changes,@manualDevelChangesSplit} @tab @docLinkBig{Changes,changes,@manualDevelChangesBig} @tab @docLinkPdf{Changes,changes,@manualDevelChangesPdf} @item @docLinkSplit{Extending,extending,@manualDevelExtendingSplit} @tab @docLinkBig{Extending,extending,@manualDevelExtendingBig} @tab @docLinkPdf{Extending,extending,@manualDevelExtendingPdf} @item @docLinkSplit{Internals,internals,@manualDevelInternalsSplit} @tab @docLinkBig{Internals,internals,@manualDevelInternalsBig} @tab @docLinkPdf{Internals,internals,@manualDevelInternalsPdf} @end multitable @ifset web_version @multitable @columnfractions .3 @headitem Downloadable @item @doctarballDevel @end multitable @end ifset @divEnd @divEnd @node Google Summer of Code @unnumberedsec Google Summer of Code @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 and 2016 and encourage students to apply for the 2017 program. 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 bigger-subsubheadings} @subheading Project Ideas List 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}. @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 a root, a bass and an inversion. It would be nice to be able to handle stacked or polychords, minor/major, etc. In order to do this, an internal representation with the ability to capture the essence of complex chords must be developed. As a bonus, once the internal representation is developed, the output formatting of chord names can be improved. @emph{Difficulty:} Easy/medium @emph{Requirements:} Scheme (Guile), but the level necessary can be easily learned @emph{Recommended:} Chord theory and naming @emph{Mentor:} Carl Sorensen @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 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 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. 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. @emph{Difficulty:} easy/medium @emph{Requirements:} Python, PyQt, LilyPond basics, LibreOffice extension basics @emph{Recommended knowledge:} Familiarity with Frescobaldi code based or willingness to learn during bonding period @emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice) @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) @emph{Mentors:} Urs Liska, Matteo Ceccarello @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) @emph{Mentor:} Jan-Peter Voigt @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{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 @divClass{column-left-top} @subheading Current Development Team @divClass{keep-bullets} @developersCurrent @divEnd @divEnd @divClass{column-right-top} @subheading Previous Development Team @divClass{keep-bullets} @developersPrevious @divEnd @divEnd @divClass{column-center-top} @subheading Current Contributors @divClass{keep-bullets} @subsubheading Programming @coreCurrent @subsubheading Font @fontCurrent @subsubheading Documentation @docCurrent @subsubheading Bug squad @bugsquadCurrent @subsubheading Support @supportCurrent @subsubheading Translation @translationsCurrent @divEnd @divEnd @divClass{column-center-bottom} @subheading Previous Contributors @divClass{keep-bullets} @subsubheading Programming @corePrevious @subsubheading Font @fontPrevious @subsubheading Documentation @docPrevious @c uncomment when we have any previous members -gp @c @subsubheading Bug squad @c @bugsquadCurrent @subsubheading Support @supportPrevious @subsubheading Translation @translationsPrevious @divEnd @divEnd @node Acknowledgements @unnumberedsec Acknowledgements @divClass{column-center-top} @subheading Acknowledgements @divClass{keep-bullets} @acknowledgementsCurrent @divEnd @divEnd @node Publications @unnumberedsec Publications @divClass{column-center-top} @subheading What we wrote about LilyPond @divClass{keep-bullets} @include we-wrote.itexi @divEnd @divEnd @divClass{column-center-bottom} @subheading What people did with LilyPond @divClass{keep-bullets} @include others-did.itexi @divEnd @divEnd @contactUsAbout{academic papers} @node News @unnumberedsec News @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 @divClass{column-center-top} @subheading Announcements Announcements and news by version: @uref{http://lilypond.org/doc/v2.16/Documentation/web/index#Lilypond-2_002e16_002e0-released_0021-August-24_002c-2012-1,v2.16}, @uref{http://lilypond.org/doc/v2.14/Documentation/web/index#LilyPond-2_002e14_002e0-released_0021-June-6_002c-2011,v2.14}, @miscLink{announce-v2.12,v2.12}, @miscLink{announce-v2.10,v2.10}, @miscLink{announce-v2.8,v2.8}, @miscLink{announce-v2.6,v2.6}, @miscLink{announce-v2.4,v2.4}, @miscLink{announce-v2.2,v2.2}, @miscLink{announce-v2.0,v2.0}, @miscLink{ANNOUNCE-1.2,v1.2}, @miscLink{ANNOUNCE-1.0,v1.0}, @miscLink{ANNOUNCE-0.1,v0.1} Descriptive list of changes by version: @uref{http://lilypond.org/doc/v2.16/Documentation/changes/index.html,v2.16}, @uref{http://lilypond.org/doc/v2.14/Documentation/changes/index.html,v2.14}, @uref{http://lilypond.org/doc/v2.12/Documentation/topdocs/NEWS,v2.12}, @uref{http://lilypond.org/doc/v2.10/Documentation/topdocs/NEWS,v2.10}, @uref{http://lilypond.org/doc/v2.8/Documentation/topdocs/NEWS,v2.8}, @uref{http://lilypond.org/doc/v2.6/Documentation/topdocs/NEWS,v2.6}, @uref{http://lilypond.org/doc/v2.4/Documentation/topdocs/out-www/NEWS,v2.4}, @uref{http://lilypond.org/doc/v2.2/Documentation/topdocs/out-www/NEWS,v2.2}, @uref{http://lilypond.org/doc/v2.0/Documentation/topdocs/out-www/NEWS,v2.0}, @uref{http://lilypond.org/doc/v1.8/Documentation/topdocs/out-www/NEWS,v1.8}, @uref{http://lilypond.org/doc/v1.6/Documentation/out-www/NEWS,v1.6}, @miscLink{NEWS-1.4,v1.4}, @miscLink{NEWS-1.2,v1.2} @divEnd @divClass{column-center-middle-color3} @subheading Thanks Thanks to developers, contributors, bug hunters and suggestions for @miscLink{THANKS-2.16,v2.16}, @miscLink{THANKS-2.14,v2.14}, @miscLink{THANKS-2.12,v2.12}, @miscLink{THANKS-2.10,v2.10}, @miscLink{THANKS-2.8,v2.8}, @miscLink{THANKS-2.6,v2.6}, @miscLink{THANKS-2.4,v2.4}, @miscLink{THANKS-2.2,v2.2}, @miscLink{THANKS-2.0,v2.0}, @miscLink{THANKS-1.8,v1.8} @divEnd @divClass{column-center-middle-color3} @subheading Changelogs Developers' changelogs by version: @miscLink{ChangeLog-2.10,v2.10}, @miscLink{ChangeLog-2.3,v2.3}, @miscLink{ChangeLog-2.1,v2.1}, @miscLink{ChangeLog-1.5,v1.5 (1)}, @miscLink{CHANGES-1.5,v1.5 (2)}, @miscLink{CHANGES-1.4,v1.4}, @miscLink{CHANGES-1.3,v1.3}, @miscLink{CHANGES-1.2,v1.2}, @miscLink{CHANGES-1.1,v1.1}, @miscLink{CHANGES-1.0,v1.0}, @miscLink{CHANGES-0.1,v0.1}, @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