Re: Google Summer of Code - Ideas List, please discuss

[Janek Warchoł]

W dniu 12 lutego 2012 12:51 użytkownik address@hidden
<address@hidden> 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