+@node GSoC 2012
+@unnumberedsec GSoC (Google Summer of Code) 2012
+@translationof GSoC 2012
+
+@divClass{column-center-top}
+@subheading Was ist Google Summer of Code?
+
+Google Summer of Code ist ein globales Programm,
+das Studenten Stipendien offeriert, um an Open-Source-Projekten während
+der Sommerferien zu arbeiten.
+
+Das LilyPond-Team hat beschlossen, dass sich hier eine ausgezeichnete Möglichkeit
+bietet neue Mitarbeiter zu finden und Studenten, die sich schon an LilyPond beteiligen, weiter einzubinden. Einer unserer Mitarbeiter wurde für den
+Sommer 2012 als Teil des @uref{http://www.gnu.org/, GNU-Projekts} angenommen;
+wir hoffen, dass wir auch in kommenden Jahren an dem Programm teilnehmen können.
+
+@divEnd
+
+@divClass{column-center-bottom}
+@subheading Unsere Ideenliste 2012
+
+Unten befindet sich eine Liste mit empfohlenen Projekten für GSoC-Stundenten für
+den Sommer 2012. Wenn auch die Anmeldefrist vorbei ist, lassen wir die Informationen
+trotzdem online, weil sie als Anregung für alle LilyPond-Entwickler dienen
+können. Einige Mitglieder des Entwicklungsteams helfen gerne Freiwilligen,
+die sich an diese Projekte wagen wollen.
+
+Es gibt natürlich viel mehr, was an LilyPond verbessert werden kann, darunter
+auch sehr kleine Projekte. Eine vollständige Liste aller bekannten Probleme
+findet sich @uref{http://code.google.com/p/lilypond/issues/list, hier}.
+
+@subheading Stichnoten
+
+Lösen Sie Probleme mit der Synchronisation von Verzierungen (Vorschläge usw.),
+zusammen mit der darunter liegenden Architektur (siehe
+@uref{http://code.google.com/p/lilypond/issues/detail?id=34,
+Nummer 34 in unserem Tracker}). Verzierungen bringen das Zeitmaß von LilyPond
+durcheinander, weil sie sozusagen in der Zeit rückwärts gehen. Dadurch
+entstehen seltsame Effekte, besonders wenn in einem Notensystem eine
+Verzierung auftritt und im zweiten nicht.
+
+@strong{Schwierigkeit:} mittel
+
+@strong{Erfordernisse:} C++, MIDI
+
+@strong{Empfohlen:} Bekannt mit den Interna von LilyPond
+
+@strong{Mentoren:} Mike Solomon, Carl Sorensen
+
+@subheading MusicXML
+
+Hinzufügen von erweiterter Unterstützung für den Export von MusicXML und
+Verbesserung des Imports, zusätzlich Tests, die die Funktionen überprüfen.
+Abhängig von der zur Verfügung stehenden Zeit kann etwas oder alles der
+folgenden Punkte implementiert werden:
+
+@divClass{keep-bullets}
+@itemize
+
+@item
+Der Export soll grundlegende Funktionen wie den MIDI-Export können (d. h.
+die Benutzung von eigenen Exportklassen, abgeleitet von der Übersetzerklasse.)
+
+@item
+Der XML-Baum soll aus dem grundlegenden musikalischen Inhalt erstellt werden,
+hinzu kommt eine Verbindung von musikalischem Ereignis zu XML-Tag.
+
+@item
+Alle LilyPond-Engraver sollen ihre Arbeit verrichten.
+
+@item
+Alle Ausgabe-Objekte (also alle Stencils/Gruppen von Stencils) sollen der
+Musik zugeordnet werden (und damit auch dem XML-Tag im XML-Baum).
+
+@item
+Ein XML-Ausgabebackend soll hinzugefügt werden, welches die Layoutinformationen
+für jedes Ausgabe-Objekt den XML-Tags hinzufügen kann.
+
+@end itemize
+@divEnd
+
+Das Ziel wird als erreicht angesehen, wenn eine (vorher festgelegte) Partitur
+von MusicXML importiert und dann wieder exportiert werden kann, ohne dass
+ungewollter Datenverlust eintritt.
+
+@strong{Schwierigkeit:} mittel
+
+@strong{Erfordernisse:} MusicXML, Python, grundlegene Kenntnis von LilyPond
+
+@strong{Mentoren:} Reinhold Kainhofer, Mike Solomon
+
+Kenntnis anderer Notensatzprogramme (zum Testen) wäre ein netter Bonus.
+
+@subheading Binde- und Legatobögen verbessern
+
+Die Standardform von Binde- und Legatobögen ist oft nicht zufriedenstellend.
+Überbindungen von enharmonischen Tönen (etwa @code{@{ cis'~ des' @}}) werden
+nicht unterstützt, auch Überbindungen, die von Schlüssel- oder Systemwechsel
+unterprochen werden, sind schlecht unterstützt. Das Projekt beinhaltet das
+Sammeln und Sortieren von Beispielen schlechter Ausgabe, das feststellen der
+richtigen Formatierung und das Schreiben das dazu notwendigen Codes.
+
+@strong{Schwierigkeit:} schwer
+
+@strong{Erfordernisse:} C++, Erfahrung mit Heuristiken
+
+@strong{Empfohlene Kenntnisse:} LilyPond-Kenntniss, Sinn für Ästhetik
+
+@strong{Mentor:} Mike Solomon
+
+@subheading Eine besondere Variante bestimmter Glyphen hinzufügen
+
+Zusätzliche Varianten von Glyphen schaffen für Situationen wie auf der Linie,
+zwischen den Linien, kürzere und schmalere Varianten für z. B. Versetzungszeichen,
+zusammen mit einer Infrastruktur, die das unterstützt. Ein Beispiel ist die
+Breve der Alten Notation, deren Notenkopf in zwei Varianten vorkommt, mit
+kleinerem und größerem Loch.
+
+@strong{Schwierigkeit:} leicht
+
+@strong{Erfordernisse:} MetaFont, C++, gutes Auge für Details
+
+@strong{Empfohlene Kenntnisse:} grundlegene LilyPond-Kenntnis
+
+@strong{Mentor:} Werner Lemberg
+
+@subheading Bebalkung verbessern
+
+Die Standardpositionen von normaler Bebalkung, Bebalkung über Systeme hinweg,
+unterbrochene und Knie-Bebaklung sollte verbessert werden. Balken sollten
+sich am Kontext und benachbarten Noten orientieren (siehe
+@uref{http://icking-music-archive.org/lists/sottisier/sottieng.pdf,
+Abschnitt 2.2}). Wenn möglich, sollte die Rechenzeit für die Bebalkung
+verkürzt werden.
+
+@strong{Schwierigkeit:} mittel
+
+@strong{Erfordernisse:} C++, Erfahrung mit Heuristiken
+
+@strong{Empfohlene Kenntnisse:} Sinn für Ästhetik
+
+@strong{Mentoren:} Mike Solomon, Carl Sorensen
+
+
+@subheading Kompilationswarnungen aufräumen
+
+Aufräumen von Kompilationswarnungen, statischer Codeanalyse und Valgrind-Warnungen.
+Werkzeuge zur automatischen Analyse von Code (Warnungen in @code{g++} und
+@code{clang}) und Analysewerkzeuge wie die Valgrind-memory-leak-detection und
+callgrind code profiler stellen wertvolle Informationen über mögliche Probleme
+im C++-Code zu Verfügung. Wenn man diese Warnungen aufräumt, könnte man auch
+automatisch alle Patche zurückweisen, die neue Warnungen mit sich bringen würden.
+
+@strong{Schwierigkeit:} mittel
+
+@strong{Erfordernisse:} C++
+
+@strong{Mentoren:} Joe Neeman, Reinhold Kainhofer
+
+@divEnd
+
+
projects / lilypond.git / blobdiff