Hi developers, this is pretty urgent, and I start a new thread for all those who may not have followed up on http://lists.gnu.org/archive/html/lilypond-devel/2016-01/msg00139.html.
We want to review our suggestions for Google Summer of Code projects. But it seems although the projects listed on here: http://lilypond.org/google-summer-of-code.html are all still valid and urgent, the majority of them is orphaned with regard to potential mentors. In order to be able to do an attractive *and* realistic presentation of possible projects (that we can actively promote then) we should find people who could volunteer mentoring any of these projects. I don't think we have to *remove* orphaned projects but at least we should move them down to the bottom of the page to a kind of "other ideas" list. So please go through this list and consider them carefully: 1) Fixing of grace notes I think this is one of the most embarrassing and longest-standing issues in LilyPond. Carl Sorensen is there as a secondary mentor, but we'd need a primary mentor. 2) MusicXML Import/export This project doesn't have *any* mentor ATM. In addition it is not really clear what could be the actual task of it as there is a multitude of possible fields to work on. There are several options, the following being a non-exhaustive list: - backporting the improvements in musicxml2ly-dev to the main musicxml2ly - working on MusicXML export through the python-ly appraoch - following up on last year's GSoC project exporting to MusicXML through LilyPond/Scheme itself 3) Improve Slurs and Ties I think this is one of the actual *engraving* parts that would warrant most attention, i.e. it is the part that usually requires the most (and pretty cumbersome) manual post-processing. There's no mentor available ATM. 4) Improve default beam positioning Carl Sorensen would be ready as secondary mentor, but we'd need a primary one 5) Help improving compilation behaviour This is not visible to the end-user but would nevertheless be a good investment on the long run. Joe Neeman could imagine being a "backup mentor" but we'd definitely need a primary mentor. ##### So these five out of six proposals would have to be "downgraded" if no mentor(s) volunteer for them. What is left is the 1) "Adding variants of font glyphs" project for which Werner Lemberg volunteers as mentor. 2) In addition there is a suggestion extending the ScholarLY library which I would mentor (see https://codereview.appspot.com/282290043/patch/1/10001 for a description). 3) And there is a suggestion about adding chord structures that Carl Sorensen would mentor (see the PS to http://lists.gnu.org/archive/html/lilypond-devel/2016-01/msg00197.html for a description). And finally I have one more suggestion for a project, but I wouldn't volunteer mentoring it as I don't even know where/how to tackle it. Consequently I can't really judge if it is suitable as a GSoC project, but my feeling is it could be considered: 4) Allow spanners to cross voices Currently all sorts of spanners (ties, slurs, dynamics, text spanners, trills etc.) have to be ended in the same 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. New ways of addressing this issue should be invented, for example by allowing a "target context" specifying where to look for endings or by explicitly defining IDs of the targeting grob (this is BTW an option how spanners can be encoded in MEI). This is not at all about engraving - which is already possible - so none of the complexities of actual engraving code are involved. This feature would solve a *lot* of problems that are commonly faced with piano music and presumable other polyphonic instruments. And it would make a *lot* of hacks obsolete that are now necessary when working with the part combiner. So I would be really happy to see progress here. Best Urs _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
