Des listes ou des classes ?


Listes, tuples ou classes ?

En Python est implémenté le concept de liste - ce qui est un bienfait et caractéristique des langages évolués (et c'est effectivement cette présence qui m'a persuadé d'utiliser intensivement Python).

Mais les pratiquants professionnels du langage manfestent une aversion contre l'écriture de listes de listes:

[[....], [....], [....], [....], [....], [....]]

qui est à quelques détails d'implémentation près équivalente à :

((....), (....), (....), (....), (....), (....))

Il se peut que pour programmer des logiciels, les listes de listes ne sont pas une bonne idée - puisque les professionnels le disent. Mais se priver volontairement d'une possibilité offerte par un langage artificiel revient à une sorte d'auto-mutilation shadockiste.

Langages de description

Si on utilise Python pour écrire une partition de musique, on n'écrit pas un logiciel, mais on utilise les structures les plus efficaces des langages artificiels pour décrire l'événement sonore, depuis la synthèse du son jusqu'à sa mise en place dans l'espace et le temps. Écrire une partition n'induit aucun problème de maintenance : quand la partition est écrite dans sa version définitive, on n'y touche plus.

C'est cette fonction de description algorithmique qui est la plus importante. Les fonctions mathématiques ne sont que peu de choses (quand on a bien assimilé les quatre opérations élémentaires, on a tout compris). D'ailleurs les langages de description dédiés ou généralistes utilisent amplement les listes de listes de listes ... Et en tête, le projet Common Lisp Music (CLM) où on verra immédiatement un instrument se terminant sur 9 parenthèses). Les listes étant la base même de Lisp, cet argument n'en serait pas un ?

L'efficacité de la syntaxe lispienne (des listes de listes ...) montre son adéquation à la description du son et de la musique. Que Lisp ne soit pas plus répandu est dû à d'autres aspects du langage : l'inversion de la notation.

Il existe d'autres langages des description : le projet SAOL/SASL. Comment y sont traités les profils :

kline(x1, dur1, x2, dur2, x3, dur3, x4, ...)

C'est à dire l'annonce de la fonction, kline, (ce qui veut dire une suite de lignes droitres), suivie d'une liste non limitée en nombre de paramètres. Ces paramètres vont normalement par paires : (valeur, duree), (valeur, duree), (valeur, duree) etc. Ce qui n'est pas visible avec leur syntaxe à la queue leu leu. Remarque en passant : cette syntaxe, bien peu commode, n'autorise pas les ruptures (ce qui est un très mauvais choix esthétique). Quand le nombre de paramètres va au-delà de ce qui lisible en un coup d'oeil, on se rend compte qu'une structuration par tuples ou listes faciliterait la lecture.

Le projet SAOL/SASL a été certifié ISO quelque chose - par un organisme auto-certifié - mais certainement pas pour sa finesse d'analyse.

Csound utilise évidemment aussi des listes du même modèle - qui peuvent devenir énormes - de paramètres. D'où les même difficultés de lecture rapide.

Pour mémoire : PureData est un bac à sable graphique, SuperCollider aussi, comme certainement encore pas mal d'autres. Tous ces langages dédiés permettent d'obtenir très rapidement un premier son ou une suite de sons. Mais comme les structures fondamentales ne sont pas au premier plan formel, ça se gâte très vite.

PureData remplit des pages avec des graphiques d'usines à gaz, là où quelques lignes de Python suffiraient. Il faut ajouter que le musicien qui sait programmer en PureData ne sait encore rien programmer d'autre que quelques bouts de musique - tandis qu'un langage de programmation généraliste lui ouvrirait des horizons.

Pourquoi des listes ?

D'abord je rappelle que la musique n'est pas un logiciel, mais ses structures peuvent être décrites par des langages formels (ce qui n'estpas la même chose). Les critères pertinents sont, à côté de l'exactitude, la clarté et la lisibilité.

Quand utiliser des listes de listes accroît le confort de compréhension il n'y a aucune raison de s'en priver, d'autant que cette structure gigogne rend compte de la réalité du fait musical que des subterfuges logiciels pour les éviter ne feraient que cacher cette réalité.

Ainsi un événement musical est souvent constitué par une évolution de hauteur, de fréquence de filtre, de l'enveloppe, du panorama stéréophonique ; c'est à dire une assocation de quatre profils.

Or en amont chaque profil est lui-même constitué de fragments: de lignes droites, de cubiques, de courbes non-linéaires, c'est-à-dire des fonctions. Même s'il est acceptable que les évaluations se fassent n'importe quand (ce qui n'est pas toujours le cas), il est plus agréable de garder les valeurs significatives pour l'affichage. C'est un énorme avantage des langages généralistes tels que Python

Et en aval, une séquence ou un pièce est décrite par une liste d'événements. La Liste - comme structure mentale - est un des moyens fondamentaux pour garder la musique en mémoire.

Copyright 2011 (c) René Bastian - rbastian (arrobe) free.fr