imported>Ali Tebbakh |
imported>Jacques Ducloy |
| (16 révisions intermédiaires par 3 utilisateurs non affichées) |
| Ligne 1 : |
Ligne 1 : |
| − | {{Titre page article|titre=Le patch comme document numérique :support de création et de constitution de connaissances pour les arts de la performance}} | + | {{Titre page article|titre=Les enjeux politiques, scientifiques et techniques de la conception et la réalisation d’une cyberinfrastructure pour les sciences humaines et sociales : l’exemple du projet Synergies}} |
| | | | |
| | {{CIDE boîte bibliographique|texte= | | {{CIDE boîte bibliographique|texte= |
| − | ;Titre:[[A pour titre:: Le patch comme document numérique :support de création et de constitution de connaissances | + | ;Titre:[[A pour titre:: Les enjeux politiques, scientifiques et techniques de la conception et la réalisation d’une cyberinfrastructure pour les sciences humaines et sociales : l’exemple du projet Synergies]] |
| − | pour les arts de la performance]] | + | ;Auteurs:[[A pour premier auteur::Guylaine Beaudry]] . |
| − | ;Auteurs:[[A pour premier auteur:: Alain Bonardi ]], [[A pour auteur:: Jérôme Barthélemy ]]. | + | ;Affiliation:[[A pour affiliation auteur::Université de Montréal]]. |
| − | :: alain.bonardi@ircam.fr
| + | ;In: [[Est dans les actes::CIDE 10 Nancy |CIDE'10]] (Nancy 2007) |
| − | :: jerome.barthelemy@ircam.fr
| + | ;En ligne: http://lodel.irevues.inist.fr/cide/index.php?id=112 |
| − | | |
| − | Affiliation:[[A pour affiliation auteur::Alain Bonardi ]], [[A pour affiliation auteur:: Jérôme Barthélemy]], STMS, Ircam-CNRS, Institut de Recherche et de Coordination Acoustique/Musique 1, place Igor-Stravinsky – 75004 Paris . | |
| − | | |
| − | | |
| − | ;Mots-clés::: patch, création, constitution de connaissances, préservation, authenticité | |
| − | ;Keywords: patch, creation, knowledge building, preservation, authenticity.
| |
| | | | |
| | }} | | }} |
| − | __TOC__
| |
| − | ;Résumé :
| |
| | | | |
| − | : : Dans cet article, nous nous intéressons aux patchs de la musique électronique, qui sont des modules logiciels de traitement sonore. À la fois supports de création et supports de constitution de connaissances, ils sont de véritables documents numériques. Nous montrons qu’ils sont de ce fait soumis aux difficultés de la préservation, problématique qu’il convient d’aborder dans la perspective de l’authenticité de l’exécution d’une œuvre. Nous concluons en décrivant les différentes tâches menées par l’IRCAM dans le cadre du projet européen de préservation Caspar.
| + | {{Clr}} |
| − | {{boîte déroulante | |
| − | |titre=English description
| |
| − | |contenu=
| |
| − | ;Abstract :In this article, we deal with patches in electronic music, that are software modules for sound processing. Both creation and knowledge building support, they are complete digital documents. We show that they are therefore submitted to preservation difficulties. The preservation field must be dealt with in the idea of authenticity when reperforming a work. We conclude with the description of the different tasks led by IRCAM in the framework of the european preservation project named Caspar.
| |
| − | }} | |
| | | | |
| | {{CIDE début corps}} | | {{CIDE début corps}} |
| − | ==Introduction ==
| + | ---- |
| − | Si le traitement de texte sur ordinateur s’est imposé comme usage associant de manière inséparable lecture et écriture, d’autres activités semblent avoir trouvé leurs paradigmes propres, associant envie de création et nécessité de documentation au sens large. Après plusieurs décennies marquées par l’invention d’instruments comme les synthétiseurs, la musique électronique s’est massivement déplacée vers une approche logicielle, notamment par le biais des langages graphiques permettant de construire à la volée des traitements sonores appelés patchs. Nous commencerons par considérer les caractéristiques de ces modules, notamment leur originalité d’écriture, en dehors des catégories musicales et informatiques usuelles ; nous examinerons leur portée dans les arts de la performance. Dans un second temps, nous montrerons en quoi il sont de véritables documents numériques, suscitant la création et permettant la constitution de connaissances. De ce fait, ils sont soumis aux mêmes difficultés que les autres documents numériques, notamment de préservation, et plus précisément de préservation d’une certaine authenticité, car il s’agit d’œuvres. Nous examinerons cette problématique dans la troisième partie. Enfin, nous exposerons la démarche du projet européen Caspar dans le domaine, et plus particulièrement les actions menées par l’IRCAM en son sein.
| |
| − | ==Le patch dans les arts de la performance==
| |
| − | ===Présentation des caractéristiques des patchs===
| |
| − | Les patchs sont des modules logiciels de commande (par exemple de déclenchement et de synchronisation de dispositifs numériques) et de traitement du signal utilisés dans les arts de la performance au sens large, comme la musique, la danse, le théâtre, la vidéo, ou encore les œuvres associant plusieurs arts. Ils reprennent pour la plupart les paradigmes des dispositifs électroniques matériels utilisés sur scène depuis une cinquantaine d’années (exemple : les réverbérations, les processeurs d’effets). Ces patchs tirent leur efficacité et leur importante diffusion de deux propriétés :
| |
| − | *le fonctionnement temps réel : à l’instar des appareils électroniques qu’ils remplacent, les modules fonctionnent en temps réel, fournissant une réponse immédiate aux entrées proposées (le délai de calcul des sorties étant considéré comme négligeable par rapport à l’ordre de grandeur temporel des entrées).
| |
| − | *la construction conviviale des traitements, s’appuyant sur un langage graphique.
| |
| − | À titre d’exemple, nous présentons ci-dessous un module créé avec le logiciel Max/MSP, produisant deux sinusoïdes, à 100 et 200 Hz, et les additionnant, l’amplitude du résultat étant atténuée (multipliée par 0.25). L’aspect du patch fait penser à un montage électrique, comme ceux élaborés sur la paillasse d’un laboratoire de physique, avec des appareils qui sont les modules rectangulaires (exemple de l’objet cycle~ qui produit une sinusoïde, à l’instar d’un générateur) et des câbles, qui sont ici les connections entre objets. Il est extrêmement facile de réaliser ces patchs, sans programmation, simplement en incorporant en quelques clics de souris des objets issus de menus, et en les reliant par des connections.
| |
| − | | |
| − | [[fichier: CIDE 7 Beaudry.png|600px|thumb|center|'''Figure 1''':Exemple de patch produisant la somme de deux sinusoïdes. ]]
| |
| − | | |
| − | Historiquement, ce type d’approche est apparu à la fin des années 1980. À cette époque, des centres de recherche musicale comme l’IRCAM cherchaient des solutions pour enrichir les musiques mixtes, associant musiciens humains et sons électroniques. Jusqu’alors, une bande magnétique accompagnait les instrumentistes, imposant une temporalité figée. Le chercheur Miller Puckette développa alors une première version d’un logiciel intitulé Patcher, qui préfigure les deux logiciels les plus utilisés aujourd’hui : Max/MSP<ref>http://www.cycling74.com</ref> et PureData<ref>/http://crca.ucsd.edu/~msp/software.html</ref> . Le patch marque le début des approches interactives dans lesquelles la machine est « en attente » d’informations venant du musicien (ou du performer au sens large), informations acquises par des capteurs. L’une des premières pièces du répertoire IRCAM à exploiter ces possibilités est Jupiter, de Philippe Manoury (1987), associant une flûte (dotée de capteurs et d’un microphone pour obtenir un certain nombre de paramètres du jeu du flûtiste) à un dispositif d’informatique musicale temps réel. Plusieurs logiciels ont ensuite vu le jour, s’ouvrant au cours des dernières années à la vidéo et à l’image tri-dimensionnelle, comme Isadora<ref>http://www.troikatronix.com/isadora.html</ref> , très utilisé dans le monde de la danse.
| |
| − | | |
| − | ===Exemples d’utilisation de patchs dans les arts de la performance===
| |
| − | Les patchs sont utilisés au sein de très nombreuses œuvres, dans les arts de la performance, faisant intervenir ou non des intervenants humains. Nous donnons dans le tableau ci-dessous quelques exemples, qui ne sont bien entendu pas exhaustifs. Nous pouvons les classifier selon deux dimensions :
| |
| − | *l’importance du traitement temps réel, par exemple du soliste à l’ensemble, du son à l’image ;
| |
| − | *les arts impliqués, allant de la musique instrumentale aux arts de la scène, danse, théâtre, opéra, etc.
| |
| − | | |
| − | [[fichier: CIDE 7 Beaudry2.png|600px|thumb|center]]
| |
| − | ==Le patch comme document numérique==
| |
| − | Nous allons montrer ici que les patchs ont acquis un véritable statut de document électronique dans le domaine des arts de la performance. Ils offrent, selon des modalités particulières, des possibilités de création et de constitution de connaissances.
| |
| − | ===Le patch comme support de création===
| |
| − | Le succès des différents logiciels permettant la réalisation de patchs s’inscrit dans le double mouvement d’expansion de la musique électronique, essentiellement à domicile dans le cadre de home studios, et des arts de la performance, dans de nombreux lieux, institutionnels ou « underground ».
| |
| − | | |
| − | Une partie de cette évolution est à mettre au crédit du mode de travail que proposent les patchs. Ce sont en effet des supports de création originaux, échappant à la fois à la programmation informatique usuelle et aux catégories de la musicologie :
| |
| − | *d’une part, du point de vue informatique, il n’y a plus de code à écrire, modifier et compiler, mais un dispositif à façonner de manière interactive : l’utilisateur adapte les objets utilisés, les connexions et les paramètres des patchs jusqu’à ce qu’il obtienne un résultat satisfaisant. La modification du patch se fait très souvent en observant ou en écoutant les contenus produits : ainsi, un patch transformant des sons, sera ajusté le plus souvent à l’oreille, puisque le patch continue à fonctionner lors de son édition.
| |
| − | *d’autre part, du point de vue musical, l’approche est assez empirique, et de ce fait correspond aux modalités traditionnelles des processus de l’écriture musicale. Précisons notre propos : nous ne voulons pas parler de la qualité du résultat sonore, qui peut tout à fait être musical. Il s’agit du mode de production et de travail, qui s’apparente à un affinage permanent, par retouche du patch. Même un utilisateur familier des possibilités de traitement du signal, ayant une idée claire du résultat à obtenir, procède ainsi : car tout ensemble de transformations sonores possède des paramètres qu’il convient de régler finement à l’oreille, et que l’on ne peut déterminer en amont de son implémentation, de manière abstraite. Toutefois, le patch s’appuie sur un ensemble de catégories qui ne font pas partie des catégories traditionnelles musicales (la hauteur, le rythme…), mais sur des catégories issues des sciences ou de l’ingénierie (la sinusoïde, les opérations mathématiques…) ; de ce fait la démarche créative du compositeur est perturbée, et devient plus dépendante du système technique utilisé dans la mesure où ces catégories ne font pas partie du bagage traditionnel du musicien.
| |
| − | Sur les deux plans de la programmation informatique et de la composition musicale, les patchs sont des dispositifs interactifs, auxquels l’utilisateur ne cesse de revenir par affinage continu. Cette absence de formalisme encourage donc la créativité d’utilisateurs non nécessairement « spécialistes ». Elle a comme contrepartie le caractère assez « brouillon » des patchs, et une certaine absence de ductilité musicale : il est plus difficile d’obtenir exactement ce que l’on veut, par rapport à l’écriture musicale traditionnelle.
| |
| − | ===Le patch comme support de constitution de connaissances===
| |
| − | Mais les patchs portent également des informations sur la conception musicale et technique d’une œuvre musicale, valorisables sous forme de connaissances, aussi bien pour les musicologues, les documentalistes de médiathèques que les utilisateurs des logiciels concernés.
| |
| − | | |
| − | Pendant les années 1997-2000, un certain nombre de musicologues [{{CIDE lien citation|5}}] ont collaboré avec le département Pédagogie et la Médiathèque de l’IRCAM pour établir des documentations hypermédia d’œuvres mixtes, fondées pour partie sur l’analyse des patchs Max/MSP mis en œuvre. Il s’agissait de mettre en perspective musicale les fonctionnalités développées par les patchs. Un module comme l’harmonizer (dispositif permettant de transposer un signal provenant d’un instrumentiste) est utilisé de manière variée par les différents compositeurs, à l’instar d’un instrument traditionnel, qui offre des modalités de création multiples : par exemple, l’utilisation de la harpe varie considérablement, entre les approches de Debussy, Berlioz, Ravel ou Mahler. L’un des objectifs de ces documentations était d’établir la spécificité musicale de l’emploi de tel ou tel module par tel ou tel compositeur.
| |
| − | | |
| − | Dans cette veine musicologique, en disposant d’outils de suivi des versions de patchs, il serait possible d’établir une archéologie des productions musicales faisant appel à l’électronique. Nous y reviendrons lors de la présentation du projet Caspar un peu plus loin dans cet article.
| |
| − | | |
| − | Enfin, pour les créateurs eux-mêmes, une structuration des patchs permet leur réutilisation, en les considérant comme les briques d’un savoir-faire pratique associant musique et traitement du signal : de nombreux compositeurs ordonnent ainsi leurs patchs en répertoires ordonnés par grandes fonctionnalités, allant des modules de base aux patchs les assemblant.
| |
| − | ==La pérennité incertaine des patchs==
| |
| − | Le patch est confronté aux problématiques que rencontrent tous les documents numériques, par exemple les difficultés de préservation, de gestion des versions ou d’indexation. Dans le cas des arts de la performance, la première nécessité est la pérennité de l’œuvre, c’est-à-dire la capacité de pouvoir la remonter, la rejouer plusieurs années après sa création. Suite à des difficultés rencontrées sur des cas particuliers, les centres de création ont récemment pris conscience de la nécessité de travailler sur cette question.
| |
| − | ===Facteurs d’obsolescence===
| |
| − | Les œuvres des arts de la performance faisant appel à l’électronique sont fragiles, en raison de plusieurs facteurs :
| |
| − | *L’usure des supports de stockage : les CD, CD-ROM, clés USB, disques durs, cassettes DAT, etc., sont des moyens de stockage relativement fragiles.
| |
| − | | |
| − | *L’obsolescence des standards techniques : les utilisateurs finaux créant et maintenant des patchs sur des logiciels propriétaires (dont les fichiers sont encodés selon des formats binaires) ou demandant des technologies propriétaires, sont particulièrement concernés par la notion d’obsolescence.
| |
| − | | |
| − | *L’absence de soin dans la préservation des parties électroniques des œuvres : depuis plusieurs siècles, les bibliothèques conservent des partitions, mais lorsque la musique électronique est née, les compositeurs ont été tout d’abord considérés comme responsables de la préservation des parties électroniques. Hannah Bosma [BOSMA 2005] décrit ce phénomène dans le cadre de l’institution Donemus/Near aux Pays-Bas. L’enquête de « terrain » de Michael Longton [{{CIDE lien citation|9}}] intitulée « Record Keeping Practices of Composer » chiffre à 47 % la proportion de compositeurs estimant avoir perdu des fichiers importants de leur création, en raison de l’obsolescence logicielle et matérielle.
| |
| − | | |
| − | *Les conditions pratiques de la performance : changer les conditions de performance peut provoquer des résultats inattendus. Par exemple, jouer avec des dispositifs légèrement différents de ceux de la création ou dans des lieux non prévus au départ nécessite un temps additionnel de test et exige souvent des modifications de patchs.
| |
| − | | |
| − | *La confection souvent empirique des patchs : la complexité des patchs les rend parfois très instables. Par exemple, dans le logiciel Max/MSP, il est connu que le traitement des priorités dépend de la position des objets dans la fenêtre du patch. De ce fait, déplacer un objet dans un patch peut produire d’importantes modifications du résultat produit. Nous donnons ci-dessous un exemple de la complexité inhérente à ces modules, sous la forme d’un patch réalisé par Olivier Pasquet, assistant musical à l’IRCAM.
| |
| − | | |
| − | [[fichier:CIDE 7 Beaudry3.jpg|600px|thumb|center|'''Figure 2''':Exemple de patch complexe par Olivier Pasquet]]
| |
| − | | |
| − | ===Les grands types d’actions de maintenance des patchs===
| |
| − | ====Objectifs====
| |
| − | L’objectif principal de la maintenance des patchs est de permettre la recréation d’une œuvre. Une des particularités des arts de la performance est la difficulté à décrire tous les paramètres en entrée des systèmes mis en jeu (en effet, ces entrées sont précisément suffisamment ouvertes pour permettre des actions variées de la part des personnes qui interagissent avec le système) : il n’est donc pas possible – ni même souhaitable – de garantir une parfaite identité du résultat. Toutefois, il est nécessaire de garantir un certain respect de l’intention initiale, ce que généralement on s’accorde à identifier sous le vocable d’authenticité. Cet impératif doit être gardé à l’esprit lors de toutes les opérations de maintenance des patchs, et notamment celles qui visent à le réimplémenter.
| |
| − | | |
| − | L’authenticité de la production musicale occidentale a été garantie depuis le Moyen-Age à l’aide d’un système de notation assurant une grande pérennité aux œuvres, en mettant en avant des catégories efficaces et stables comme la hauteur, la durée, ou la famille instrumentale : si un instrument disparaît lors d’évolutions historiques, le système assure que l’œuvre reste jouable dans son esprit. Par exemple, la Sonate pour Arpeggione de Schubert est maintenant jouée couramment sur violoncelle, malgré de grandes différences entre l’instrument original et celui employé aujourd’hui. De plus, cette codification s’est avérée suffisamment souple pour être étendue en fonction des évolutions stylistiques ou faire face à de nouvelles conceptions, à un goût nouveau<ref>Par exemple, les nouvelles manières de jouer la musique baroque et ancienne introduites à partir des années 1960.</ref> , et faire face à de nouveaux besoins de notation. Certains arts de la performance s’en sont même inspiré, comme la danse avec les notations de Laban et Benesz.
| |
| − | | |
| − | Mais, de nos jours, la situation a évolué, car la musique électronique utilise d’autres paradigmes de prescription qui ne sont plus liés aux catégories musicales habituelles. De plus, les modèles de la musique électronique sont divers et locaux, adaptés à tel ou tel besoin, et très fortement dépendants du système technique sous-jacent. Il n’existe pas de modèle d’ensemble du traitement électronique, qui permettrait de substituer un « instrument » à un autre en cas d’obsolescence. Ce qui suscite une vaste question : comment considérer que les résultats d’une nouvelle implémentation d’un traitement numérique sont conformes aux intentions originales du compositeur ? L’expérience à l’IRCAM de migrations pour des raisons techniques montre que les compositeurs réagissent de manière variée au même type d’action : certains trouvent le nouveau résultat trop « proche » de l’ancien (et du coup ne tirant pas assez parti des nouvelles technologies mises en œuvre) ; d’autres le trouvent trop éloigné, n’ayant pas assez à voir avec l’original.
| |
| − | ====Classification des actions de maintenance====
| |
| − | Ces actions peuvent être classées selon la typologie suivante :
| |
| − | | |
| − | *Préservation
| |
| − | *Émulation
| |
| − | *Migration
| |
| − | *Virtualisation
| |
| − | | |
| − | Nous présentons maintenant chacun de ces types.
| |
| − | ====Préservation====
| |
| − | Alors que la préservation des manuscrits de partitions anciennes est largement répandue depuis plusieurs décennies, la préservation des arts de la performance fait l’objet de travaux et de recherches depuis quelques années seulement [{{CIDE lien citation|3}}] [{{CIDE lien citation|13}}][{{CIDE lien citation|14}}][{{CIDE lien citation|15}}] . L’initiative de recherche Mustica[{{CIDE lien citation|1}}] (« Mustica Research Initiative »), projet international conduit et coordonné par l’université de technologie de Compiègne, a suscité une collaboration sur la problématique de la préservation de la musique contemporaine entre deux institutions spécialisées : l’Institut de Recherche et de Coordination Acoustique/Musique – IRCAM – et le Groupe de Recherches Musicales à l’Institut National de l’Audiovisuel – INA.
| |
| − | | |
| − | Le projet a notamment permis de produire une base de données ouverte aux organismes et personnes souhaitant remonter des œuvres contemporaines : en octobre 2006, elle contenait 54 références d’œuvres produites à l’IRCAM. Nous présentons ci-dessous une copie d’écran relative à l’œuvre Jupiter de Philippe Manoury, pour flûte et électronique.
| |
| − | | |
| − | [[fichier: CIDE 7 Beaudry4.png|600px|thumb|center|'''Figure 3''':Une copie d’écran de la page de Jupiter dans la base de données Mustica. ]]
| |
| − | | |
| − | La base donne accès à plusieurs sources d’information au sujet de l’œuvre :
| |
| | | | |
| − | *La documentation de l’œuvre : le patch principal, l’implémentation des haut-parleurs, le schéma audio-MIDI (certains de ces éléments sont reproduits ci-dessous).
| + | [[File:CIDE 10Beaudry diapo1.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo2.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo3.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo4.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo5.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo6.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo7.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo8.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo9.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo10.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo11.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo12.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo13.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo14.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo15.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo16.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo17.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo18.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo19.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo20.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo21.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo22.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo23.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo24.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo25.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo26.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo27.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo28.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo29.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo30.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo31.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo32.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo33.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo34.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo35.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo35.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo35.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo35.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo35.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo36.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo37.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo38.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo39.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo40.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo41.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo42.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo43.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo44.jpg|600px|thumb|center]] |
| | + | [[File: CIDE 10Beaudry diapo45.jpg|600px|thumb|center]] |
| | | | |
| − | [[fichier: CIDE 7 Beaudry5.png|600px|thumb|center|'''Figure 4''':Une copie d’écran du patch principal de Jupiter de Philippe Manoury (assistant musical : Serge Lemouton).]]
| |
| − |
| |
| − | [[fichier: CIDE 7 Beaudry6.png|600px|thumb|center|'''Figure 5''':L’implémentation des sources sonores dans Jupiter, de Manoury ]]
| |
| − |
| |
| − | *Des extraits sonores, le plus souvent au format MP3.
| |
| − | *L’accès aux pages BRAHMS<ref>BRAHMS est une base de données en ligne des compositeurs du XXe siècle et de leurs œuvres.</ref> concernant Manoury et Jupiter.
| |
| − | *L’accès à l’achat du CD et des ouvrages concernant le compositeur et l’œuvre.
| |
| − |
| |
| − | ====Émulation====
| |
| − | L’émulation est certainement l’une des approches les plus difficiles techniquement et les plus coûteuses en temps de travail pour pouvoir rejouer une œuvre. Bernardini et Vidolin [{{CIDE lien citation|2}}] citent l’exemple de l’œuvre Oktophonie de Stockhausen, qui nécessite un ordinateur personnel ATARI-1040 ST : ce dernier a disparu du marché depuis bien longtemps. Il existe des émulateurs Atari tournant sur des ordinateurs actuels, mais personne ne sait si le programme Notator utilisé par Stockhausen pourra fonctionner sur un émulateur, bien que les communautés d’utilisateurs puissent fournir une certaine aide. Et les auteurs de mettre en avant « le pouvoir des communautés, à l’opposé du manque de fiabilité des entreprises ».
| |
| − |
| |
| − | L’émulation de dispositifs matériels par des logiciels est également difficile. Bullock et Coccioli [{{CIDE lien citation|6}}] fournissent l’exemple intéressant de l’œuvre Madonna of winter and spring du compositeur anglais Jonathan Harvey, écrite pour grand orchestre et trois synthétiseurs, dont un modèle Yamaha TX816 pour la synthèse sonore, qui n’existe plus. Les auteurs, en charge de l’émulation, prévoient de tenter de le remplacer par des patchs réalisés avec le logiciel PureData, en s’attendant toutefois à des différences de résultat sonore.
| |
| − |
| |
| − | ====Migration====
| |
| − | L’activité de migration est la plus répandue lorsque l’on remonte des œuvres. De nombreux compositeurs ont eu leurs œuvres portées d’un environnement technique à un autre. Toutes les institutions dans le champ des arts électroniques font face à des nécessités de migration. À l’IRCAM, les pièces importantes utilisant des ordinateurs Next ont été migrées vers des ordinateurs Macintosh à la fin des années 1990.
| |
| − |
| |
| − | La migration, en général motivée par des raisons techniques, peut également être perçue comme un appel à re-création pour le compositeur. Le compositeur et théoricien Jean-Claude Risset [{{CIDE lien citation|12}}] a créé une nouvelle œuvre, Resonant Sound Spaces, avec l’aide d’Antonio de Sousa Dias, Daniel Arfib, Denis Lorrain et Laurent Pottier, qui avaient formalisé informatiquement certains aspects de ses œuvres précédentes. Le travail de Sousa Dias [{{CIDE lien citation|7}}] a été fondamental pour Risset, tout particulièrement sa programmation de structures harmoniques avec des outils temps réel.
| |
| − |
| |
| − | Au cours des dernières années, les migrations ont essayé d’éviter les solutions propriétaires. Bullock et Coccioli [{{CIDE lien citation|6}}], et Miller Puckette [{{CIDE lien citation|11}}] ont mis l’accent sur la nécessité de standards et de formats ouverts pour sauvegarder tous les fichiers impliqués dans un processus de création. Ils recommandent par exemple de sauvegarder les patchs produits dans Max/MSP au format texte ASCII plutôt qu’en binaire, certes plus rapide à charger ; de même, toute la documentation devrait être écrite en format « text » ; enfin, les contenus sonores devraient être sauvegardés sous un format de fichier WAV de base.
| |
| − |
| |
| − | ====Virtualisation====
| |
| − | La virtualisation désigne l’activité de description de modules électroniques en utilisant des abstractions. À l’IRCAM, Andrew Gerzso a accompli un important travail de recherche de représentations aussi indépendantes que possible d’une implémentation technique, dans le cadre de l’œuvre Anthèmes 2 de Pierre Boulez, pour violon et électronique temps réel. Son travail concerne la partition aussi bien que la documentation technique, publiées toutes deux par les éditions Universal.
| |
| − | Il a appliqué cette approche d’abstraction à trois types de modules électroniques :
| |
| − |
| |
| − | *Des modules de traitement du son : Gerzso prend en considération des modules standard, considérés comme connus et décrits de manière univoque en traitement du signal. Par exemple : les « frequency shifters », les filtres en peigne, les modulateurs en anneau.
| |
| − |
| |
| − | *Les modules de spatialisation : avec l’aide d’Olivier Warusfel (qui dirige l’équipe « Acoustique des salles » à l’IRCAM), Gerzso a identifié des descripteurs de spatialisation, dont les valeurs numériques peuvent être obtenues à partir des patchs actuels. Exemples de descripteurs : la direction de la source sonore, le niveau de source directe, le niveau des premières réflexions.
| |
| − |
| |
| − | *Les modules de suivi de partition : rien n’est précisé dans la documentation de Gerzso, si ce n’est ce que le module devrait être capable de faire.
| |
| − | [[fichier: CIDE 7 Beaudry7.jpg|600px|thumb|center|'''Figure 6''':La partition du début d’Anthèmes 2 de Pierre Boulez, pour violon et électronique temps réel.Avec l’aimable autorisation des Éditions Universal, Vienne. ]]
| |
| − |
| |
| − | Les modules ont été ajoutés à la partition, comme parties, exactement comme s’il s’agissait de parties instrumentales. Sous la ligne du violon, la première partie électronique indiquée est la réverbération infinie (notée Inf. Rev. ou IR). La deuxième partie est consacrée au « Sampler IR », c’est-à-dire un échantillonneur doté d’une réverbération infinie. La troisième est un « Sampler » ou échantillonneur simple, sans réverbération. Chacune de ces parties est complétée d’une ligne indiquant les effets de spatialisation associés. La dernière ligne est celle du « frequency shifter ». Le « suiveur de partition », dans cette partition, a un rôle de chef d’orchestre : il doit déclencher des événements au bon moment, ces derniers étant notés par des numéros entourés d’un cercle. Comme on pourra le remarquer, chaque partie est notée en utilisant des paradigmes classiques de la musique, à savoir, des pentagrammes, des notes, des mesures, et d’autres symboles, aussi proches que possible de la notation musicale traditionnelle.
| |
| − |
| |
| − | Toute personne capable de lire la musique et habituée à suivre des exécutions musicales devrait être capable de lire cette partition et de se donner une idée du résultat attendu, sans avoir aucune précision sur l’implémentation technique nécessaire.
| |
| − |
| |
| − | [[fichier: CIDE 7 Beaudry8.png|600px|thumb|center|'''Figure 7''':Le schéma symbolique du début d’Anthèmes 2 de Pierre Boulez,
| |
| − | pour violon et électronique temps réel, réalisé par Andrew Gerzso.
| |
| − | Avec l’aimable autorisation des Éditions Universal, Vienne, Autriche. ]]
| |
| − |
| |
| − | Au Grame à Lyon, Yann Orlarey et son équipe de recherche [{{CIDE lien citation|8}}] [{{CIDE lien citation|10}}] ont exploré d’autres types de formalismes, en utilisant l’algèbre pour spécifier des langages de diagrammes de bloc. Ceci les a conduits au système Faust, qui permet la description mathématique de fonction de traitement de signal, jusqu’à la compilation des modules correspondants en C++. Ci-dessous l’exemple d’une description d’une réverbération.
| |
| − |
| |
| − | [[fichier: CIDE 7 Beaudry9.jpg|600px|thumb|center|'''Figure 8''':Une copie d’écran d’une réverbération utilisant le système Faust]]
| |
| − |
| |
| − | D’autres équipes ont étudié la génération automatique de patchs Max/MSP. Paolo Bottoni et ses collègues de l’Université de Rome La Sapienza [Bottoni & al. 2006] se sont penchés sur l’utilisation d’agents planificateurs pour transformer des buts abstraits spécifiés par le performer en séquences potentiellement complexes de messages de contrôle Max/MSP, grâce à un langage de programmation appelé GO/Max.
| |
| − |
| |
| − | ==Les pistes de travail du projet européen Caspar==
| |
| − | Le projet européen Caspar (Cultural, Artistic, and Scientific Knowledge for Preservation, Access and Retrieval) a été lancé en 2006, réunissant 17 partenaires, parmi lesquels l’IRCAM. La thématique générale est la préservation des données numériques. Ce projet a l’intention de s’adresser à trois communautés différentes, en développant trois jeux de tests différents : un pour la connaissance scientifique, un pour l’héritage culturel et un pour les arts de la performance.
| |
| − |
| |
| − | La préservation de l’authenticité nécessite un cadre de travail commun qui répondra aux besoins des différentes communautés impliquées dans le projet. L’hypothèse fondamentale en ce qui concerne les arts de la performance est qu’une ontologie précise du processus de création devrait permettre de préserver les données concernées : un effort particulier est fait pour participer au standard ISO 21127 :2006 CIDOC CRM pour traiter les données des arts de la performance, afin de préserver l’histoire d’une création et l’authenticité de l’exécution. Toutefois, la préservation seule n’est pas suffisante pour garantir l’authenticité.
| |
| − |
| |
| − | A l’IRCAM, nous avons commencé à travailler sur l’archéologie des processus de production. Ce qui veut dire être capable d’enregistrer, de documenter et de classifier les différentes phases de production d’œuvres mixtes combinant performers humains et dispositifs électroniques. Plusieurs actions sont menées :
| |
| − |
| |
| − | *Enregistrement et annotation de sessions musicales avec des compositeurs et des musiciens. Par exemple, la création du quatuor de la compositrice Florence Baschet, pour instruments à cordes augmentés.
| |
| − |
| |
| − | *Modélisation du travail de production et de la gestion des versions des œuvres, en utilisant des ontologies.
| |
| − |
| |
| − | *Parsing des patchs et modules électroniques utilisés par les compositeurs, pour être capable de les décrire et de les comparer.
| |
| − | Ces efforts de recherche devraient converger vers une approche de la mesure de l’authenticité en musique électronique.
| |
| − | ==Conclusion==
| |
| − | Nous avons montré comment le patch est devenu un document-clé de la musique électronique : ce document est la trace d’une activité créatrice, et vise à traduire une certaine forme de pensée musicale. Il est même la seule trace exploitable par les générations futures de l’interaction du créateur avec la technologie électronique.
| |
| − |
| |
| − | Ce document a ses propres spécificités qui le rendent difficilement déchiffrable, pour deux raisons majeures : d’une part il est dépendant du système technique sous-jacent, et d’autre part il repose sur un système de catégories non musicales, alors même qu’il est censé traduire une pensée musicale. Il convient donc de développer les outils et les méthodes qui permettent de le rendre indépendant d’un système technique, et de développer les catégories spécifiques qui permettront de traduire et de repenser en termes musicaux les concepts techniques utilisés.
| |
| − |
| |
| − | Le rôle de l’IRCAM dans le projet européen Caspar est de cerner au mieux les pratiques de création et d’émergence d’un répertoire. Il le fait notamment en développant des outils et des méthodes d’analyse et de décryptage des patchs, qui devraient contribuer à assurer la pérennité d’une musique « jeune », née il y a environ quarante ans, mais déjà soumise à la crainte de la disparition de certaines de ses pièces essentielles, par obsolescence des solutions techniques mises en œuvre.
| |
| − |
| |
| − | ==Remerciements==
| |
| − | Ce travail est soutenu par le projet CASPAR, co-financé par la Communauté Européenne dans le sixième Programme-Cadre (Priorité IST-2005-2.5.10, « Accès et préservation des données culturelles et scientifiques »).
| |
| − | Site web du projet : www.casarpreserves.eu
| |
| − |
| |
| − | Nous remercions Guillaume Boutard, Serge Lemouton, Denis Lorrain, Philippe Manoury et Andrew Gerzso.
| |
| − | ==Notes==
| |
| − | <references/>
| |
| | | | |
| | + | {{CIDE fin corps}} |
| | + | [[Catégorie:Article de conférence]] |
| | + | {{CIDE article terminé}} |
| | + | [[Catégorie:Cyberinfrastructure]] |
| | __SHOWFACTBOX__ | | __SHOWFACTBOX__ |
| − |
| |
| − | ==Références bibliographiques==
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=1
| |
| − | |auteur=Bruno Bachimon{{!}}B. Bachimont
| |
| − | |auteur 2=Jean-François Blanchette{{!}}J.-F. Blanchette
| |
| − | |auteur 3=Andrew Gerzso,{{!}}A. Gerszo
| |
| − | |auteur 4=Anne Gillilant-Swetland{{!}}A. Swetland
| |
| − | |auteur 5=. Olivier Lescurieux{{!}}O. Lescurieux
| |
| − | |auteur 6=Pierre Morizet-Mahoudeaux{{!}}P. Mahoudeaux
| |
| − | |auteur 7=Nicolas Donin{{!}}N. Donin
| |
| − | |auteur 8=Jill Teasley{{!}}J. Teasley
| |
| − | |texte="Preserving Interactive Digital Music : A report on the Mustica Research Initiative. In Proceedings of the Third International Conference on WEB Delivering of Music (WEB’03), Leeds, England, 2003."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=2
| |
| − | |auteur=Nicola Bernardini{{!}}N. Bernardini
| |
| − | |auteur 2=Alvise Vidolin{{!}}A. Vidolin
| |
| − | |texte="Sustainable Live Electro-acoustic Music. In Proceedings of the International Sound and Music Computing Conference, Salerno, Italy, 2005."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=3
| |
| − | |auteur= Hannah Bosma{{!}}H. Bosma
| |
| − | |texte="Documentation and Publication of Electroacoustic Compositions at NEAR. In Proceedings of the Electroacoustic Music Studies Network International Conference (EMS 05), Montreal, Canada, 2005."
| |
| − | }}
| |
| − | {{CIDE biblio
| |
| − | |id=4
| |
| − | |auteur=Paolo Bottoni{{!}}P. Bottoni
| |
| − | |auteur 2=Stefano Farall{{!}}S. Faralli
| |
| − | |auteur 3=Anna Labella{{!}}A. Labella
| |
| − | |auteur 4=Mario Pierro{{!}}M. Pierro
| |
| − | |texte="Mapping with planning agents in the Max/MSP environment: the GO/Max language. In Proceedings of the 2006 International Conference on New Interfaces for Musical Expression, Paris, France, 2006."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=5
| |
| − | |auteur=Alain Bonardi{{!}}A. Bonardi
| |
| − | |auteur 2=Marie-Hélène Serra{{!}}M.-H. Serra
| |
| − | |auteur 3=Michel Fingerhut{{!}}M. Fingerhut
| |
| − | |texte="Documentation musicale et outils hypermédias, Deuxième Colloque International sur le Document Electronique : CIDE’99, Damas (Syrie), 5-7 juillet 1999, actes du colloque (édités par Europia Productions, Paris), pages 295-309."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=6
| |
| − | |auteur=Jamie Bullock{{!}}J. Bullock
| |
| − | |auteur 2=Lamberto Coccioli{{!}}L. Coccioli
| |
| − | |texte="Modernising Live Electronics Technology in the Works of Jonathan Harvey. In Proceedings of the International Computer Music Conference, Barcelona, Spain, 2005."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=7
| |
| − | |auteur=António de Sousa Dias{{!}}A. de Sousa Dias
| |
| − | |texte="Transcription de fichiers MusicV vers Csound au travers de Open Music. In Proceedings of the tenth Journées d'Informatique Musicale, AFIM, Montbéliard, 2003."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=8
| |
| − | |auteur=Albert Gräf {{!}}A. Graef
| |
| − | |auteur 2=Stefan Kersten{{!}} S. Kersten
| |
| − | |auteur 3=Yann Orlarey{{!}}Y. Orlarey
| |
| − | |texte="DSP Programming with Faust, Q and SuperCollider. In Proceedings of Linux Audio Conference 2006, Karlsruhe, Allemagne, 2006."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=9
| |
| − | |auteur=Michael Longton{{!}}M. Longton
| |
| − | |texte="Record Keeping Practices of Composers, a survey (revised in 2004). InterPares 2 Website, à l’adresse http://www.interpares.org."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=10
| |
| − | |auteur=Yann Orlarey{{!}}Y. Orlarey
| |
| − | |auteur 2=Dominique Fober{{!}}D. Fober
| |
| − | |auteur 3=Stéphane Letz{{!}}S. Letz
| |
| − | |texte="An Algebra for Block Diagram Languages. In Proceedings of International Computer Music Conference ICMA 2002, Göteborg, Sweden, 2002."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=11
| |
| − | |auteur=Miller Puckette{{!}}M. Puckette
| |
| − | |texte="New Public-Domain Realizations of Standard Pieces for Instruments and Live Electronics. In Proceedings of the International Computer Music Conference, Miami, 2004."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=12
| |
| − | |auteur=Jean-Claude Risse{{!}}J.-C., Risset
| |
| − | |auteur 2=Daniel Arfib{{!}}D. Arfib
| |
| − | |auteur 3= António de Sousa Dias{{!}} A. De Sousa Dias
| |
| − | |auteur 4=Denis Lorrain{{!}} D. Lorrain
| |
| − | |auteur 5=Laurent Pottier{{!}} L. Pottier
| |
| − | |texte="De Inharmonique à Resonant Sound Spaces. In Proceedings of the Journées d'Informatique Musicale, AFIM, Marseille, Gmem, 2002."
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=13
| |
| − | |auteur=John Roeder{{!}}J. Roeder
| |
| − | |texte="Preserving Authentic Electroacoustic Music: the InterPARES Project. In Proceedings of the IAML-IASA Congress 2006, Oslo, Norway, 2006.".
| |
| − | }}
| |
| − |
| |
| − | {{CIDE biblio
| |
| − | |id=14
| |
| − | |auteur=Daniel Teruggi{{!}}D. Teruggi
| |
| − | |texte="Preserving and Diffusing. Journal of New Music Research, vol. 30, n. 4, 2001."
| |
| − | }}
| |
| − | {{CIDE biblio
| |
| − | |id=15
| |
| − | |auteur=Vincent Tiffon{{!}}V. Tiffon
| |
| − | |texte="Les musique mixtes : entre pérennité et obsolescence. Revue Musurgia, XII/3, Paris, 2005.".
| |
| − | }}
| |
| − |
| |
| − |
| |
| − |
| |
| − | .
| |
