midi2ly

Bonjour à tous,

Je cherche à récupérer pour mon fiston des partitions de batterie incluses dans
des fichiers midi. Si j'utilise midi2ly le résultat est à chier... Exemple :

trackJchannelA = {
  
  % [SEQUENCE_TRACK_NAME] DRUMS
  
}

trackJchannelB = \relative c {
  fis,4*29/120 s4*211/120 fis4*29/120 s4*211/120 |
  % 2
  fis4*29/120 s4*211/120 fis4*29/120 s4*3811/120 c4*29/120 s4*91/120
c4*29/120
  s4*91/120 |
  % 11

Aucune vraie notation de percussions, et une partition illisible. Rosegarden
n'est pas mieux. En fait strictement identique AMHA. Pb de codage midi dans le
source ou pb d'exportation ?

Pour l'instant je suis en train de recopier à la main (crayon-gomme-papier, hé
oui, ça la fout mal) mais j'aimerais avoir une méthode efficace pour l'avenir.

Merci à vous.

Psst philippe tu as un truc sur ce pb ?

···

--
Cordialement, Daniel Cartron
« Le drame de la vieillesse, ce n'est pas que l'on se fait vieux, c'est qu'on
reste jeune. »
Oscar Wilde

Bonjour Daniel,

Je cherche à récupérer pour mon fiston des partitions de batterie incluses dans
des fichiers midi. Si j'utilise midi2ly le résultat est à chier...

Pour te remercier pour ton langage, les auteurs de midi2ly pourraient
très bien t'envoyer sur les roses, en admettant peut-être que ce
convertisseur n'est pas très élaboré, et en faisant preuve de bonté dire
que midi2ly ne sait pas convertir une partie de percussion — pour
confirmer ton expérience, je n'ai rien vu dans le code source du script
qui prenne en charge les percussions.

Pour l'instant je suis en train de recopier à la main (crayon-gomme-papier, hé
oui, ça la fout mal) mais j'aimerais avoir une méthode efficace pour l'avenir.

Je suis prêt à ajouter à midi2ly la prise en charge des parties de
percussion dès la semaine prochaine, mais mon prochain "salaire" étant
fin janvier, je ne suis prêt à le faire que moyennant finances. Pour
partager le financement de cette petite fonctionnalité, je peux lancer
un appel sur la liste des utilisateurs anglophones si tu veux.

Ceci dit, il existe peut-être des programmes de conversion
MIDI->MusicXML/ABC libres, ou à défaut gratuits, et qui prennent en
charge les percussions ; si de plus abc2ly et/ou musicxml2ly géraient
également les percus (ce que je te laisse vérifier), tu n'aurais pas
besoin de demander d'ajouter cette fontionnalité à midi2ly.

Salutations lilyesques,
John

···

Le lundi 12 octobre 2009 à 13:50 +0200, Daniel Cartron a écrit :

Pour te remercier pour ton langage, les auteurs de midi2ly pourraient
très bien t'envoyer sur les roses,

Celles de Rosegarden ? Bon désolé que tu aies mal pris cette expression qui
fait malgré tout partie du langage familier, et qui est AMHA absolument
adaptée au résultat produit en terme de percus, je persiste et signe.

en admettant peut-être que ce
convertisseur n'est pas très élaboré, et en faisant preuve de bonté dire
que midi2ly ne sait pas convertir une partie de percussion — pour
confirmer ton expérience, je n'ai rien vu dans le code source du script
qui prenne en charge les percussions.

Bon si ça le prend pas en charge, au temps pour moi, mais il fallait le
savoir... Et comme je l'ai aussi écrit la conversion à partir de Rosegarden
est aussi moche.

> Pour l'instant je suis en train de recopier à la main
> (crayon-gomme-papier, hé oui, ça la fout mal) mais j'aimerais avoir une
> méthode efficace pour l'avenir.

Je suis prêt à ajouter à midi2ly la prise en charge des parties de
percussion dès la semaine prochaine, mais mon prochain "salaire" étant
fin janvier, je ne suis prêt à le faire que moyennant finances. Pour
partager le financement de cette petite fonctionnalité, je peux lancer
un appel sur la liste des utilisateurs anglophones si tu veux.

Arff je peux aussi écrire qq lignes de code cradingues en python pour faire du
chercher/remplacer bestial, mais la philosophie du libre n'est-elle pas (entre
autre) de ne pas devoir ré-inventer l'eau tiède ? D'où ma question de savoir
si ça existe déjà.

Ceci dit, il existe peut-être des programmes de conversion
MIDI->MusicXML/ABC libres, ou à défaut gratuits, et qui prennent en
charge les percussions ; si de plus abc2ly et/ou musicxml2ly géraient
également les percus (ce que je te laisse vérifier), tu n'aurais pas
besoin de demander d'ajouter cette fontionnalité à midi2ly.

Je vais regarder ça aussi, mais partir de midi pour passer par abc ou autre
pour ensuite arriver à ly, c'est bien compliqué et donc à terme probablement
générateur de bugs.

···

Le lundi 12 octobre 2009, John Mandereau a écrit :

--
Cordialement, Daniel Cartron
« Parler pour ne rien dire ou ne rien dire pour parler sont les deux
principes majeurs de tous ceux qui feraient bien de la fermer avant de
l'ouvrir. »
Pierre Dac

Arff je peux aussi écrire qq lignes de code cradingues en python pour faire du
chercher/remplacer bestial, mais la philosophie du libre n'est-elle pas (entre
autre) de ne pas devoir ré-inventer l'eau tiède ? D'où ma question de savoir
si ça existe déjà.

Je ne suis pas sûr que ça existe déjà, et j'ai au l'honnêté de le dire
dès mon premier message. Ce que je voulais dire, c'est que si ça
n'existe pas, alors je sais que c'est faisable pour quelques cacahuètes
— le format MIDI est binaire, et la biliothèque de décodage MIDI de
LilyPond est écrite en C, donc c'est un chouia plus que "qq lignes de
code cradingues en python" (ce n'est pas très difficile pour autant).

Je vais regarder ça aussi, mais partir de midi pour passer par abc ou autre
pour ensuite arriver à ly, c'est bien compliqué et donc à terme probablement
générateur de bugs.

Tu penses donc qu'il faudrait que midi2ly prenne en charge les
percus ?

Je reste disponible pour un éventuel travail sur Midi2ly
Salutations lilyesques,
John

···

Le lundi 12 octobre 2009 à 15:35 +0200, Daniel Cartron a écrit :

Je ne suis pas sûr que ça existe déjà, et j'ai au l'honnêté de le dire
dès mon premier message. Ce que je voulais dire, c'est que si ça
n'existe pas, alors je sais que c'est faisable pour quelques cacahuètes
— le format MIDI est binaire, et la biliothèque de décodage MIDI de
LilyPond est écrite en C, donc c'est un chouia plus que "qq lignes de
code cradingues en python" (ce n'est pas très difficile pour autant).

Bon disons que je voulais dire que je peux le faire cradingue en qq lignes :slight_smile:
En gros il suffit de virer toutes les pistes non percus du fichier midi, puis de
l'exporter en ly puis filtrer les commentaires et autres markup via display
lily. Ensuite un remplacement global des en-têtes puis ensuite on ajoute un
drummode, et derrière un bon coup de dictionnaire à la python (non seulement
our les notes mais aussi pour les durées qui sont notées de façon compliquée)
et le tour est joué. Mais ça c'est uniquement si on ne veut garder que la
partie percus, ça sera à peine plus trapu si on garde les autres voix.

Je ne connais pas le C, et pour tout dire je code plutôt avec les pieds, mais
ça je me sens capable de le faire en python.

Tu penses donc qu'il faudrait que midi2ly prenne en charge les
percus ?

Ben oui. Le libre c'est aussi des outils super puissants, bourrés d'un tas
d'options, non ? Donc une option pour avoir les percus et uniquement elles
serait un plus pour moi qui ne suis pas batteur, mais qui aime à accompagner
mon fils dans son travail.

Je reste disponible pour un éventuel travail sur Midi2ly

Si je peux aider ne serait-ce qu'en écrivant les correspondances entre notes
et notations percus, ce sera avec plaisir. Je préfère bosser modestement pour
la collectivité et que ça serve à tous plutôt que faire mon truc cradingue
dans mon coin et qui ne sert qu'à moi... :slight_smile:

···

Le lundi 12 octobre 2009, John Mandereau a écrit :

--
Cordialement, Daniel Cartron
« Jamais je ne me suis mieux entendu qu'avec personne. »
Serge Gainsbourg

Alors, en ce qui concerne midi2ly : c'est vrai que c'est pourri, nous
en sommes tous conscients, et peu de gens se sentent le courage de
travailler dessus. Martin Tarenskeen a récemment tenté d'apporter pas
mal d'améliorations, mais son travail n'a même pas été testé ni
validé.

Bien que ça ne serve généralement à rien, j'ai ajouté une prime
("bounty") de 50 euros sur l'amélioration de midi2ly ; Daniel ou
quiconque peut surenchérir dessus si nécessaire :
http://code.google.com/p/lilypond/issues/detail?id=839

Pour tous ceux qui sont intéressés par la prise en charge du MIDI
(import et export), il existe également une liste de discussion
spécialement consacrée à ce sujet :
http://lists.lilynet.net/midi/

Cordialement,
Valentin

···

2009/10/12 Daniel Cartron <****@****>:

Tu penses donc qu'il faudrait que midi2ly prenne en charge les
percus ?

Ben oui. Le libre c'est aussi des outils super puissants, bourrés d'un tas
d'options, non ? Donc une option pour avoir les percus et uniquement elles
serait un plus pour moi qui ne suis pas batteur, mais qui aime à accompagner
mon fils dans son travail.

Bon disons que je voulais dire que je peux le faire cradingue en qq lignes
:slight_smile:

En fait je réalise qu'il y a un truc un peu complexe, c'est la durée des
notes...

Première chose, midi2ly garde la notation brute du midi (pour ce que j'en
comprend) et note
<c gis' >4*116/480 s4*364/480 <d gis >4*116/480 s4*364/480 <c gis'

4*116/480 s4*124/480 c4*116/480 s4*124/480 <d gis >4*116/480 s4*364/480

alors que rosegarden exporte ça de façon plus propre :
< c, gis, > 16 r r8 < d, gis, > 16 r r8 < c, gis, > 16 r c, r < d, gis, > r r8
mais avec des silences visibles alors que midi2ly met des invisibles.

Donc si je peux me permettre une suggestion, ce serait de remplacer dans un
premier temps les sub-divisions de pulsations du midi par une durée à la lily.

Dans un deuxième temps, il faut fusionner les silences (visibles ou
invisibles) avec les notes. En effet en midi le son est noté avec sa durée
réelle, en général une double croche. Mais sur la partition on n'écrira pas la
durée mais uniquement le moment où on frappe. Par exemple on n'écrira pas
hho16 r16 r8 r4 hho16 r16 r8 r4
mais simplement
hho4 r4 hho4 r4
pour dire qu'on frappe tous les 2 tps,

Autre exemple :
< c, gis, > 16 r r8 < d, gis, > 16 r r8 < c, gis, > 16 r c, r < d, gis, > r r8
correspond à
<bda hhp>4 <sna hhp>4 <bda hhp>8 bda8 <sna hhp>4

Donc il faut fondre les silences inutiles (ceux du 2e exemple le sont tous)
mais garder les utiles (dans le 1er exemple il y en a). A priori il semble
qu'il faut s'aligner sur le temps, par exemple sur du 4/4 dans < c, gis, > 16
r r8 il faut additionner les durées pour écrire < c, gis, >4 qui deviendra
<bda hhp>4. Par contre < d, gis, > 16 r r d, 32 d, devient <sna hhp>8 r16
sna32 sna32.

Et ça ce sera moins simple à faire AMHA...

···

Le lundi 12 octobre 2009, Daniel Cartron a écrit :

--
Cordialement, Daniel Cartron
« La liberté consiste moins à faire sa volonté qu'à ne pas être soumis à celle
d'autrui. »
Jean-Jacques Rousseau - Discours sur l'inégalité

En fait je réalise qu'il y a un truc un peu complexe, c'est la durée des
notes...

[...]

Dans un deuxième temps, il faut fusionner les silences (visibles ou
invisibles) avec les notes. En effet en midi le son est noté avec sa durée
réelle, en général une double croche. Mais sur la partition on n'écrira pas la
durée mais uniquement le moment où on frappe. Par exemple on n'écrira pas
hho16 r16 r8 r4 hho16 r16 r8 r4
mais simplement
hho4 r4 hho4 r4
pour dire qu'on frappe tous les 2 tps,

Autre exemple :
< c, gis, > 16 r r8 < d, gis, > 16 r r8 < c, gis, > 16 r c, r < d, gis, > r r8
correspond à
<bda hhp>4 <sna hhp>4 <bda hhp>8 bda8 <sna hhp>4

Donc il faut fondre les silences inutiles (ceux du 2e exemple le sont tous)
mais garder les utiles (dans le 1er exemple il y en a). A priori il semble
qu'il faut s'aligner sur le temps, par exemple sur du 4/4 dans < c, gis, > 16
r r8 il faut additionner les durées pour écrire < c, gis, >4 qui deviendra
<bda hhp>4. Par contre < d, gis, > 16 r r d, 32 d, devient <sna >8 r16
sna32 sna32.

Et ça ce sera moins simple à faire AMHA...

Serait-il possible de procéder comme suit :
1) diviser la mesure en niveau rythmiques (ce qui peut se faire de façon
  systématique *si la mesure est connue*);
2) lorsqu’une note commence sur un niveau n, la faire « englober » les silences
  - si possible jusqu'au prochain niveau rythmique plus fort (ou égal) à n,
  - sinon (une note survient plus tôt), jusqu’au niveau rythmique le plus fort,
  - éventuellement, on force l’arrêt à un niveau donné : le temps, p. ex.

Ce que j’appelle niveau rythmique est le rhythmic level de Lerdahl et
Jackendoff (si mes souvenirs sont bons). Le principe, pour une mesure en 2/4
(ou binaire de manière générale) :
  - les pulsations de niveau 1 surviennent au premier temps de
  chaque mesure
  - celles de niveau 2 surviennent entre deux pulsations successives
  de niveau 1, soit à chaque deuxième temps
  - [...]
  - de manière générale, les pulsations de niveau (n + 1) survient entre
  deux pulsations successives de niveaux strictement inférieurs à n+1

Un petit dessin vaut mieux qu’un long discours. Dans le fichier ci-joint, les
niveaux rythmiques calculés jusqu’au niveau 5 avec la reprise de ton exemple
légèrement modifié.

metric_levels.ly (723 Bytes)

Édouard Gilbert.vcf (510 Bytes)

···

Le 13 oct. 09 à 07:57, Daniel Cartron a écrit :

Serait-il possible de procéder comme suit :
1) diviser la mesure en niveau rythmiques (ce qui peut se faire de façon
        systématique *si la mesure est connue*);

La mesure est forcément indiquée dans le fichier midi donc récupérée par
l'export, que ce soit via midi2ly ou rosegarden (pas encore testé les autres
mais ya pas de raisons).

Ce que j’appelle niveau rythmique .../...

Le niveau rythmique d'une partition de batterie est tout simplement (pour ce
que j'en ai vu jusqu'à maintenant) le chiffre du bas de la métrique. Il se
pourrait que ce soit modifié si le tempo ne correspond pas, par exemple du 4/4
avec un tempo à la croche. Pas encore trouvé d'exemples, je vais me fendre
d'un petit fichier test...

Pour moi la démarche serait la suivante :
-à chaque note (ou indication de percu) on regarde la durée (ou on garde celle
de la précédente) ;
- on ajoute tous les silences qui suivent jusqu'à concurrence de la valeur
d'un temps ;
-on recommence...

Bon c'est sommaire mais c'est le concept de base...

Un petit dessin vaut mieux qu’un long discours. Dans le fichier ci-
joint, les
niveaux rythmiques calculés jusqu’au niveau 5 avec la reprise de ton
exemple
légèrement modifié.

Je jetterai un cil dès que j'aurai un peu de temps.

Je ne me suis pas posé la question de gérer les « accords ».

Les accords sont fréquents, dès qu'on tape simultanément sur plusieurs trucs à
la fois, et ça passe très bien à l'export.

Ni de
celles des
n-uplets. Mais est-il possible de gérer proprement les n-uplets à
partir de fichier midi ?

Pour ce que j'en ai vu jusqu'à maintenant il semble que oui aussi.

Mes expérimentations de cet après-midi ont donné ceci :
- je commence par passer le fichier ly au travers du "filre" \displayLilyMusic
avec en outre un petit patch du module scm display-lily pour virer les
indications de numéros de mesures et autres "cochonneries", ainsi que les
stacccatos et autres tenuto qui sont intéressants en midi mais pas en
partitions ;
- ensuite remplacement des notes par les notations percus (ceci dit je ne
comprend pas pourquoi ça ne passe pas à l'export, puisque la table des percus
midi est parfaitement connue) ;
- remplacement bestial des durées du genre 16 r r8 par 4, etc. puis correction
manuelle de ce qui ne passe pas.

En fait, la grosse difficulté de passer du midi à une partition est que le
premier est fait pour l'oreille et le deuxième pour l'oeil.

Donc dans le genre de trucs qui seront difficiles à gérer je pourrais citer les
anacrouses (le midi se fout de ça et commence la mesure sur la première note
jouée), mais aussi les roulements, qui sont enregistrés en midi sous forme de
multiples x-uples croches mais qui se notent avec des barres sur les hampes
d'une seule note.

···

Le mardi 13 octobre 2009, Édouard Gilbert a écrit :

--
Cordialement, Daniel Cartron
« On a beau avoir une santé de fer, on finit toujours par rouiller. »
Jacques Prévert

Remarque préalable :

Désolé, Daniel, je n’ai répondu qu’à toi dans mon dernier mail, tu es quitte
pour un mail en double. Bonne nouvelle, il y a une information
supplémentaire. Sauras-tu la trouver ?

J’en profite pour réitérer ma demande :
quand la mailing list se décidera-t’elle à ajouter un champ « répondre à »
aux mails ?

On reprend.

Bon, je ne suis pas du tout sûr que l’on se soit compris.

Le fichier que j’ai envoyé ne contient pas le moindre bout de code. Il ne fait rien,
il illustre juste un morceau de niveau métrique.

Serait-il possible de procéder comme suit :
1) diviser la mesure en niveau rythmiques (ce qui peut se faire de façon
      systématique *si la mesure est connue*);

La mesure est forcément indiquée dans le fichier midi donc récupérée par
l'export, que ce soit via midi2ly ou rosegarden (pas encore testé les autres
mais ya pas de raisons).

J’’ignorais que les fichiers midi contenait des informations de mesure. Super.
Y-a-t’il également des informations de mesures partielles ? La durée du temps
en ticks également ? Les changements de mesure ? Je n’ai pas le temps de fouiller
la norme MIDI, je l’avoue. Je ne sais même pas si elle est accessible librement.
Mais il me semble me souvenir que non.

Ce que j’appelle niveau rythmique .../...

Le niveau rythmique d'une partition de batterie est tout simplement (pour ce
que j'en ai vu jusqu'à maintenant) le chiffre du bas de la métrique. Il se
pourrait que ce soit modifié si le tempo ne correspond pas, par exemple du 4/4
avec un tempo à la croche. Pas encore trouvé d'exemples, je vais me fendre
d'un petit fichier test...

C’est pour ça que je donnais ma définition de niveau rythmique. Pour qu’on
parle de la même chose. Je pense que mon idée se rapproche un peu de
la définition qu’en donne Wikipedia.

Remarquons la magnifique illustration (les niveaux plus forts sont indiqués
avec plus de points) :

Pour moi la démarche serait la suivante :
-à chaque note (ou indication de percu) on regarde la durée (ou on garde celle
de la précédente) ;
- on ajoute tous les silences qui suivent jusqu'à concurrence de la valeur
d'un temps ;
-on recommence...

Bon c'est sommaire mais c'est le concept de base...

Je pense que c’est un peu trop sommaire. Avec cette idée, on se retrouve à transformer

r32 c32 r16 r8

en

r32 c32~ c16~ c8

ou pire, en

r32 c8..

d’où ma suggestion. Qui revient, dans le fond, à s’arrêter au plus grand diviseur du temps
possible tout en évitant les liaisons ou les notes pointées.

Un petit dessin vaut mieux qu’un long discours. Dans le fichier ci-
joint, les
niveaux rythmiques calculés jusqu’au niveau 5 avec la reprise de ton
exemple
légèrement modifié.

Je jetterai un cil dès que j'aurai un peu de temps.

Je ne me suis pas posé la question de gérer les « accords ».

Les accords sont fréquents, dès qu'on tape simultanément sur plusieurs trucs à
la fois, et ça passe très bien à l'export.

Je ne suis pas sûr que les « accords » soient vraiment un problème dans
le cas de la percussion. Mais je ne sais pas s’il est préférable de transformer

<c g>16 r16 g16

en

<c g>8 r16 g16

ou en

<< {c4} {g8 r16 g16} >>

Ni de
celles des
n-uplets. Mais est-il possible de gérer proprement les n-uplets à
partir de fichier midi ?

Pour ce que j'en ai vu jusqu'à maintenant il semble que oui aussi.

Pas de ce que j’en ai vu. J’ai souvent vu des sextolets de doubles se transformer
doubles avec des notes alignées. Bon, je n’ai pas essayés des millions d’outils
(probablement juste MuseScore et Finale NotePad) et en général, le playback
fonctionnait bien. Je soupçonne qu’une trace du MIDI était gardée quelque part.

Mes expérimentations de cet après-midi ont donné ceci :
- je commence par passer le fichier ly au travers du "filre" \displayLilyMusic
avec en outre un petit patch du module scm display-lily pour virer les
indications de numéros de mesures et autres "cochonneries", ainsi que les
stacccatos et autres tenuto qui sont intéressants en midi mais pas en
partitions ;

Les staccatos et tenutos ne sont pas intéressants sur une partition ? Je dois
mal comprendre.

- ensuite remplacement des notes par les notations percus (ceci dit je ne
comprend pas pourquoi ça ne passe pas à l'export, puisque la table des percus
midi est parfaitement connue) ;

Probablement parce qu’il faut l’écrire. Et parce qu’il faut savoir que la voix est
une voix de percussions.

- remplacement bestial des durées du genre 16 r r8 par 4, etc. puis correction
manuelle de ce qui ne passe pas.

En fait, la grosse difficulté de passer du midi à une partition est que le
premier est fait pour l'oreille et le deuxième pour l'oeil.

Un prof nous avait un jour expliqué que le MIDI était un format de tablature bien
plus que de partition. Non pas une description de la musique, mais la description
de l’interprétation.

Donc dans le genre de trucs qui seront difficiles à gérer je pourrais citer les
anacrouses (le midi se fout de ça et commence la mesure sur la première note
jouée), mais aussi les roulements, qui sont enregistrés en midi sous forme de
multiples x-uples croches mais qui se notent avec des barres sur les hampes
d'une seule note.

Effectivement. Je ne vois pas comment se note un roulement. Comme un trémolo ?

Édouard GILBERT
PhD student - Université de Lille III
Équipe MOSTRARE - INRIA Lille Nord-Europe
****@****

Édouard Gilbert.vcf (510 Bytes)

···

Le 13 oct. 09 à 20:06, Daniel Cartron a écrit :

Le mardi 13 octobre 2009, Édouard Gilbert a écrit :

J’en profite pour réitérer ma demande :
quand la mailing list se décidera-t’elle à ajouter un champ «
répondre à »
aux mails ?

(mode 'admin #t)
La liste de diffusion vous prie d'utiliser la fonction "Répondre à la
liste" de votre client de messagerie, ou à défaut "Répondre à tous", son
logiciel de gestion Mailman offrant la possibilité de de pas délivrer un
message aux abonnés qui figurent explicitement dans les destinataires.
Il n'est pas question que la liste se décide à remplacer la valeur du
champ Reply-To, pour les raisons évoquées dans

https://lists.ubuntu.com/archives/ubuntu-fr/2005-April/003261.html
http://www.culte.org/projets/doc/reply-to.shtml
http://www.unicom.com/pw/reply-to-harmful.html

La dernière référence est en anglais, mais c'est l'argumentation la plus
complète.

Enfin, la liste vous serait reconnaissante d'utiliser votre adresse
d'inscription à la liste — il y a eu pas mal d'emails à modérer pour
cette raison ces derniers temps — ou bien de vous inscrire à plusieurs
adresses et n'activer la réception du courriel que pour une seule
adresse.
(mode 'admin #f)

Je réponds au sujet original du fil ci-dessous.

J’’ignorais que les fichiers midi contenait des informations de
mesure. Super.
Y-a-t’il également des informations de mesures partielles ? La durée
du temps
en ticks également ? Les changements de mesure ? Je n’ai pas le temps
de fouiller
la norme MIDI, je l’avoue. Je ne sais même pas si elle est accessible
librement.
Mais il me semble me souvenir que non.

MMA, l'organisme qui a standardisé la norme MIDI, vend les
spécifications, mais basta, on peut aussi trouver cette spécification
(ou une documentation apparemment de même valeur, n'ayant jamais
consulté la spécification officielle je ne sais pas) sur
http://home.roadrunner.com/~jgglatt/ -> Technical Docs and Programming
-> The MIDI Specification

Je pense que c’est un peu trop sommaire. Avec cette idée, on se
retrouve à transformer

r32 c32 r16 r8

en

r32 c32~ c16~ c8

ou pire, en

r32 c8..

d’où ma suggestion. Qui revient, dans le fond, à s’arrêter au plus
grand diviseur du temps
possible tout en évitant les liaisons ou les notes pointées.

Si j'ai bien compris, cela serait bien plus fin que l'actuelle option de
quantification -d de midi2ly. Si on implémente cette fonctionnalité, il
faudrait définir une option pour paramétrer le diviseur du temps
considéré.

Mais je ne sais pas s’il est préférable de
transformer

<c g>16 r16 g16

en

<c g>8 r16 g16

Tu veux dire

<c g>8 g16

? C'est l'option qui me semble la plus raisonnable.

ou en

<< {c4} {g8 r16 g16} >>

Ça n'a plus le même sens, et si ma mémoire est bonne ça peut s'exprimer
correctement en MIDI, c'est au convertisseur MIDI->"expressions
musicales à la LilyPond" de bien faire son boulot, et non pas à une
routine de post-traitement.

Probablement parce qu’il faut l’écrire.

En effet, la table des percus n'est pas connue de midi2ly.

Et parce qu'il faut savoir
que la voix est
une voix de percussions.

C'est connu grâce à l'instrument MIDI ça, non ?

Un prof nous avait un jour expliqué que le MIDI était un format de
tablature bien
plus que de partition. Non pas une description de la musique, mais la
description
de l’interprétation.

Pour surenchérir sur ce point (merci les cours du master ATIAM ;-), le
MIDI est un format conçu pour décrire le jeu d'un instrument à clavier,
il n'est pas très bien adapté aux instruments pour lesquels on peut
contrôler en continu le son après l'attaque.

Effectivement. Je ne vois pas comment se note un roulement. Comme un
trémolo ?

Oui. Cela dit, il y a beaucoup de travail à faire sur midi2ly avant de
songer à lui ajouter un détection heuristique de trémolo.

Salutations lilypondesques,
John

···

Le mardi 13 octobre 2009 à 23:46 +0200, Édouard Gilbert a écrit :

Alors, en ce qui concerne midi2ly : c'est vrai que c'est pourri, nous
en sommes tous conscients, et peu de gens se sentent le courage de
travailler dessus. Martin Tarenskeen a récemment tenté d'apporter pas
mal d'améliorations, mais son travail n'a même pas été testé ni
validé.

Je m'engage à regarder son travail, qui n'est pas bien présenté sous
forme de patch, mais de toute façon c'est un préalable à tout autre
travail sur midi2ly.

Pour tous ceux qui sont intéressés par la prise en charge du MIDI
(import et export), il existe également une liste de discussion
spécialement consacrée à ce sujet :
http://lists.lilynet.net/midi/

... et pour s'y abonner sans passer par Nabble, le plus simple est
d'envoyer un message avec pour objet "subscribe" à
****@**** avec un corps vide.

···

Le lundi 12 octobre 2009 à 20:28 +0200, Valentin Villenave a écrit :

J'avais commencé à répondre mais John m'a doublé :-)... Je vais intercaler.

J’ignorais que les fichiers midi contenait des informations de mesure.
Super.
Y-a-t’il également des informations de mesures partielles ?

Qu'entends-tu par là ? Anachrouses ? Non, d'après mes essais, si on écrit une
partition avec anachrouse et qu'on ouvre le fichier midi dans rosegarden par
exemple les barres de mesures sont toutes décalées. La seule solution que je
vois serait de mettre des mesures complètes començant par des silences.

La durée
du temps
en ticks également ?

Les ticks valent 10 ms, comme on peut le lire sur le lien donné par John. Fort
intéressant par ailleurs.

Les changements de mesure ?

Oui à ma connaissance. Et de tonalité etc. D'ailleurs ces histoires de
tonalité ont un effet pervers sur l'export des percussions, un coup on a le
charleston ouvert (par exemple) sur le do dièse, un coup sur le ré bémol, donc
ça double la taille du dictionnaire de conversion.

MMA, l'organisme qui a standardisé la norme MIDI, vend les
spécifications, mais basta, on peut aussi trouver cette spécification
(ou une documentation apparemment de même valeur, n'ayant jamais
consulté la spécification officielle je ne sais pas) sur
http://home.roadrunner.com/~jgglatt/ -> Technical Docs and Programming
-> The MIDI Specification

En plus je pense que pour un habitué de l'hexadécimal (non John ce n'est pas
du binaire) ça doit pouvoir se lire assez couramment.

Tu veux dire

<c g>8 g16

? C'est l'option qui me semble la plus raisonnable.

Moi aussi, c'est ce que je fais manuellement en tout cas.et j'obtiens une
partition convaincante.

Les staccatos et tenutos ne sont pas intéressants sur une partition ?
Je dois
mal comprendre.

Ben avec une batterie faire un tenuto ça me semble difficile, et un staccato me
semble légèrement pléonasmatique :slight_smile: Bon ceci dit je ne suis pas batteur et il
y a certainement des indications qui sont propres à l'instrument. Le fait
qu'il en passe lors d'un export ne signifie pas forcément qu'elles aient été
saisies initialement, le midi enregistre le moment où la note débute et où
elle s'arrête, sa vélocité, sa hauteur évidemment, le canal sur lequel est va
transiter, et l'instrument qui doit la jouer. Et quelques autres trucs. Si le
fichier est créé avec un instrument midi, le jeu de l'instrumentiste est plus
expressif qu'une écriture manuelle, et le convertisseur cherchera AMHA à
transformer les variations subtiles de vélocité et pitch en autre chose... Là
je spécule...

En tout cas une chose qui passe à l'export et qui est super pénible à retirer
c'est tous les commentaires sur les numéros de mesure et autres trucs, il y en
a à chaque mesure, c'est lourd, y a-t-il une option pour virer ça ?

En effet, la table des percus n'est pas connue de midi2ly.

Pourtant il y en a bien l'indication dans le fichier midi, non ? Bankselect
probablement si j'ai bien compris. Rosegarden par exemple sait la trouver.

> Et parce qu'il faut savoir
> que la voix est
> une voix de percussions.

C'est connu grâce à l'instrument MIDI ça, non ?

Non pas tout à fait, dans le fichier midi les percus sont systématiquement sur
le canal 10 donc on sait que ça en est. Sinon ça le jouerait en piano ou
guitare ou autre...

Autre chose, Rosegarden sait parfaitement m'afficher que le fa dièse est le hhc
(charleston fermé). Donc pourquoi l'export garde un fa dièse, et ne met pas un
hhc ? Idem pour midi2ly qui lui a l'excuse de ne pas connaitre la table :slight_smile:

> Un prof nous avait un jour expliqué que le MIDI était un format de
> tablature bien
> plus que de partition. Non pas une description de la musique, mais la
> description
> de l’interprétation.

Parfaitement exact.

Pour surenchérir sur ce point (merci les cours du master ATIAM ;-), le
MIDI est un format conçu pour décrire le jeu d'un instrument à clavier,
il n'est pas très bien adapté aux instruments pour lesquels on peut
contrôler en continu le son après l'attaque.

Tu veux dire un instrument à vent par exemple ? On peut parfaitement
transmettre des variations de pitch ou de vélocité a posteriori, je le fais
avec mon sax midi (si l'expandeur est adapté, mais ce n'est plus un pb midi,
mais matériel).

> Effectivement. Je ne vois pas comment se note un roulement. Comme un
> trémolo ?

Oui. Cela dit, il y a beaucoup de travail à faire sur midi2ly avant de
songer à lui ajouter un détection heuristique de trémolo.

Je suppose que si la durée de la note correspondant à un instrument est
inférieure à une valeur plancher (fraction du temps) et répétée à l'identique
plusieurs fois on peut dire que c'est un roulement. Le pb est que si il y a un
roulement de caisse claire pendant que le batteur utilise aussi les pieds les
indications des notes de caisse claire seront à l'intérieur de notations entre
<>, donc pas évident à extraire...

···

Le mercredi 14 octobre 2009, John Mandereau a écrit :

--
Cordialement, Daniel Cartron
« Le bonheur, c'est de désirer ce que l'on a. »
Saint Augustin

D'ailleurs ces histoires de
tonalité ont un effet pervers sur l'export des percussions, un coup on a le
charleston ouvert (par exemple) sur le do dièse, un coup sur le ré bémol, donc
ça double la taille du dictionnaire de conversion.

Je ne comprends pas bien de quel dictionnaire de conversion tu parles.
Ce n'est pas très propre et ça n'a pas de sens de traduire un numéro de
note MIDI qui doit être interprété comme un sons de percussion à hauteur
non déterminée en hauteur de note, puis convertir cette hauteur de note
en nom de percussion pour le format final (ly ou autre) ; il est bien
plus pratique et efficace de traduire directement tout numéro de note
MIDI sur la chaîne 10 en nom de percussion.

En plus je pense que pour un habitué de l'hexadécimal (non John ce n'est pas
du binaire)

J'ai écrit que les formats de fichier MIDI sont des formats binaires
(lisibles avec un éditeur hexadécimal), sous-entendu par opposition à
des formats texte (lisibles avec un éditeur de texte) ; ça n'a rien à
voir avec le fait de noter un nombre en hexadécimal, binaire, octal,
décimal ou dans la base que tu veux.

En tout cas une chose qui passe à l'export et qui est super pénible à retirer
c'est tous les commentaires sur les numéros de mesure et autres trucs, il y en
a à chaque mesure, c'est lourd, y a-t-il une option pour virer ça ?

Non, mais comme d'habitude en ce qui concerne le logiciel libre, on a 3
options :
- on le fait soi-même et on envoie un patch,
- on convainc quelqu'un d'autre (pas nécessairement les développeurs
principaux du logiciel) de le faire,
- on paie quelqu'un pour le faire.

> En effet, la table des percus n'est pas connue de midi2ly.

Pourtant il y en a bien l'indication dans le fichier midi, non ? Bankselect
probablement si j'ai bien compris. Rosegarden par exemple sait la trouver.

Non, cette table fait partie du standard GM (General Midi) :
http://home.roadrunner.com/~jgglatt/tutr/gm.htm#Keys

Non pas tout à fait, dans le fichier midi les percus sont systématiquement sur
le canal 10 donc on sait que ça en est. Sinon ça le jouerait en piano ou
guitare ou autre...

Effectivement, je ne me souvenais plus de ce point du standard GM.

Autre chose, Rosegarden sait parfaitement m'afficher que le fa dièse est le hhc
(charleston fermé). Donc pourquoi l'export garde un fa dièse, et ne met pas un
hhc ?

Si c'est l'export Rosegarden->ly, nous ne pouvons rien y faire ici.

Tu veux dire un instrument à vent par exemple ? On peut parfaitement
transmettre des variations de pitch ou de vélocité a posteriori, je le fais
avec mon sax midi (si l'expandeur est adapté, mais ce n'est plus un pb midi,
mais matériel).

Je sais bien, mais le débit MIDI est trop limité pour un contrôle fin
avec beaucoup de paramètres, à ma connaissance le MIDI ne modélise pas
bien les subtilités d'attaque des instruments à anche ou à cordes
frottées, plus précisément MIDI n'a aucune notion de régime
transitoire/permanent. Comment exprimes-tu correctement avec un flux
MIDI un jeu détaché dans le son (flux d'air continu avec légers coups de
langue) sur un instrument à anche ? Comment exprimes-tu différents
types de vibrato en MIDI ?

Je suppose que si la durée de la note correspondant à un instrument est
inférieure à une valeur plancher (fraction du temps) et répétée à l'identique
plusieurs fois on peut dire que c'est un roulement. Le pb est que si il y a un
roulement de caisse claire pendant que le batteur utilise aussi les pieds les
indications des notes de caisse claire seront à l'intérieur de notations entre
<>, donc pas évident à extraire...

Tu peux très bien faire une détection indépendante pour chaque
instrument.

John

···

Le jeudi 15 octobre 2009 à 10:12 +0200, Daniel Cartron a écrit :

John Mandereau wrote

Je suis prêt à ajouter à midi2ly la prise en charge des parties de
percussion dès la semaine prochaine, mais mon prochain "salaire" étant
fin janvier, je ne suis prêt à le faire que moyennant finances. Pour
partager le financement de cette petite fonctionnalité, je peux lancer
un appel sur la liste des utilisateurs anglophones si tu veux.

Salutations lilyesques,
John

Bonjour.
Ce message date de 2009 et nous sommes en 2020 et j'ai toujours ce problème
de percussions du canal 10 du fichier midi importées par midi2ly comme des
notes classiques, sans \drums{}, ni symbole comme "sn"...
Est-ce qu'une version de lilypond intègre cette correction ?

Merci pour votre réponse,

Musicalement,
Benoît.

···

--
Sent from: http://lilypond-french-users.1298960.n2.nabble.com/

Bonjour,

Non, ce n'est pas encore le cas. Ce convertisseur bénéficie hélas d'une
faible maintenance à l'heure actuelle. Il faut dire que MIDI n'est pas le
format le plus adapté à l'échange de partitions (MusicXML étant plus en vogue
en ce moment).

Éventuellement, ouvrez une page de bogue sur Issues · LilyPond / LilyPond · GitLab,
en anglais bien entendu, pour que le problème ne se perde pas.

Cordialement,
Jean Abou Samra

···

Le 25/09/2020 à 15:27, gerbille a écrit :

John Mandereau wrote

Je suis prêt à ajouter à midi2ly la prise en charge des parties de
percussion dès la semaine prochaine, mais mon prochain "salaire" étant
fin janvier, je ne suis prêt à le faire que moyennant finances. Pour
partager le financement de cette petite fonctionnalité, je peux lancer
un appel sur la liste des utilisateurs anglophones si tu veux.

Salutations lilyesques,
John

Bonjour.
Ce message date de 2009 et nous sommes en 2020 et j'ai toujours ce problème
de percussions du canal 10 du fichier midi importées par midi2ly comme des
notes classiques, sans \drums{}, ni symbole comme "sn"...
Est-ce qu'une version de lilypond intègre cette correction ?

Merci pour votre réponse,

Musicalement,
Benoît.

Merci pour votre réactivité.

Je vais aller lire le code source de midi2ly, ça m'entrainera.

Musicalement,
Benoît.

···

--
Sent from: http://lilypond-french-users.1298960.n2.nabble.com/