-
Notifications
You must be signed in to change notification settings - Fork 152
Google Summer of Code
Frescobaldi has applied as a mentoring organization for Google Summer of Code 2019 (GSoC), but unfortunately we have not been selected. Nevertheless, LilyPond is allowed to participate as part of the GNU Project, and some of the project ideas below might also be eligible to be realized as LilyPond projects. For other project suggestions please visit LilyPond's GSoC page.
As a student this is a chance for you to work for three months on a specific task within Frescobaldi, with one dedicated mentor assigned to you and of course the user and developer community of both Frescobaldi and LilyPond ready to assist you.
See the section Student Guidelines below for specific details about our expectations from students.
Below is a list of project ideas that could be done as a GSoC project, but you are free to suggest other development as well. The projects are not laid out in detail to leave room for individual suggestions and discussion. Some more ideas may be found in the TODO file within the code itself and the Issue Tracker where especially the Wish label may be relevant. The Beginner label may be used to find some “warm-up” tasks to familiarize oneself with the code even before actually submitting an application.
Frescobaldi and its underlying python-ly library are written in Python 3, the GUI application being built on PyQt5. So these two tools are the basic requirement for any project. More specific requirements are listed with each project. Note that Frescobaldi can also pre-process the to-be-compiled LilyPond files by modifying them or injecting LilyPond or Scheme functionality, so this is an option too.
Recently an Extension API has been added to Frescobaldi (merged to master but not in a release yet) that provides a convenient and robust interface to add functionality to Frescobaldi that may be very useful but not completely suitable to be merged into the core application. Possible use cases include repertoire-specific edition tools, project management/statistics. More information about the structure of Frescobaldi extensions can be found in the heavily commented sample extensions at https://github.com/frescobaldi-extensions/
Creating one comprehensive extension could be a viable approach to a GSoC project, with the following suggestions being strictly just that: suggestions:
- Document statistics and an accounting system for billing-by-token
- Managing openLilyLib installation and packages
Although LilyPond is a text based tool and Frescobaldi is and will remain a text editor at its core interacting with the score via a pointing device such as a mouse can be very convenient. While it is very practical to write LilyPond music, fixing things while proof-reading will become significantly easier with mouse access.
There is substantial potential in Frescobaldi to be exploited through its existing point-and-click functionality. When clicking on a score element Fresocbaldi “knows” its cause in the input file and can position the cursor beside it. From there it is pretty straightforward to have the program actually edit the element.
The scope of this project is not to implement graphical tweaking, i.e. fine-tuning the elements' positioning or shape, as this does not work with the regular PDF based music viewer and is more complex anyway. What we think of are functions like adding/removing elements (e.g. dynamics, articulations, text elements) or flipping directions and choosing styles (e.g. making a slur dashed). A general feature could be the integration of all the features of the Quick Insert Tool into the Music View's context menu. A slightly more challenging but very useful task is to insert or re-attach spanners such as dynamics hairpins or slurs.
Other Details:
- Difficulty: medium/average
-
Requirements:
- Understanding PyQt's menu and signal/slot infrastructure
- Understanding point-and-click
- Learning how Frescobaldi's document model interacts with the input files
- Mentors: Peter Bjuhr, Urs Liska
A relatively new feature in Frescobaldi is the Manuscript Viewer which allows to see the model from which the music is copied side by side with the engraved score. While already very useful for integrating workflows the tool can be massively extended, some of the desired features being:
- Maintain alternative manuscripts for the same score (e.g. manuscript and printed edition)
- Marking up the manuscripts to locate specific measures. This will allow
- synchronising the manuscript view with the input file and the view of the engraved score
- displaying variants for a given measure/region
- maintaining engravings that match the line/page breaking of the different manuscripts. Engraving can be done in the background, so switching the displayed manuscript immediately switches to the corresponding score view the background
Manuscript( set)s will be encoded in MEI, and a graphical tool has to be created to write that encoding. On the other side of things LilyPond has to be talked into providing the data about the layout of the resulting score.
Other Details:
- Difficulty: medium/hard
-
Requirements:
- Creating graphical tools to mark up an image
- Understanding point-and-click
- Scheme knowledge to make LilyPond know about the positions of the measures in the resulting score
- Mentor: Urs Liska
There is experimental support for exporting scores to MusicXML. So far there is limited coverage that should be extended, and the export should become more robust with regard to unconventionally organized input files. Several strategies can be thought of in that regard.
In 2017 significant progress in coverage has been made by our GSoC student Felippe Roza, but there is still much to be done that could make a nice GSoC project.
Other Details:
- Difficulty: easy to hard (depending on the targeted improvements)
-
Requirements:
- MusicXML
- Mentor: Peter Bjuhr
One of the issues with working with LilyPond is the compilation time. One way to improve this is partial compilation and handle scores system by system instead of page by page. This project is very ambitious because it involves work on Frescobaldi, Frescobaldi's interaction with LilyPond, LilyPond user space programming, and maybe modifying LilyPond itself. But parts of the LilyPond-related work can also be deferred to the LilyPond community.
The idea behind this project is the implementation of a music viewer that doesn't display pages but sees a scores as a continuous sequence of systems that are stitched together. LilyPond can produce such a sequence of files, and it can be made aware of the moments of each line break. That way only systems have to be recompiled that are affected by a modification, thus saving significant waiting times. Optionally there could be new engraving modes in LilyPond that don't try to optimize the line breaking, saving even more time, at least while in content editing mode.
The project is fairly complex and has many more aspects than could be listed on this page. So if you are interested in this please get in touch with us as early as possible to evaluate options and discuss the topics before you write an application.
Other Details:
- Difficulty: hard
-
Requirements:
- LilyPond/Scheme
- possibly C++ if it's necessary to modify LilyPond itself
- Mentors: NN (, Urs Liska)
- Community Mentor: Kieren MacMillan
Frescobaldi builds an internal tree structure representing the document and uses this for many editing operations. We have several wishes how this can be significantly improved.
- The tree structure should be able to als write a LilyPond document from scratch.
This will make it possible to implement ways to generate LilyPond music. - Small changes to the document, i.e. to individual notes, should trigger an update to the document, without having to build the whole tree again.
- Make building that tree structure (and other expensive operations, e.g.
for syntax highlighting and autocompletion) take place in a background thread.
Other Details:
- Difficulty: hard
-
Requirements:
- Understanding of trees
- XML and related concepts
- Mentor(s): NN, (Wilbert Berendsen)
- finish syntax highlighting/parsing html, latex, docbook and build proper lilypond-book support
- design a PDF format showing the music and including the source files so that that could become the preferred format for exchanging music, handling files originating from a library intelligently (I.e. depend on it, or include it). File extension would be .PDF of course, but Frescobaldi could open it, and automatically extract all files in a sentible place. Saving the document would run LilyPond in publish mode and store everything (maybe even the point and click areas!) in the PDF file.
- move snippets over from current QSettings storage to a location on
disk, make it possible to have a web resource for snippets that can
be used by Frescobaldi automatically from a remote resource, e.g. a
githup repository, where users can add snippets (requires thinking
about a structure that promotes quality but also predictability).
Question: this seems to be too small for a GSoC project - Improve MIDI/Sound Support. Although audio playback is not part of
LilyPond's original design and use case it can be an important part
of a toolchain. We have a lot of enhancements to playback support in
mind for Frescobaldi. These include
- making sure that sound can be played out-of-the-box. Select the best MIDI player available (TiMidity or FluidSynth) and run it with the arguments to use the best sound server available.
- Research ways to improve sound quality. If Frescobaldi cannot make some adjustments automatically (e.g. root permissions are needed, TiMidity needs to be recompiled), document those limitations.
- Provide a user interface to allow choosing between the automatic and the manual MIDI settings.
- Provide a user interface for managing MIDI players and soundfonts/libraries
- Improve
articulate.ly, the LilyPond package that improves the performance aspects of MIDI output.
If you are interested in participating in GSoC working on a Frescobaldi project you have to submit a good application through the GSoC web interface. But it is strongly recommended to get in touch with us beforehand. We are ready to help you with any questions you may have, but it is part of the program that you do the heavy lifting in that stage yourself.
First of all you need a working knowledge of the Frescobaldi program, so you have to install it first,
preferrably from the Git directory. Please follow the direction on the corresponding Wiki page. (An additional source of information may be http://www.frescobaldi.org/download.
TODO: Question: Can development be done (i.e. installed from Git) on Mac as well? I think so, but I'm not
sure if that needs special indications.
From this working knowledge and the project ideas above you should make up your mind about what functionality you're interested to work on. Approaching us with messages indicating a general interest in GSoC participation without any signs of specific interest are not too helpful for us.
For a first investigation in how the code is organized you should investigate the README-development file, which gives quite a lot of information and should get you started, at least to the point where you can ask specific questions.
With that in mind you should then write a message to the mailing list or email address stated at the top of this page. As said, you are expected to do most of the work independently, even at this stage, but we're always there to assist you.
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 strictly 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 he or she isn’t paid for this activity like you are, you are still entitled to get regular attention from them.
In order to get support from your mentor you have to give them 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 reading it without the opportunity to apply it in a real example.