Code élégant et bonnes pratiques

Cet article sera plus court que les précédents. Il est pourtant tout aussi important. Je vais essayer de vous présenter quelques techniques simples pour accroître la lisibilité de votre code. Il s’agit d’un sujet à ne pas négliger tant celui-ci peut conditionner votre jeu musical. Lire du code est difficile, et faire tout ce qui est en votre possible pour maintenir une bonne lisibilité du code est important. Gardez à l’esprit que vous n’aurez jamais toute votre tête si par malheur vous vous trouviez à live-coder en public : il vous faudra penser à votre public, aux problèmes techniques, à votre propre stress, etc.. Plus vous simplifierez votre code, mieux ce sera.

Ne pas se répéter

Une des règles d’or consiste à ne pas se répéter ou à éviter au maximum les répétitions dans votre code. Si répétition il y a, veillez à ce que celle-ci soit volontaire ou qu’elle permette d’encourager la lisibilité d’un évènement. Voici quelques exemples :


live_loop :test do play :c2, amp: 0.5 sleep 0.25 play :c2, amp: 0.7 sleep 0.25 end

Dans le feu de l’action, vous pourriez être encouragés à écrire ce type de boucle. Vous la rendrez d’autant plus facile à maintenir si vous utilisez des structures plus flexibles :


live_loop :test do ; tick play :c2, amp: (ring 0.5, 0.7).look // ou amp: (line 0.5, 0.7, steps: 2).look sleep 0.25 end

Non seulement vous simplifiez votre code, mais vous le rendez également plus aisément suceptible à des modifications et à des altérations au cours du temps. Si vous souhaitiez par exemple moduler l’amplitude de manière un peu plus originale, vous pourriez rapidement changer pour écrire :


live_loop :test do ; tick play :c2, amp: (line 0.5, [0.2, 0.8].choose, steps: 5).look sleep 0.25 end

De manière générale, il y a une tendance naturelle à répéter les instructions les plus basiques et les plus courantes :

  • play / midi / midi_cc.
  • sleep / wait.

Erreurs fréquentes

Il existe certaines erreurs assez fréquentes qu’il est possible d’éviter facilement dès lors que l’on en prend conscience. Elles peuvent amener dans le pire des cas à un arrêt de la lecture du buffer et dans le meilleur des cas, à une absence de changement lorsque vous lisez votre code (particulièrement si vous utilisez un éditeur de texte externe et qu vous ne jetez pas un oeil à la console assez régulièrement).

  • Absence de déclaration de la synchronisation des boucles.
  • Absence de .tick ou de .look dans une partie du code.
  • Erreur liée à un scope.
  • Erreur liée à une déclaration conditionnelle fautive.
  • Lag lié à un trop grand nombre d’informations MIDI transitant par un seul canal.
  • Destruction du signal sonore par accumulation d’effets.

Un des talents que vous devez chercher à développer consiste à être capable d’avoir un regard critique sur votre code au fur et à mesure de l’écriture. Ce n’est pas toujours possible, aussi est-il important de prendre au moins de temps pour l’optimisation que pour l’écriture de nouvelles idées. Veillez à laisser votre code assez ouvert pour qu’il soit possible de le modifier très rapidement.

Déplacer les données

Vous jouerez fréquemment avec un grand nombre d’anneaux, d’accords et de valeurs rythmiques. Si vous savez par avance que vous souhaitez en utiliser beaucoup, déplacez les données dès le début pour rendre votre code plus facile à maintenir :

  • nommez vos anneaux, stockez-les en dehors d’un scope spécifique. Ainsi vous pourrez utiliser le même anneau à de multiples endroits du code.
  • Définissez quelques variations d’un même anneau, d’une même courbe d’automation, etc.. Ainsi vous pourrez très rapidement créer des variations intéressantes. Si vous disposez d’une autom1 ,(automatisation n°1), créez une autom2 et autom3. Vous aurez trois fois plus de choix en ne changeant que le chiffre, et les possibilités de combinaison de celle-ci avec les différents paramètres vous ouvrirons beaucoup de portes.

Seule la musique algorithmique peut vous permettre de jouer aussi rapidement sur le contenu de la musique que vous écrivez et d’en entendre immédiatement les résultats. Profitez-en. Vous auriez du mal à copier/coller aussi rapidement des courbes d’automation sur des logiciels d’édition musicale ou autre.

Abusez des commentaires

Cela vaut surtout les performances les plus longues. Il peut arriver parfois que vous conserviez une partie de votre buffer sans toutefois la jouer. Une demi-heure plus tard, vous souviendrez-vous de l’effet d’une boucle un peu complexe, des valeurs les plus efficaces pour chaque paramètre, etc ? N’hésitez pas à user et à abuser des commentaires pour conserver un peu de votre processus de réfléxion. Il existe beaucoup de techniques différentes pour commenter votre code, en voici quelques unes :


=begin Vous pouvez écrire un commentaire sur plusieurs lignes tant que ce dernier commence par une balise =begin et se termine par une balise =end. =end

D’autres techniques plus légères existent :


## LA BONNE VIEILLE TECHNIQUE # Celle-ci est plutôt classique mais vous la rencontrerez souvent. # Elle a pour avantage de bien séparer le code du commentaire. # Ce n’est pas à proprement parler un commentaire multi-ligne, mais l’effet # est strictement similaire. #############################