Historique du projet 4X de l’Ircam

A la suite d’une demande du compositeur Luciano BERIO, qui souhaitait disposer de « mille oscillateurs numériques en temps réel » pour synthétiser des sons complexes, le physicien Giuseppe DI GIUGNO développa à l’IRCAM , à partir de 1975, plusieurs versions successives de processeurs numériques: 4A, 4B, 4C, pour aboutir en 1981, au très performant processeur 4X (200 Mops).

Ce processeur permettait aussi bien l’analyse que la synthèse en temps réel de signaux sonores (à la norme audio professionnelle ; 16 bits et 20KHz de bande passante).

Pouvant être reconfiguré par logiciel, il permettait la mise en oeuvre de toutes les techniques connues de synthèse et d’un grand nombre de techniques d’analyse du signal.

L’IRCAM a disposé jusqu’au début des années 90, de 4 stations de travail musical 4X, comportant chacune :

• un calculateur de développement UNIX,
• un calculateur temps réel muni de périphériques de contrôle,
• un processeur 4X et son système de convertisseurs numériques/analogiques et analogiques/numériques.

Le système 4X a été utilisé tout au long de son histoire par plusieurs compositeurs dont Pierre BOULEZ qui en fit la première application dans Répons et aussi Clarence BARLOW, Marc BATTIER, François BAYLE, George BENJAMIN, Denis COHEN, Thierry LANCINO, Cort LIPPE, Tod MACHOVER, Philippe MANOURY, Tristan MURAIL, Ichiro NODAIRA, Emmanuel NUNES, Robert ROWE et Karlheinz STOCKHAUSEN.

Brève description du processeur 4X :
Ce système pouvait comporter jusqu’à 8 plaques universelles de traitement du signal « 4U », une carte de contrôle, ainsi qu’une interface avec le calculateur hôte (calculateur temps-réel).

Chaque 4U était programmable individuellement, notamment pour la fréquence d’échantillonnage. Une 4U travaillait en arithmétique virgule fixe sur 16 bits selon des cycles de 60ns et comprenait :

• une unité logique et arithmétique (ALU en anglais),
• un multiplieur MUL,
• ume mémoire de fonction FUN de 64 Kmots de 16 bits,
• une mémoire de données DM 1 Kmots de 24 bits,
• une mémoire d’adresses MA sur 10 bits,
• une mémoire de microcode MMP de 1 Kmots de 48 bits.

La carte de contrôle contenait :

• 256 horloges programmables, capables de déclencher des interruptions sur le calculateur hôte,
• une double mémoire tampon permettant l’enregistrement et la reproduction simultanée de signaux sur le disque dur de l’hôte,
• un arbitrage du bus interne de la 4X,
• la gestion des entrées/sorties.

Un assembleur-optimiseur et un compilateur avaient été développés à l’IRCAM. La programmation se faisait normalement, le parallèlisme n’apparaissant nullement dans le langage et l ‘assembleur pouvait travailler en mode compilé ou interprété.

Ce petit historique du projet 4X vient d’une note d’Olivier Koechlin.

Par la suite, j’ai récupéré un ancien texte (~1981) de Marc Battier où il décrit le fonctionnement des 4n (A, B, C et X) :

Les machines 4A, 4B, 4C, 4X

Des projets où les oscillateurs se comptent par centaines ont été réalisés (machine 4A de Giuseppe Di Giugno, comprenant 256 oscillateurs en temps réel), ou très récemment comme la machine 4X, offrant la faculté de traiter des signaux extérieurs, et capable d’être configurée en banc d’oscillateurs ou de modules quelconques. L’idée qui a d’abord conduit au développement de la machine 4A a été de fournir au musicien la possibilité d’activer et de commander une masse de fréquences simultanées, mais indépendantes, non reliées entre elles par des contraintes de rapports de hauteurs et d’amplitudes fixes. Il s’agit d’un dispositif de synthèse additive, développé autour du multiplexage d’un système numérique de synthèse. Le synthétiseur est piloté par un ordinateur-hôte, un Dec PDP 11. Le nombre virtuel d’oscillateurs dépend de la fréquence d’échantillonnage choisie [Di Giugno, n.d.].

4A

nombre d’oscillateurs	fréquence d’échantillonnage	amplitude
16	256kHz	1024

Une table d’onde, choisie parmi un ensemble conservé sur disque, est chargée dans le synthétiseur en quelques millisecondes. Cette opération peut se réaliser en cours de jeu. Le logiciel de pilotage du synthétiseur a été écrit par DiGiugno, et consiste en un ensemble de courtes routines, réunies dans le programme pepmus. A l’aide d’un code que l’utilisateur entre au clavier alphanumérique du terminal, un Goto calculé permet d’accéder au bloc de commande choisi. Après évaluation des données, le programme envoie ses ordres à un logiciel spécialement chargé du dialogue avec le synthétiseur, 4ASYS, écrit en macro-assembleur pour l’efficacité de la communication. En ce sens, Pepmus serait un programme d’utilisation, et 4ASYS un programme de commande. Le programme utilisateur se borne à passer à 4ASYS les indications du numéro d’oscillateur à modifier, et ses nouvelles valeurs, dans un code interne : la fréquence, l’amplitude et la phase. La structure de Pepmus en blocs indépendants ressemble à un ensemble de sous-programmes : les musiciens peuvent augmenter la bibliothèque commune en y incorporant leurs propres algorithmes. Cette architecture a été choisie afin d’économiser le temps que prend un appel et un retour de sous-programme.
Le musicien qui veut utiliser ses propres procédures a alors le choix d’écrire une sous-routine que Pepmus peut appeler en échange d’un code qu’il faut déterminer dans le Goto calculé ou dans un test sur des valeurs d’entrées, ou bien de placer son bloc d’instructions dans le corps du programme. Nous donnons ici l’exemple d’un tel processus, réalisé pour une brève structure de la pièce récente de York Höller, Resonance. Il s’agit du glissando descendant d’un accord de quatre notes, dont les bornes sont déterminées.
La structure doit durer 35 secondes, après quoi l’état final atteint par le mouvement de l’accord doit rester fixe pendant 1 minute. Cette dernière spécification ne pose aucune difficulté : Le synthétiseur ne s’interrompt que si l’on lui en donne l’ordre, sinon les valeurs des registres de fréquence et d’amplitude sont lus en permanence. Nous avons écrit, avec Jean Holleville, un bloc d’instructions capable de faire varier une fréquence sur un temps déterminé, grâce à une procédure d’interruption écrite par Jean Kott. L’interruption est engendrée par une horloge à fréquence fixe.

Une limite du système vient de la table d’onde.
Celle-ci est d’une longueur de 2k-mots, et le synthétiseur y prélève des échantillons sans effectuer d’interpolation, comme dans la plupart des systèmes temps réel. Cette dimension s’avère trop courte et provoque un bruit de quantification important. Les machines qui lui ont succédé ont en partie remédié à ce problème.

A la suite du synthétiseur 4A fut entreprise une recherche sur un système qui serait plus souple, en offrant le moyen de programmer les ressources de la machine [Alles, DiGiugno 1977]. La machine 4B est attachée à un processeur hôte LSI-11, qui la pilote en lui communicant les valeurs de ses registres. Elle offre 64 oscillateurs, contrôlables séparément, bien qu’il s’agisse là aussi d’un multiplexage, avec une discrimination de fréquence de l’ordre de 0,002 Hz. Les oscillateurs sont modulés en amplitude et en fréquence par des générateurs de rampe, et la fréquence d’échantillonnage est de 32 kHz. Le dispositif offre la possibilité de réaliser des interconnexions entre les oscillateurs, au moyen de 15 registres. La machine a été suffisamment achevée pour permettre à des logiciels d’utilisation de naître, tel que celui que le compositeur Neil Rolnick et Philippe Prevot ont mis au point, le langage SYN4B [Rolnick 1978]. Il permet un jeu interactif en temps réel à partir de périphériques, tels qu’un banc de 4B potentiomètres linéaires, un potentiomètre en X-Y, et une pédale. [Lawson, Mathews 1977] ont consacré un article à la discussion des possibilités musicales simples d’un tel système, et à l’implémentation des modèles de synthèse de J.-C. Risset (synthèse additive) et de J. Chowning (modulation de fréquence). La première méthode offrirait dans ce contexte 4 voix indépendantes, se composant chacune de 16 partiels indépendants, tandis que la seconde pourrait combiner 32 voix de modulation de fréquence. Toutefois, cette conclusion est discutée par [Rolnick 1978, 18]. Cet auteur montre en effet que le moyen le plus rapide d’effectuer des opérations arithmétiques telles que les mises à l’échelle des données d’enveloppe ou de périphériques d’entrées, est de les réaliser dans le synthétiseur même, au moyen des oscillateurs employés comme des multiplicateurs câblés. Cela conduit à réduire considérablement les ressources de la synthèse, et les voix de FM, au sein de ce contexte, se réduisent alors à 8.

Le développement de la machine 4C a été mené à l’Ircam par Giuseppe di Giugno, à la suite du travail sur le modèle expérimental 4B. Les programmes de commande du synthétiseur sont aujourd’hui développés. Il s’agit précisément de livrer aux compositeurs des programmes qui, bien qu’en état de fonctionnement, demandent à être confrontés à des situations en vraie grandeur. Il est clair que la mise en chantier de projets musicaux a pour effet d’enrichir ces programmes qui, pour la plupart, ont été écrits par des programmeurs ayant de sérieuses notions musicales personnelles, et une bonne intuition des désirs et des souhaits des compositeurs.

Les synthétiseurs numériques offrent des moyens d’interagir avec leur fonctionnement, dans le temps même où se déroule la synthèse des sons. Il s’agira, par exemple, de périphériques analogiques, tels que des potentiomètres, ou des bancs de potentiomètres, des commutateurs, un clavier de type piano, ou encore le clavier du terminal, dont les touches enfoncées seront décodées dans le programme et bien entendu des sources provenant d’autres machines analogiques, tels que des démodulateurs d’enveloppes ou d’amplitude, ou tout simplement des microphones et des filtres. Il existe aussi des périphériques numériques pouvant servir à de telles commandes, tels qu’un écran graphique muni d’un crayon lumineux (Light pen), ou une tablette graphique (bit pad). Les informations recueillies sur ces périphériques demandent à être traitées au fur et à mesure de leur saisie. L’un des problèmes soulevés par l’emploi des synthétiseurs numériques en temps réel est que leur accès est réservé à un seul musicien à la fois. Le système d’opération est choisi de telle manière qu’il assure dans les meilleures conditions un dialogue continu et instantané avec le synthétiseur. C’est donc un système d’opération orienté vers les tâches temps réel qui est nécessaire. Par ailleurs, l’interaction qu’on vient d’évoquer, et qui se passe en temps réel, demande bien entendu que pendant la durée de l’échange le système d’opération soit en dialogue avec cette seule tache, c’est-à-dire avec un seul utilisateur. C’est ce qui explique le choix du système RT-11 pour les ordinateurs Dec PDP-11, commandant les 4C, et celui de Unix pour les systèmes les plus récents. Cependant, une large proportion du temps qu’un musicien passe aux cotés d’une machine de ce type est consacré à l’écriture, l’implémentation et le test des programmes de pilotage.
L’évaluation avec le synthétiseur ne prend que peu de temps, et conduit dans les étapes de développement logiciel à revenir au programme, afin d’apporter les corrections. Cette situation a conduit l’équipe de l’université de Stanford a connecter le synthétiseur de Peter Samson comme périphérique d’un système multi-utilisateur. Plusieurs musiciens peuvent travailler simultanément sur la mise au point des programmes de synthèse. C’est seulement une fois compilées que les commandes sont passées à la machine Sambox, qui effectue alors la synthèse en temps réel [Samson 1980]. Ce mode de pilotage interdit pour l’instant l’interaction pendant l’exécution. Le système du SSSP de l’université de Toronto a déjà été mentionné plus haut.
Une équipe de compositeurs et de techniciens a mis au point un système, non seulement de synthèse de sons, mais aussi d’écriture et de modification de partitions. Ce système abondamment décrit [Buxton 1976], met en scène un logiciel compositionnel, destiné à un ordinateur Dec PDP-11, sous le système d’opération Unix, écrit en langage C, qui semble offrir bien des avantages aux musiciens [Abbott 1978], et une configuration de périphériques associant différents modules d’entrée à un synthétiseur numérique.
Là, le système a été pensé pour donner aux musiciens un instrument dont l’accès est orienté vers un type de dialogue dans lequel la machine propose des réponses à leurs sollicitations. La distinction entre les dispositifs et la tache compositionnelle est soigneusement établie. Le musicien doit savoir poser convenablement ses problèmes musicaux, et non tenter de répondre aux contraintes de la machine. Ce sera à elle d’évaluer les propositions du musicien selon sa propre configuration.

Qui dit 4X dit… Matrix 32.

Le système « MATRIX 32 » développé à l’IRCAM dans les années 83-85, par Didier RONCIN et Michel STARKIER, avait pour objectif initial de remplacer le « Hallophone », système allemand utilisé lors des premières executions de Répons de Pierre BOULEZ.

Toutefois, il s’est avéré, de par sa souplesse d’emploi et sa versatilité, qu’ il était à même de résoudre la quasi totalité des problèmes de brassage audio, statique ou dynamique.

« MATRIX32 » était un système analogique commandé numériquement à partir d’un pupitre à base de micro-calculateur VME, ou par un ordinateur via une ligne série. Par la suite, une liaison MIDI a été ajoutée, pour piloter le système.

Deux types de brassage étaient utilisables séparément ou conjointement :

• par commutation à gain programmable de 0 à 100dB par pas de 0,4dB gr‚ce à des modules VCA 8 entrées vers 4 sorties,
• par commutation en tout ou rien, via des modules 8 entrées vers 8 sorties, avec absence totale de bruit de commutation (en présence ou non de signaux) et possibilité de sommer plusieurs signaux d’entrée vers une sortie.

Ces modules pouvaient être associés, pour former des matrices allant jusqu’à 32 par 32 en tout ou rien, ou 32 par 16 en gain contrôlé. Un circuit de moniteur permettait l’écoute et la mesure de toutes ces entrées sorties.

Un logiciel écrit par Andrew GERZSO, offrait les fonctions suivantes :

• édition des fichiers de configuration depuis le pupitre,
• édition des fichiers de configuration conservés en mémoire secourue, sur disque dur ou sur disquette,
• édition des séquences de configuration,
• bibliothèque de fonctions courantes (rampes, sinus, cosinus, exponentielle etc. ) , pouvant être augmentée.

Deux nouveaux liens à propos de la famille 4(n) : le 1er sur le site de l’IRCAM et un l’autre sur le site du Centro di Sonologia Computazionale.