Recensement de nos idées

Voici une liste de projets que nous avons proposés aux étudiants du GSoC et à quiconque aurait envie d’améliorer LilyPond.
Dernière mise à jour : juanvier 2017.

Si vous avez d’autres idées de projet réalisable sur une période de trois mois, n’hésitez pas à nous en faire part sur la liste des développeurs (voir Contact). Il y a bien d’autres choses à améliorer dans LilyPond et les membres de l’équipe de développement aideront volontiers ceux qui aimeraient s’atteler à de tesl projets. Dans la mesure où la disponibilité de tuteurs diffère selon les projets et les années, nous vous conseilllns de nous contacter au plus tôt.

Une liste exhaustive des problèmes est disponible ici.

Amélioration de la structure interne des accords

La structure interne des accords dans LilyPond n’est pas suffisamment puissante pour tenir compte de la nomenclature des accords de jazz. Pour l’instant, un accord comporte une fondamentale, une basse et un renversement. Il serait souhaitable d’arriver à gérer les amalgames ou polyaccords, qu’ils soient majeur ou mineur, etc. Seul le développement d’une représentation interne capable de capturer l’essence d’accords complexes permettra d’y parvenir. Cette représentation interne une fois développée permettra par ailleurs d’améliorer le rendu des accords nommés.

Difficulté : moyennement facile.
Préalables : Scheme (Guile), mais le niveau nécessaire peut s’acquérir aisément
Connaissances appréciées : Théorie des accords et de leur nommage
Mentor : Carl Sorensen.

Adoption du standard SMuFL d’encodage de fontes musicales

Depuis quelques années émerge un nouveau standard en matière de fontes musicales : SMuFL, qui fait aussi l’objet de discussions aux fins d’intégration dans un futur standard du W3C pour l’encodage de la musique. En tant que logiciel libre et open source, LilyPond se doit d’adhérer à un tel standard ouvert plutôt que de reposer sur une solution isolée comme à l’heure actuelle. L’adoption de SMuFL aidera à l’intégration de LilyPond dans le monde des logiciels de notation musicale et procurera par là même à ses utilisateurs accès à une sélection de fontes musicales plus étendue.

Rendre LilyPond compatible avec SMuFL inclut une refonte de la cartographie des glyphes construits à partir des sources METAFONT, un ajustement des métriques de glyphe aux spécifications de SMuFL et enfin l’adaptation de la manière dont LilyPond recherche et positionne les glyphes. En complément à ce projet, il pourrait être souhaitable de modifier les mécanismes de chargement des fontes dans LilyPond, de telle sorte qu’ils ne se cantonnent pas uniquement à l’installation de LilyPond.

Difficulté : moyennement facile
Préalables : C++ et la volonté de se familiariser avec les composantes internes de LilyPond
Connaissances appréciées : intérêt et expérience dans le maniement des fichiers de fonte ; des notions de METAFONT
Mentors : Werner Lemberg, Abraham Lee

Ajout de variantes pour certains glyphes

Difficulté : facile
Préalables : MetaFont, C++, une bonne vue pour les détails
Connaissances appréciées : les bases de LilyPond
Mentor : Werner Lemberg

Notation contemporaine

LilyPond excelle dans la création de notation non standard. La nécessité de coder chaque élément graphique plutôt que de simplement les dessiner peut paraître fastidieuse mais se révèle être un investissement solide. De nouvelles fonctionnalités en matière de notation ainsi fournies permettront une apparence uniforme, un tracé automatisé et une interface syntaxique naturelle.

Au sein du système de bibliothèque openLilyLib, l’étudiant créera une infrastructure de base et construira des blocs aux fins de faciliter la création de notation contemporaine. Accessoirement se développe un paquet couvrant certains aspect de la notation contemporaine comme, par exemple, le style d’un compositeur donné, des techniques étendues d’exécution pour un instrument particulier ou une certaine catégorie d’effets.

Difficulté : moyenne
Préalables : Scheme (interaction avec les arcanes de LilyPond), techniques de notation contemporaine
Connaissances appréciées : sens de la construction d’ossatures hiérarchisées
Mentors : NN, Urs Liska

Réécriture en Python de l’extension LilyPond pour LibreOffice

L’extension OOoLilyPond a permis d’inclure de façon agréable des extraits de partition LilyPond dans les documents OpenOffice.org/LibreOffice Writer, Draw et Impress tout en conservant ensemble le code et l’image. Après plusieurs années de suspension dans son développement, un effort a vu le jour pour rendre cette extension à nouveau compatible avec les nouvelles versions de LibreOffice et LilyPond.

Toutefois, l’écosystème de LibreOffice s’est modifié substanciellement, et il est désormais possible de récrire cette extension avec Python et PyQt. Ceci sera non seulement plus puissant de manière générale, mais permettra aussi l’intégration de fonctionnalités de Frescobaldi comme, par exemple, la coloration syntaxique, des aides à la saisie, des assistants à la creation de partition ou des transformations de musique.

Difficulté : moyennement facile
Préalables : Python, PyQt, les base de LilyPond, les base des extensions de LibreOffice
Connaissances appréciées : familiarité avec les bases du code de Frescobaldi ou l’envie de l’apprendre sur la période
Mentors : Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)

Automatisation des tests et documentation d’openLilyLib

openLilyLib constitue une infrastructure d’extension au code de LilyPond en fournissant un dépôt de courts extraits ainsi qu’une collection de paquets intégrés tels que, par exemple, des outils de mise en page ou un système d’annotations pour édition critique. Cette bibliothèque est très puissante et prometteuse, mais souffre de deux lacunes pour pouvoir réellement décoller : des tests automatisés et la génération d’une documentation.

L’automatisation des tests est une nécéssité si l’on veut s’assurer que des modifications fonctionnelles ne cassent pas d’autres fonctions au sein de la bibliothèque. Certains tests automatiques sont en place au niveau des extraits sur le serveur Github de Travis, mais ils demandent à être revus et étendus pour couvrir aussi les paquetages indépendants.

Afin d’être couramment exploitable par une majorité d’utilisateurs de LilyPond, openLilyLib a besoin de sa propre documentation. Cette documentation, qui doit être générée directement à partir des sources, nécessite un système qui requiert des auteurs de paquetage qu’ils documentent leurs sources et fournissent des exemples concrets à partir desquels la documentation sera générée. Dans l’idéal, bien que pas nécessairement, il devra être implémenté en connexion directe à Git, autrement dit s’exécuter à chaque mise à jour du dépôt. Aucun outil ni approche ne sont arrêtés, mais il faut savoir que le langage le plus répendu dans l’univers LilyPond est Python, ce qui pourrait être un parti pris. Une solution à base de Scheme pourrait tout aussi bien générer la documentation en étant déclanchée par la « compilation » d’un fichier LilyPond particulier. Il est généralement conseillé de se reposer sur des concepts et des outils qui ont fait leurs preuves lorsqu’ils sont issus d’autres langages.

Le résultat de la documentation devrait se présenter sous la forme d’un site HTML statique, consultable en local ou disponible sur un site web. Il serait toutefois souhaitable que cet outil génère une représenttation intermédiaire – tel un fichier JSON et ses fichiers associés par exemple – à partir de laquelle une application génératrice de page unique saurait retrouver le contenu pour affichage sur le site d’openLilyLib. Le développement d’un tel générateur de page unique peut éventuellement s’intégrer au projet GSoC.

Difficulté : moyenne
Préalables : Python ou Scheme, générateur(s) de site statique ou technologie d’application web dynamique (basée sur Node.js) ; intégration continue (peut s’acquérir sur la période)
Mentors : Urs Liska, Matteo Ceccarello

MusicXML

Amélioration des fonctionnalités d’import et d’export :

L’interopérabilité entre LilyPond et les autres applications utilisant MusicXML reste quelque chose de difficile. L’import de MusicXML est réalisé par conversion « manuelle » à l’aide du script musicxml2ly. L’export en MusicXML n’est disponible qu’au travers d’une fonctionnalité rudimentaire de Frescobaldi. L’interopérabilité naturelle entre LilyPond et les applications basées sur MusicXML requiert une véritable fonction d’import ainsi qu’un moteur de traitement dédié à l’export.

L’importation de XML doit fournir les fichier, ligne et colonne afin d’ajouter les attributs d’origine des objets. La fonctionnalité de cliquer-pointer sera alors disponible tant pour Frescobaldi que pour les autres EDI.

L’exportation en XML devra se faire avec une classe d’exportateur tel que cela se pratique déjà au niveau du MIDI. Ceci pourrait se réaliser à partir du travail déjà effectué par David Garfinkle lors du GSoC 2015. Devrait être vérifiée la possibilité d’utiliser une bibliothèque XML autre que celle fournie par Guile-2 afin de rendre cette fonctionnalité opérationnelle avec la version actuelle de LilyPond, basée quant à elle sur Guile-1.8.

Difficulté : moyenne
Préalables : MusicXML, Python, Scheme, les bases de LilyPond
Connaissances appréciées : connaissance d’autres éditeurs de partition, dans un but de tests comparatifs
Mentor : Jan-Peter Voigt

Information à l’attention des candidats et participants

Afin que l’expérience du GSoC se révèle satisfaisante et enrichissante, les candidats sont fortements encouragés à porter toute leur attention aux recommandations qui suivent. Certaines d’entre elles concernent la procédure de candidature, d’autres la période du stage au sein du projet.

Une liste des projets inactifs est disponible au grenier. Y sont recensés des projets toujours considérés comme d’actualité mais pour lesquels aucun mentor n’est à ce jour disponible.