lilypond-user-fr
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suivre une partition avec un curseur visuel

From: Mathieu Demange
Subject: Re: Suivre une partition avec un curseur visuel
Date: Mon, 6 Apr 2020 17:36:19 +0200 
Tout ce que tu viens de décrire là est à peu de chose près ce que j’avais en 
tête pour si jamais un jour les journées passaient à 36 heures ;)

Je n’avais fait qu’un proof of concept, mais qui avait permis à Paul Morris 
d’écrire l’engraver Scheme (ce dont j’aurais été absolument incapable), mais 
surtout le patch pour les output-attributes dans le backend SVG.

Qu’est-ce que tu entends par « partitions sur plusieurs systèmes » ? Systèmes à 
plusieurs portées, oui (cf. l’exemple avec Tetris), et pas mal de mises en page 
que j’avais pu tester (y compris en « rouleau horizontal »).

Pour le curseur, j’avais le truc en tête (avec une référence temporelle et un 
interpolateur), je peux essayer de coder ça ces jours-ci pour me remettre 
dedans.

Pour tout ce qui est DSP est détection de tempo, ça me semble moins prioritaire 
: ne marchera jamais avait toutes les musiques, sauf les plus « boum, boum ». 
Par contre, le tempo mapping est super important en effet. Dans l’exemple du 
solo de vibraphone de Mainieri, c’est ce qui permet de garder la synchro (et je 
trouve que c’est un exercice rigolo, mais ça c’est mon côté masochiste). Dans 
mes bricoles, j’avais aussi commencé à développer un outil pour ça : remapper 
toutes les valeurs de temps du SVG visuellement par dessus une forme d’onde.

En l’état je n’ai pas vraiment de co-équipier sur ce projet à part l’aide 
inestimable et ponctuelle de Paul, mais je peux donner à quiconque le désir les 
accès sur le repo (sur GitLab).

Amicalement,

Mathieu

> On 6 Apr 2020, at 17:06, Valentin Villenave <address@hidden> wrote:
> 
> On 4/6/20, Mathieu Demange <address@hidden> wrote:
>> Je n’ai jamais eu le temps de mettre au propre mes derniers travaux
>> (scrolling et curseur justement), mais cela peut peut-être quand même vous
>> intéresser ?
>> 
>> https://gitlab.com/sigmate/lilypond-html-live-score
> 
> Hé, j’avais oublié ça… Très intéressant. Est-ce que ça peut
> fonctionner avec des partitions sur plusieurs systèmes ? (je n’ai pas
> vu d’array dans le code)
> 
> De quelle façon comptais-tu t’y prendre pour synchroniser le curseur ?
> Ajouter un surlignement de notes correctement synchronisé serait
> certainement faisable avec quelques lignes de Javascript/CSS, comme ce
> que fait Kurt ; le curseur est certainement un peu plus compliqué mais
> pas infaisable. Pour tout ça comme pour la succession des "slides", le
> modèle proposé par Kurt me semble fournir un bon point de départ.
> 
> Il serait faisable de recoder tout ça en Scheme pur, et d’essayer de
> proposer ça pour inclusion dans LilyPond. Par exemple avec un nouveau
> backend, ou même un nouveau mode de rendu (en plus de \layout et
> \midi, il pourrait y avoir \html par exemple). Du coup ça
> sélectionnerait automatiquement le backend svg et l’export midi, et
> puis ça se chargerait de créer la page html qui va bien. Il serait
> trivial de laisser LilyPond générer directement le préambule (<head>
> etc.) de la page HTML, en laissant à l’utilisateur la possibilité
> d’ajouter autant de CSS et de squelette HTML à travers quelques
> variables toutes-prêtes.
> 
> Une possibilité intéressante serait de ne pas avoir besoin de reposer
> sur un élément audio généré de façon externe ; par exemple avec l’API
> WebMIDI :
> https://github.com/djipco/webmidi ou
> https://github.com/g200kg/webaudio-tinysynth
> quitte à offrir, évidemment, une possibilité d’ajouter un fichier son
> rendu séparément voire enregistré par de vrais musiciens -- auquel cas
> on pourrait même imaginer, comme ce que fait Kurt, la possibilité
> d’ajouter un fichier beatmap externe, transcrit d’après la piste audio
> avec un algorithme FFT.
> 
> Le code de Kurt a été refusé par David (tout comme des propositions de
> Mike d’ajouts métatextuels dans le SVG, quelques années plus tôt, très
> similaires à ce que tu fais avec le Scheme engraveur ici) parce qu’il
> sentait le bricolage sur-mesure plutôt qu’une solution propre et
> adaptable à tous les utilisateurs ; en proposant une implémentation
> bien propre et correctement utilisable plutôt qu’un vaporware fumeux,
> ça aurait toutes les chances d’être accepté.
> 
> De surcroît, je pense vraiment que la voie du SVG/JS/CSS est la bonne
> (comme ça pas de dépendance externes ou très peu, contrairement à
> toutes les propositions à base de ffmpeg, de codecs parfois
> incertains, et autres formats plus ou moins non-Libres). D’ailleurs
> une sortie HTML peut très facilement être convertie en vidéo, en
> animation interactive ou en ce qu’on veut.
> 
> Si ton co-équipier et toi vous sentez d’attaque pour proposer quelque
> chose, je serais bien partant pour aider à l’implémenter sous une
> forme qui pourrait être acceptée upstream…
> 
> V.
reply via email to
[Prev in Thread] Current Thread [Next in Thread]