Récemment, j'ai découvert l'environnement de programmation Sonic Pi, à la suite d'une conférence de Raphaël Forment sur le live-coding. J'ai déjà testé quelques logiciels de sons, j'ai joué de la guitare pendant 1 ans ou 2, et j'ai un père qui est musicien. Il est possible que ces facteurs aient joué dans l'équation. Mais surtout, je suis programmeuse depuis quelques années déjà, et je crois que ça m'a apporté une attention particulière à la compréhension des choses, des systèmes, des mécaniques/mécanismes. En même temps quand on programme, on est obligéj de comprendre comment ça marche. Souvent on pars de zéro, d'une feuille blanche, et on a la documentation du langage avec quelques exemples. Du coup, on doit être prêtj à apprendre pour créer. On est pas forcément obligéj d'apprendre complètement et entièrement comment ça marche, par exemple comment le son fonctionne, les fréquences etc. mais on est obligatoirement confrontéj à des mots, et non à des symboles comme dans les logiciels. On met ces mots en relations avec d'autres mots, c'est de l'écriture, donc la relation que l'on a avec la création de musique pour revenir à ça, elle est forcément différente. Peut-être que dans le cas de la programmation musicale, c'est plus proche de la création de partition. Au moment même ou j'ai envisagé l'idée de faire de la musique avec Sonic Pi, j'étais dans une optique de prendre mon temps. J'ai donc lu attentivement, pas-à-pas, le tutoriel. Et toutes les notions que j'avais entendu comme l'amplitude, le gain, mais aussi la manière de traiter la musique devenaient un peu plus claire. Je pouvais entendre l'action de ces paramètres sur le son. Je ne pense pas qu'il soit impossible d'apprendre tout ça autrement, la plupart des musiciens ne sont d'ailleurs pas du tout des programmeurs, mais j'ai l'impression en revanche que cette approche lente d'apprentissage méthodique que convoque la pratique de la programmation est une manière d'entrer plus profondément dans les systèmes de créations. C'est ce que Donald E.Knuth propose d'expérimenter, avec des systèmes comme laTex ou métafonte,
Knuth Donald, Delorme M.R. Le concept de métafonte. In: Communication et langages, n°55, 1er trimestre 1983. pp. 40-53. https://www.persee.fr/doc/colan_0336-1500_1983_num_55_1_1549
ou il n'y a aucune interface ou joli bouton à cliquer. L’idée est que l’auteur décrive avant tout la structure logique. Cette obligation à repenser le système, donne aussi la possibilité d'intervenir dans ce système, en quelque sorte de reprendre le contrôle et d'agir à tout les endroits de la conception. Les logiciels, les systèmes d'exploitations, rajoutent une couche d'opacité avec les interfaces. Elles permettent d'aller vite car elles jouent avec des codes supposément universels, mais ne permettent pas forcément une réelle compréhension et un accès au fonctions qu'elles utilisent. En même temps, la technique nous dépasse, et la plupart du temps nous n'avons ni le temps, ni même les connaissances suffisantes pour nous plonger dedans. Pourtant, je pense avoir une approche différente vis-a vis des logiciels aujourd'hui. La manière dont je les appréhende est différente. Quand on teste un logiciel, on doit aussi comprendre comment fonctionne l'environnement et les outils que l'on utilise, mais une sorte de système nous est plus ou moins déjà imposé. Quand on ouvre Photoshop, on doit créer un "document", une page blanche, une feuille, à laquelle on donne un format (qui peut aussi être un format web), on choisit l'unité de mesure que l'on veut utiliser, et on a la page blanche devant nous. Il y'a aussi cette notion de WYSIWYG, ou on a en direct un simulacre de feuille blanche, et on intervient directement dessus. On choisit parmi des outils, pinceau, crayon, ciseaux, bref, des outils que l'on connait, et dont on sait à l'avance le résultat qu'ils vont provoquer. Lorsque l'on programme de faire un dessin via un language de programmation, la projection est toute autre. On commence déjà avec une surface, que l'on définit dans l'écran, le passage a une éventuelle impression est à construire indépendamment. Je ne vais pas dessiner sur une feuille virtuelle, je vais dessiner dans un espace donné, dans la surface de mon écran. D'ailleurs, je ne vais pas dessiner, je vais inscrire une suite de points, qui vont se teinter d'une couleur pour produire un tracé. Si je veux reproduire l'outil de pinceau de photoshop, je dois d'abord capter les coordonnées de ma souris, et attribuer à chacune de ces coordonnées une couleur, une épaisseur. En fait, en faisant ça, en programmant ça, je suis consciente que je ne reproduis pas la réalité, je suis déjà un peu plus consciente de l'espace dans lequel je me trouve: un espace virtuel, ou je travaille avec un langage de programmation car je suis sur un appareil capable, par divers programmes/logiciels de compilations, de m'afficher des pixels colorés via un écran - même si bien sur, je ne saurais pas dire avec une grande précision tout ce qu'il s'y passe et comment.
Le but ici n'est pas forcément de faire une liste exhaustive de toutes les possibilités ou avantages qu'offre la programmation, mais simplement de mettre en avant certains points, qui me semble important. Déjà le fait que cette simulation du réel, est finalement une couche d'opacification dans notre compréhension de ce qu'est l'action de création. Aussi que la programmation permet de se questionner sur ce que l'on est en train de faire, et donc de nous permettre d'agir à certains endroits, de remettre en question ce qui nous semble évident.
Ce qui me semble aussi intéressant avec la pratique de la programmation, c'est la recherche de nouveaux systèmes. Parce que penser le système, penser les outils, c'est forcément penser la forme "finale".