W dniu 12 lutego 2012 12:51 użytkownik m...@apollinemike.com <m...@apollinemike.com> napisał: > >> 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.
Really? All these issues, and extending this to all sorts of grobs? Wow! >> 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. And i would be glad to take it. >> 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! Great! >> 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. I have 500+ examples that need to be sorted, described and (in some cases) decided how the proper beaming should look like... Wanna Catch'em All? :P And i meant to include cross-staff beams of course :) Thanks for review! Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel