-@divClass{column-center-top}
-@subheading ¿Qué es el Google Summer of Code (Verano del Código de Google)?
-
-@uref{https://summerofcode.withgoogle.com/, GSoC} es un programa
-global que ofrece a estudiantes una ayuda para que trabajen en
-proyectos de software de fuentes abiertas durante las vacaciones
-de verano. Durante tres meses, los estudiantes trabajan para
-completar una tarea dada como parte de la comunidad del proyecto y
-bajo la guía de mentores con experiencia. El programa es una
-excelente oportunidad para que los estudiantes obtengan
-experiencia en el desarrollo de software en el mundo real y hagan
-contribuciones que beneficie a todos. Atrae a colaboradores
-nuevos y anima a los estudiantes que ya participan en el
-desarrollo de LilyPond a que se impliquen aún más. LilyPond
-participa en el GSoC como parte del @uref{http://www.gnu.org/,
-proyecto GNU}.
-
-Hemos tenido participantes en el GSoC en 2012, 2015 y 2016 y
-animamos a los estudiantes a que envíen la solicitud para el
-programa de 2017.
-
-Si está interesado en presentarse al programa con LilyPond como
-proyecto, le rogamos que lea la información que aparece más abajo
-y que no dude en escribirnos a la lista de desarrolladores (véase
-@ref{Contacto}). El plazo de solicitud para estudiantes es desde
-el 20 de marzo hasta el 3 de abril de 2017, pero le recomendamos
-encarecidamente que se ponga en contacto con nuestra comunidad con
-antelación.
-
-@divEnd
-
-@divClass{column-center-middle-color2 bigger-subsubheadings}
-@subheading Lista de ideas del proyecto
-
-Más abajo aparece una lista de ideas para el proyecto GSoC (última
-actualización: enero de 2017), pero si tiene otras ideas para un
-proyecto que pueda completar en el plazo de tres meses del
-programa, se le invita a formular la sugerencia sobre nuestra
-lista de correo de desarrolladores (véase @ref{Contacto}).
-Existen varias áreas en las que LilyPond se puede mejorar, y
-nuestro equipo de desarrollo siempre está dispuesto a ayudar a los
-que desean enfrentarse a un proyecto similar a los que aparecen
-relacionados más abajo. Ya que la disponibilidad de los mentores
-varía de proyecto en proyecto y de un año a otro, lo más sensato
-es ponerse en contacto con nosotros lo antes posible.
-
-Hay una lista completa de todas las incidencias abiertas
-@uref{http://sourceforge.net/p/testlilyissues/issues/, aquí}.
-
-
-@subsubheading Mejora de la estructura interna de acordes
-
-La representación interna de los acordes de LilyPond no es lo
-bastante potente como para captar la nomenclatura de los acordes
-de jazz. Actualmente el acorde tiene una fundamental, un bajo y
-una inversión. Sería bueno poder manejar acordes múltiples o
-superpuestos, menor/mayor, etc. Para hacerlo, debe desarrollarse
-una representación interna con la capacidad de capturar la esencia
-de los acordes más complejos. Además, una vez que se haya
-desarrollado la representación interna, el formato de salida de
-los nombres de acorde puede mejorarse.
-
-@emph{Dificultad:} Fácil/intermedia
-
-@emph{Requisitos:} Scheme (Guile), pero el nivel necesario puede
-aprenderse fácilmente
-
-@emph{Conocimientos recomendados:} Teoría y nomenclatura de los acordes
-
-@emph{Mentor:} Carl Sorensen
-
-
-@subsubheading Adoptar el estándar SMuFL de codificación de tipografías
-
-Desde hace varios años circula un nuevo estándar para las fuentes
-tipográficas de música: @uref{http://www.smufl.org/, SMuFL}, que
-también se estudia como parte de un futuro estándar del W3C para
-la codificación de música. Como herramienta FLOSS, LilyPond
-debiera unirse a este estándar en lugar de usar una solución
-aislada como hace actualmente. La adopción de SMuFL ayudaría a
-integrar LilyPond con el mundo del software de notación musical y
-al final daría a los usuarios de LilyPond acceso a una más amplia
-selección de fuentes tipográficas de notación.
-
-Hacer que LilyPond cumpla el estándar SMuFL consiste en la
-reasignación de los glifos que se construyen a partir de código
-fuente de METAFONT, el ajuste de las métricas de los glifos a las
-especificaciones de SMuFL, y finalmente la actualización de la
-forma en que LilyPond localiza y posiciona los glifos. Como parte
-opcional de este proyecto, podría modificarse el mecanismo de
-carga de las fuentes por parte de LilyPond para que usara las
-fuentes de notación instaladas como fuentes del sistema en lugar
-de hacerlo dentro de la instalación de LilyPond.
-
-@emph{Dificultad:} Baja/media
-
-@emph{Requisitos:} C++ y disposición para familiarizarse con el funcionamiento interno de LilyPond.
-
-@emph{Conocimientos recomendados:} Interés y experiencia en el trabajo con archivos de fuentes tipográficas. Un poco de METAFONT.
-
-@emph{Mentores:} Werner Lemberg, Abraham Lee
-
-
-@subsubheading Añadir una variante especial de los glifos de fuente tipográfica
-
-@divClass{keep-bullets}
-@itemize
-
-@item
-Añadir variantes @q{sobre} y @q{entre} líneas del pentagrama.
-
-@item
-Variantes más bajas y estrechas de ciertos glifos, como
-alteraciones alccidentales. Otro ejemplo más específico sería una
-cabeza de nota breve de la notación antigua en dos variantes, una
-con un hueco pequeño dentro, y otra con un hueco grande.
-
-@end itemize
-@divEnd
-
-@emph{Dificultad:} fácil
-
-@emph{Requisitos:} MetaFont, C++, buen ojo para los detalles
-
-@emph{Conocimientos recomendados:} conocimientos básicos de LilyPond
-
-@emph{Mentor potencial:} Werner Lemberg
-
-
-@subsubheading Notación contemporánea
-
-LilyPond es muy bueno creando notación no estándar. Tener que
-@emph{codificar} cada uno de los elementos gráficos en lugar de
-simplemente @emph{dibujarlo} puede parecer engorroso pero de hecho
-es una gran virtud. Se pueden implementar funcionalidades
-notacionales nuevas con apariencia consistente, disposición
-automática y una interfaz sintáctica natural.
-
-Dentro del sistema de biblioteca
-@uref{https://github.com/openlilylib/oll-core, openLilyLib} el
-alumno creará una infraestructura fundamental y unos bloques
-constructivos para hacer más fácil la creación de notación
-contemporánea. Además (al menos) @emph{un} paquete en concreto se
-desarrollará para cubrir alguna notación contemporánea específica,
-como por ejemplo el estilo de algún compositor dado, técnicas de
-ejecución extendidas para un instrumento específico o una cierta
-categoría de efectos.
-
-@emph{Dificultad:} media
-
-@emph{Requisitos:} Scheme (interacción con las interioridades de LilyPond),
-técnicas de notación contemporánea
-
-@emph{Conocimientos recomendados:} habilidad para la elaboración de marcos de funcionamiento jerárquicos
-
-@emph{Mentores:} @strong{NN,} Urs Liska
-
-
-@subsubheading Reescritura de la extensión de LilyPond para LibreOffice con Python
-
-La extensión @uref{http://ooolilypond.sourceforge.net/,
-OOoLilyPond} hace posible incluir de forma muy práctica fragmentos
-de partitura de LilyPond dentro de documentos de
-OpenOffice.org/LibreOffice Writer, Draw e Impress, manteniendo al
-mismo tiempo la fuente y la imagen juntas. Después de muchos años
-sin desarrollo, se ha iniciado una tarea de hacer de nuevo que la
-extensión sea compatible con las versiones actuales de LibreOffice
-y de LilyPond.
-
-Sin embargo, según el ecosistema de LibreOffice ha cambiado
-significativamente, ahora es posible reescribir la extensión con
-Python y PyQt. Esto no solo será más potente en general, sino que
-permitirá la integración de funcionalidades de
-@uref{http://frescobaldi.org, Frescobaldi}, tales como el
-resaltado de sintaxis, facilidades durante la escritura,
-asistentes de partitura o transformaciones musicales.
-
-@emph{Dificultad:} baja/media
-
-@emph{Requisitos:} Python, PyQt, conceptos básicos de LilyPond y
-de extensiones de LibreOffice
-
-@emph{Conocimientos recomendados:} Familiaridad con la base de
-código de Frescobaldi o disposición para aprenderla durante el
-período fijado
-
-@emph{Mentor(es):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
-
-
-@subsubheading Pruebas y documentación automatizadas para openLilyLib
-
-@uref{https://github.com/openlilylib, openLilyLib} es un marco
-para extensiones de código de LilyPond que ofrece un repositorio
-de fragmentos de código o @qq{snipets} y una colección de paquetes
-integrados, tales como herramientas para la disposición de páginas
-o las anotaciones académicas. Es muy potente y prometedora, pero
-para que despegue realmente hacen falta dos funcionalidades:
-pruebas automatizadas y generación de la documentación.
-
-Las pruebas automatizadas son necesarias para asegurarse de que
-las modificaciones en una funcionalidad no quiebran el
-funcionamiento de otras partes de la biblioteca. Ya existe una
-cierta cantidad de pruebas automatizadas del repositorio de
-fragmentos de código, con el servidor Travis de Github, pero es
-necesario reconsiderarlo y extenderlo para que cubra también los
-paquetes sueltos.