[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Google Summer of Code - Ideas List, please discuss
From: |
address@hidden |
Subject: |
Re: Google Summer of Code - Ideas List, please discuss |
Date: |
Sun, 12 Feb 2012 12:51:57 +0100 |
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
- Google Summer of Code - Ideas List, please discuss, Janek Warchoł, 2012/02/12
- Re: Google Summer of Code - Ideas List, please discuss,
address@hidden <=
- Re: Google Summer of Code - Ideas List, please discuss, Janek Warchoł, 2012/02/12
- Re: Google Summer of Code - Ideas List, please discuss, Reinhold Kainhofer, 2012/02/15
- Re: Google Summer of Code - Ideas List, please discuss, pls, 2012/02/16
- Re: Google Summer of Code - Ideas List, please discuss, Janek Warchoł, 2012/02/21
- Re: Google Summer of Code - Ideas List, please discuss, pls, 2012/02/21
- Re: Google Summer of Code - Ideas List, please discuss, Janek Warchoł, 2012/02/21
Re: Google Summer of Code - Ideas List, please discuss, Graham Percival, 2012/02/12