Accueil
SuperCollider vs Max/MSP - épisode 1 Envoyer
Max/MSP/Jitter - Trucs et astuces
Mardi, 19 Juillet 2011 20:58

Cela fait maintenant bientôt une quinzaine d'années que j'utilise Max/MSP. Cet environnement m'a permis d'explorer de multiples dimensions de la création musicale, depuis les multiples formes de synthèse jusqu'aux modules de transformation sonore sur mesure en passant par l'interconnexion avec des commandes gestuelles variées ou l'élaboration de dispositifs pour le concert, sans oublier la réalisation de plug-ins de spatialisation octophonique pour le défunt Pluggo.

 

Je connais l'existence de SuperCollider depuis à peu près aussi longtemps. La première fois que j'en ai entendu parler, ce logiciel en était encore à sa première génération. Il était développé par une seule personne (un certain James McCartney) et était payant. Depuis il est passé à sa deuxième puis à sa troisième génération. Ses possibilités se sont considérablement élargies et il est devenu gratuit. En outre, il est développé et utilisé par une communauté très large et dynamique, ce qui est toujours encourageant.

 

Régulièrement, SuperCollider revient dans mon champ de vision et je me dis que je vais m'y mettre, qu'il a plein de qualités, qu'il va m'ouvrir certaines possibilités, etc. Ah oui au fait, en tant qu'utilisateur avancé de Max/MSP, en quoi ce logiciel peut-il m'intéresser ?

 

 Il suffit d'ouvrir quelques exemples de programmes réalisés dans SuperCollider pour se convaincre du potentiel sonore du logiciel, surtout en matière de synthèse. SuperCollider offre en effet une quantité invraisemblable de générateurs et de filtres qui pourraient déjà m'occuper pour quelques années. Par ailleurs, un aspect séduisant réside dans la concision du langage. En effet, un programme de quelques lignes permet de créer des sons extrêmement originaux, vivants et d'une grande finesse. Un autre point tient dans ce que SuperCollider apparaît comme très efficace dans l'utilisation des ressources de calcul. Il n'est pas sûr que cela se vérifie à tous points de vue mais j'ai pu le vérifier au moins pour une application précise, en l'occurence de la synthèse additive. La synthèse additive implique l'utilisation de nombreux oscillateurs afin de créer des sons riches et évolutifs et en l'occurence SuperCollider m'a permis d'en faire tourner plusieurs centaines sans problème. Etant donné que j'arrive pour l'instant dans les limites de mon ordinateur en ce qui concerne mon dispositif électronique pour le concert, toute perspective de gain de ressources de calcul est à considérer attentivement et ce point est un élément déterminant dans mon envie d'utiliser plus régulièrement SuperCollider.

 

Par ailleurs, SuperCollider utilise le principe client/serveur. L'idée est de séparer le logiciel en deux parties. Le serveur (scsynth) est la partie qui fait tout le travail sonore. Qu'il s'agisse de synthèse, de lecture, d'enregistrement et transformation de sons, tout cela c'est son rayon. L'autre partie c'est le client (sclang). C'est dans le client qu'on code les programmes et c'est le client qui gère l'interface graphique, tant pour les commandes (curseurs, boutons, etc) que pour l'affichage des données (formes d'onde, etc). Le client et le serveur peuvent être sur le même ordinateur ou bien sur deux machines différentes, éventuellement distantes car le client communique avec le serveur par l'intermédiaire du protocole OSC, c'est-à-dire pouvant circuler sur tout réseau IP (Internet ou réseau local). L'utilisation de plusieurs serveurs en parallèle sur un ordinateur ou sur plusieurs est bien sûr possible. En outre, n'importe quel logiciel capable de communiquer en OSC (Pure Data, Processing... ...ou Max/MSP pour n'en citer que quelques-uns) peut communiquer directement avec le serveur et remplacer ou compléter sclang. L'utilisation de l'OSC offre notamment l'avantage d'autoriser la communication de multiples données au serveur et de faire en sorte que toutes soient utilisées simultanément, à un moment fixé dans un futur très proche.

 

Un autre aspect très intéressant tient dans les possibilités génératives de SuperCollider. Plutôt que de créer un générateur, pourquoi en effet ne pas créer un générateur de générateurs ? En effet, SuperCollider peut se "scripter" lui-même, le code peut créer ou modifier un autre code. Les possibilités en ce domaine ont été poussées très loin par Fredrik Olofsson, qui a créé des programmes qui modifient leur propre code avant d'être transformés en son, de même que des programmes qui créent des synths sur base de programmation génétique (une sorte de programmation combinatoire très évoluée). Cela fait longtemps que je veux mettre à profit les principes de la programmation génétique afin de créer des sons sur base de principes sensibles plutôt que techniques et SuperCollider semble à cet égard beaucoup plus adapté que Max/MSP. J'ai bien réalisé quelques patchs Max/MSP plutôt prometteurs incluantn des algorithmes génétiques mais leur réalisation supposait de toutes façons l'inclusion de code sous forme de texte (JavaScript en l'occurence) et le résultat restait assez lourd dans son fonctionnement (quoiqu'avec un grand potentiel sonore). SuperCollider est plus adapté à ce type de création que Max/MSP, il n'y a pas de doute à ce propos.

 

Tout cela est bien joli mais SuperCollider n'a pas que des avantages. Son défaut principal (mais que certains tendant à considérer comme un atout) tient en ce que sa programmation s'effectue par codage de texte. Pour un musicien qui a développé de nombreux outils dans Max/MSP, où la programmation s'effectue graphiquement par interconnexion de modules élémentaires, le passage n'est pas simple. Ayant réalisé un peu de programmation en JavaScript et ayant esquissé quelques tentatives de programmer en langage Java (et sans tenir compte de mes anciennes expériences en Basic sur Commodore 64), je ne suis pas tout à fait sans expérience dans le domaine de la programmation par texte. Mais pour quiconque fonde son travail musical sur des logiciels "clé en mains" tels que Live ou Pro Tools, le passage peut être abrupt, très abrupt. D'ailleurs, je tendrais à déconseiller SuperCollider comme premier "environnement modulaire d'informatique musicale" car avant de créer un premier programme à la fois un tant soi peut utile et personnel, la somme des connaissances à acquérir est franchement rebutante si l'on n'a pas un peu d'expérience et une grande motivation.

 

Tout d'abord, il faut bien comprendre l'organisation client/serveur, sans compter que plusieurs liens sont possibles (serveur intégré à sclang ou séparé). Ensuite, il faut comprendre tant sclang que scsynth. Du côté de sclang, il faut avant tout comprendre les structures de programmation. Ce n'est pas le plus difficile car celles-ci sont semblables à celles de nombreux langages de programmation : déclaration de variables, tests de conditions, boucles d'itération, fonctions, etc. Connaître les différents types de données est déjà un peut plus ardu car sclang donne accès à de multiples types, surtout pour ce qui concerne les données groupées (tableaux, collections, etc). A cet égard, la compréhension des principes inhérents à la programmation dite objet est indispensable, la notion d'héritage étant particulièrement développée dans SuperCollider (rien à voir avec votre vieil oncle sans enfants qui vit en Amérique). Avant d'en arriver à la partie la plus intéressante, il faut se frapper la tête quelques centaines de fois sur le mur de la syntaxe, véritable cauchemar. En effet, la moindre parenthèse non refermée, le moindre point-virgule oublié et c'est la catastophe (bien anodine en réalité car le programme ne se lance pas tout simplement - mais c'est tout de même agaçant quand le programme ne se lance pas pour la trente-septième fois d'affilée). Et puis il faut comprendre pourquoi on place une virgule ici, un tilde là ou des crochets plus loin. Il est clair que dans cet exercice les geeks ont un avantage sur les musiciens. Faudra-t-il " Réveiller le geek qui sommeille en vous " ?

 

On en vient ensuite aux UGens. Les UGens, ce sont les "briques" avec lesquelles on crée ou l'on transforme le son. Tout travail dans SuperCollider implique au moins un Ugen et plus probablement une brouette ou deux. La structure formée par les UGens forme ce qu'on appelle une synthdef, c'est-à-dire un modèle de structure qui est envoyé au serveur. La synthdef peut être mise de côté par le serveur et utilisée plus tard ou bien démarrée immédiatement. De multiples synths peuvent être actifs simultanément et échanger des signaux.

 

L'organisation au sein du serveur repose elle aussi sur quelques notions qu'il faut comprendre (bus, node, groupe). Les bus sont très importants pour l'interconnection des synths entre eux ou avec les entrées/sorties. Et bien sûr la communication du client vers le serveur de même qu'en sens inverse est incontournable.

 

Et puis surtout il faut se faire à l'idée que la place du code est centrale. Par exemple, l'insertion de commandes telles que curseurs ou boutons est loin d'être aussi simple que de simplement faire glisser une icône et tracer un câble. Il faut créer le code qui définit chaque commande et ensuite relier ce code à une autre partie du code, qui va soit utiliser les données de la commande ou modifier son apparence (position d'un curseur, etc). Bref, pour tout musicien qui veut donner une place de choix aux commandes gestuelles et à une représention visuelle efficace des données, rien ne semble donné. Il est clair qu'avec SuperCollider on est plus proche de la "computer music" que de la console de mixage.

 

Tout cela est heureusement facilité par un système d'aide intégré incluant souvent des exemples. Il existe aussi des tutoriels, mais bien sûr tout cela est en anglais (I hope you don't mind).

 

Au-delà de la programmation un peu difficile (mais puissante), j'ai remarqué quelques faiblesses de SuperCollider. Comme le chantait l'autre, "c'est peut-être un détail pour vous", mais en ce qui me concerne, l'impossibilité d'insérer un plug-in de type VST ou Audio Unit dans un programme SuperCollider m'a fait l'effet d'une douche froide. En effet, ce type d'insertion permet de ne pas réinventer la roue quand on a besoin d'un outil standard et bien fait. Pas que je veuille jouer du piano debout mais tout de même cette impossibilité constitue un manque regrettable. Certes SuperCollider permet d'intégrer des plug-ins de type LADPSA, mais hors Linux ce format n'est pas très utilisé. Cela étant, il est au contraire possible de faire fonctionner SuperCollider lui-même comme un plug-in Audio Unit, ou encore en tant qu'objet au sein même de Max/MSP. Une forme de symbiose entre logiciels est donc tout de même possible.

 

Par ailleurs, SuperCollider ne comporte pas de module intégré pour gérer dynamiquement des connexions telle qu'une simple matrice  (à la façon de l'objet matrix~ de Max/MSP). Cet élément, fondamental dans mon dispositif de concert, devrait donc être recréé de toutes pièces si je voulais le tranposer dans SuperCollider.

 

Il y aurait certainement bien d'autres choses à écrire mais c'est déjà pas mal pour un premier tour d'horizon permettant d'entrevoir les atouts et les faiblesses de SuperCollider.

Commentaires

  • 1) (sans titre)

    Auteur: Yvan

    Bonjour. Juste quelques petits ajouts: (je précise que j'ai utilisé Pd et MaxMSP pendant 7 ans, jusqu'à que je découvre SuperCollider qui les a rapidement remplacés en 3 années ;) - il est évident que SuperCollider étant un language, il n'est pas fait pour les gens rebutés par le code. - le fait de pouvoir utiliser sc sour linux est pour moi un atout très important, surtout depuis l'arrivée de Supernova, version "multicore" de scsynth, qui est intégré à SuperCollider. Pour l'instant supernova marche "mieux" sous linux. Si sc3 n'était pas open source, il aurait été beaucoup plus difficile de voir ce genre de choses arriver (le gain de performances avec supernova est assez impressionant). - gérer des connexions comme avec [matrix~] se fait avec Bus notament mais il faut penser différement dans! sc que dans Max pour le routage!

    • 2) (sans titre)

      Auteur: RB

      SCLang n'est en effet pas fait pour les gens rebutés par du code, mais en même temps il est très tentant de l'utiliser, il faut donc en passer par cet aspect.

      Pour le routage, le problème des Bus c'est que leur utilisation basique ne semble pas admettre des boucles de réinjection, ce qui est fondamental si l'on veut un routage souple.

      • 3) (sans titre)

        Auteur: Yvan

        pour pouvoir "réinjecter" il faut utiliser InFeedback ;)

        je conseille aussi les tutoriels de la librairie JITLib/ProxySpace pour des exemples de routages encore plus simples (JITLib est inclue dans le core de sc).

Ajouter un commentaire

 
 
 
 
 
 
 
 

RDBS Comment développé par Robert Deutz Business Solution