Google Summer of Code
¿Qué es el Google Summer of Code (Verano del Código de Google)?
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 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 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.
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 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 aquí.
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.
Dificultad: Fácil/intermedia
Requisitos: Scheme (Guile), pero el nivel necesario puede aprenderse fácilmente
Conocimientos recomendados: Teoría y nomenclatura de los acordes
Mentor: Carl Sorensen
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: 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.
Dificultad: Baja/media
Requisitos: C++ y disposición para familiarizarse con el funcionamiento interno de LilyPond.
Conocimientos recomendados: Interés y experiencia en el trabajo con archivos de fuentes tipográficas. Un poco de METAFONT.
Mentores: Werner Lemberg, Abraham Lee
Añadir una variante especial de los glifos de fuente tipográfica
- Añadir variantes ‘sobre’ y ‘entre’ líneas del pentagrama.
- 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.
Dificultad: fácil
Requisitos: MetaFont, C++, buen ojo para los detalles
Conocimientos recomendados: conocimientos básicos de LilyPond
Mentor potencial: Werner Lemberg
Notación contemporánea
LilyPond es muy bueno creando notación no estándar. Tener que codificar cada uno de los elementos gráficos en lugar de simplemente 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 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) 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.
Dificultad: media
Requisitos: Scheme (interacción con las interioridades de LilyPond), técnicas de notación contemporánea
Conocimientos recomendados: habilidad para la elaboración de marcos de funcionamiento jerárquicos
Mentores: NN, Urs Liska
Reescritura de la extensión de LilyPond para LibreOffice con Python
La extensión 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 Frescobaldi, tales como el resaltado de sintaxis, facilidades durante la escritura, asistentes de partitura o transformaciones musicales.
Dificultad: baja/media
Requisitos: Python, PyQt, conceptos básicos de LilyPond y de extensiones de LibreOffice
Conocimientos recomendados: Familiaridad con la base de código de Frescobaldi o disposición para aprenderla durante el período fijado
Mentor(es): Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
Pruebas y documentación automatizadas para openLilyLib
openLilyLib es un marco para extensiones de código de LilyPond que ofrece un repositorio de fragmentos de código o “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.
Para que sea utilizable por un más amplio abanico de usuarios de
LilyPond al nivel del “consumidor”, openLilyLib requiere una
adecuada documentación. Esta documentación se debe generar a
partir de las fuentes, por lo que se necesita un sistema que
demande de los autores de los paquetes que documenten los archivos
de entrada y que provean ejemplos de uso adicionales, desde los
cuales se genera la documentación. Idealmente, pero no
obligatoriamente, estaría implementado como un hook de Git, es
decir, que funcione automáticamente al producirse cada una de las
actualizaciones realizadas sobre el repositorio. No prescribimos
ninguna de las herramientas o enfoques que se deben usar, pero el
lenguaje de más amplio uso en el dominio de LilyPond es Python,
por lo que habría cierta inclinación hacia esa opción. Como
alternativa, estaría bien una solución en Scheme, de forma que la
generación de documentación fuese, en efecto, disparada por la
compilación de un determinado archivo de entrada de LilyPond. En
general se recomienda hacer uso de conceptos y herramientas de
otros lenguajes de eficacia probada.
La salida final de la documentación debería ser una página HTML estática que se pueda ver localmente y/o subida a un sitio web. Pero sería beneficioso que la herramienta generase primero una representación intermedia (p.ej. un archivo JSON con archivos de medios adicionales) a partir de la cual una aplicación de página única pudiese recuperar el contenido para su presentación en la página web de openLilyLib. El desarrollo de esta Aplicación de Página Única puede formar parte del proyecto GSoC, pero es opcional.
Dificultad: media
Requisitos: Python o Scheme, generadores de web estáticos o tecnologías de aplicaciones web dinámicas (basadas en Node.js). Integración continua (se puede aprender mientras dura el período de vinculación)
Mentores: Urs Liska, Matteo Ceccarello
MusicXML
Mejora de las funciones de importación y exportación de MusicXML:
File interchange between LilyPond and other applications using
MusicXML is still a difficult matter. To import MusicXML it has
to be converted manually by the musicxml2ly script. Export
to MusicXML is only available as a rudimentary feature
inside Frescobaldi. In order to provide natural interchange
between LilyPond and MusicXML based applications there’s the need
of actual import functionality and a dedicated export backend.
Importing XML shall provide file, line and column to add origin attributes to generated objects. That way point and click can be made available in Frescobaldi or other supported IDEs.
Exporting XML shall be realized with an exporter class like the MIDI export. This may be based on the work already done in GSoC 2015 by David Garfinkle. It should be checked if it is possible to use another XML library than the one provided by guile-2 in order to have this feature available in current LilyPond (which is based on guile-1.8).
Dificultad: media
Requisitos: MusicXML, Python, Scheme, basic LilyPond knowledge
Conocimientos recomendados: Familiarity with other scorewriters (for cross-testing)
Mentor: Jan-Peter Voigt
Información para los solicitantes o participantes
In order to have a satisfying experience with GSoC applicants are strongly advised to thoroughly read the following recommendations. Some of these are relevant for the application process, others for the time within the project.
- Read all applicable information on the program’s website, particularly the students’ manual. Make sure you fulfil all of Google’s prerequisites and are willing to join the program as a full-time commitment over the coding period of three months.
- Please get in touch with us as soon as possible if you are interested in applying with a project. Mentor availability may change without notice, project proposals may need fine-tuning, and many other reasons might require us to reject or ignore an application that hasn’t been discussed before.
- We do not know in advance how many “slots” we will have available for projects, so please be aware that you may find yourself in competition with other applicants or not. Interested or even enthusiastic response from our mentors is no guarantee of eventually being accepted, and not being accepted does not necessarily indicate a negative evaluation of your application. If we have to decide between different applicants there may be various aspects to consider.
- Integration in the LilyPond community is a fundamental part of GSoC, and we expect our students to make substantial efforts to become community members. Within the bonding period we expect you to write a blog post about your project (either on Scores of Beauty or on any other blog) and to be active on our mailing lists, introducing yourself but also communicating about unrelated tasks. This goes beyond the mere setting up of a working environment and familiarizing yourself with the relevant code, but we think it is crucial for the GSoC project to be mutually satisfying.
- If you are accepted to the program you will have one mentor explicitly assigned to your project. With this mentor you will have to agree upon a communication strategy, be it emails, chatrooms, issue trackers or voice/video chats. Regular communication is absolutely crucial for the success of a GSoC project so you are stricly required to keep talking to your mentor. But keep in mind that your mentor has explicitly taken over the responsibility for your project, and while unlike you he isn’t paid for this activity you are still entitled to get regular attention from him.
- In order to get support from your mentor you have to give him a chance to follow your progress and efforts. Therefore it is important to regularly commit your changes to the versioning repository you are working on. Don’t hesitate making unfinished code available because you are afraid of criticism, and don’t suppress questions because you think they might be considered stupid. But ideally your code should at any time be accompanied by compatible testing code. Your mentor may not be able to properly assess your code by only reading it without the opportunity to apply it in a real example.
Existe una lista de proyectos inactivos en el Desván. Mantenemos en la lista los proyectos que aún se consideran valiosos, pero para los cuales no existe en la actualidad ningún mentor disponible.
Otros idiomas: English, deutsch, français, italiano, 日本語, nederlands.
Acerca de la selección automática del idioma.