All of these look good. On Feb 12, 2012, at 12:03 PM, Janek Warchoł wrote:
> General student prerequisites: (basic?) git knowledge > > 1) Fixing problems with synchronization of grace notes, together with > all underlying architecture (issue 34). Requirements: C++, MIDI; > familiarity with basic music notation recommended > I have no clue how broken this is as the last time I used a grace note in a MIDI was 1998, but it seems like it's a reasonable thing to fix. > 2) Adding comprehensive MusicXML import and export features, together > with test suites for it. Requirements: ? (no idea in which language > this would be written), MusicXML, basic LilyPond and music notation > knowledge; familiarity with other scorewriters would be a nice bonus > (for cross-testing). The goal would be considered achieved when a > (previously chosen) not-so-complicated score could be imported from > MusicXML and exported back with no (unintentional) loss of data. > I worked on this a little bit - it is totally possible and would likely weigh in @ 500-1000 lines of Scheme. I'd recommend not worrying about placement data and stopping at the engraver level. This is more or less the same thing as a MIDI plus stuff like articulations, slurs, etc.. Placement data would be doable but hard: it'd be better to just get the info from engravers first. > 3) Horizontal Spacing of Objects Attached to Notes, esp. Accidentals: > make spacing depend on tightness of the music. This is thoroughly > explained in issues 2141, 2142, 2143 ans 2144. Also, the > infrastructure needed to solve 2142 should be generic and extensible, > so as to cover other types of grobs like dots, arpeggios etc (see > comment 8 on issue 2142 - > http://code.google.com/p/lilypond/issues/detail?id=2142#c8). > Requirements: This is a cool idea but wouldn't be a lot of work - in C++ it'd require 20-50ish lines of code. > 4) Currently some glyphs come in two varieties: for use on staff lines > and between them (an example of noteheads with varying hole size is > here > http://lilypond.googlecode.com/issues/attachment?aid=18390010000&name=hole+sizes+and+stem+thicknesses.png&token=hQOK78AGtkqG3PmB5YSWI0g1I68%3A1329042576520&inline=1). > It would be nice to add such variants to other glyphs, for example > accidentals and flags, together with a generic infrasctucture to > support them. Also, narrower and shorter variants of some glyphs > would be handy, see > http://code.google.com/p/lilypond/issues/detail?id=2145 and > http://code.google.com/p/lilypond/issues/detail?id=2203. Requirements: > MetaFont, C++(?), good eye for details; basic LilyPond knowledge > recommended(?). This could be combined with the above to be a full project. > > 5) Build System Improvement: if we want to ever move away from make, > this would be a good opportunity. Issues like thousands of errors and > warnings during compilation should be removed, all dependancies fixed > (so that one doesn't need to remove fonts folder to have fonts > rebuilt). Requirements: Python, Make and (optionally) another build > system. > No clue how this stuff works, but sounds like a good idea. > 6) Grand Slur&Tie Project - quite often LilyPond produces bad-looking > slurs and ties, ties on enharmonic notes are not supported { cis'~ > des' }, ties "broken" by clef or staff change aren't supprted well, > etc. (as for bad shapes, i have a big report on ties halfway done, and > slur examples would need to be collected from mutopia or from users). > Requirements: C++, experience with writing heuristics; basic Scheme, > music notation and LilyPond knowledge recommended. This project seems > really big to me, unless all of the research and testing would be done > by someone else (bad idea). This would take the entire summer if you added intelligent non-convex slurs. Here I could most certainly help out - it was on my summer-of-lily list but I'd gladly delegate to someone else! > > 7) Grand Beam Project - there are cases of badly-looking beaming, even > in very simple snippets (again, i have a huge report on this matter > halfway-done). Also, beaming should depend on context and neighbor > notes (see http://icking-music-archive.org/lists/sottisier/sottieng.pdf > section 2.2, i can also give some more examples). Changing beam code > to do this looks like a fairly complicated matter. Requirements: C++, > experience with writing heuristics; basic music notation knowledge > recommended. > Most beam problems that don't involve cross-staff or broken beams are fixable with 1-20 lines of code. If you send me concrete examples, I can likely estimate how long it'd take. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
