Page  1 ï~~OUR RESEARCH FOR LOST ROUTE TO ROOT Jer6me Barthelemy, Alain Bonardi, Guillaume Boutard, Raffaele Ciavarella IRCAM - Institut de Recherche et de Coordination Acoustique/Musique, Paris, FR {jerome.barthelemy, alain.bonardi, guillaume.boutard, raffaele.ciavarella}@ircam.fr Alexander Mikroyannidis, Bee Ong, Kia Ng ICSRiM - University of Leeds, Schools of Music & Computing, Leeds LS2 JT, UK {alex, bee, kia} @icsrim.org.uk ABSTRACT In contemporary arts many non conventional instruments, devices and technologies are used, as well as many new ways of man-machine interaction, to produce new artistic works. When introducing electroacoustics, artists did not realize the risk of not being able to re-perform their works just a few years later. In the framework of the CASPAR European project, the On Line Services team at IRCAM proposes first results of the research, conducted together with the ICSRiM team at the University of Leeds, for trying to save artistic works from obsolescence and to support future developments. 1. INTRODUCTION 1.1. The root During centuries music was written on paper and a little part of what needed to re-perform the author's intention was outside that paper. Many kinds of performances, like jazz or folk, are more styles than coded music. This lets us consider that also social and cultural environments, in which music is produced, have to be studied in order to keep safe the tie to its origin. In this case, re-performance possibilities are not crucial for the purpose of preservation and recordings, together with social environment trackings, can fully satisfy the need for documentation [1]. At about the middle of the last century a new era for arts, and especially for music, started. Many experiments were done on the structure of the sound and time, and really new possibilities were offered to arts. Due to the rapid growth of technologies, electronic devices became affordable and available not only in specialized structures but even to home end-user. Computer and software permitted all people to have high quality virtual instruments as well as completely new ones. The use of hardware and especially software devices introduced a great degree of freedom for composers and artists, but the price paid was the very short life time of those devices and the wide spread of used solutions. Considering electronics as musical instruments and modeling an interaction with human in artistic works, a new paradigm of notation was also required. While in traditional notation the meaning was written and final effect was coded in the score, for complex contemporary works there is no adequate notation and the only saved data are the specific way used to obtain the result (the process itself) but not the intentions. Because of the very quick changes in technology and market devices, now we live also a paradoxical situation: electro-acoustic works, that are very recent, are facing serious problems [2] not present in traditional works. The core problem seems to be time dependency: the most difficult to be solved. 1.2. The route Preservation of music has been studied for many years on a wide range of manuscripts and instruments, while the sustainability of live electronics is a recent interest, more complex and with a lot of missing information: more and more difficult to obtain. Because of this complexity and of many scientific underlying issues, adequate new methodologies have to be applied. The European project named CASPAR' (Cultural, Artistic, and Scientific Knowledge for Preservation, Access and Retrieval) has been launched in 2006, bringing together 17 partners, including IRCAM and the University of Leeds, on the general topic of preservation of digital data. This project intends to address three different communities, by developing three different testbeds: one for scientific knowledge, one for cultural heritage, and 1 http://www.casparpreserves.eu Figure 1. Francois invented in 1974. le pertorming at Acousmonlum,

Page  2 ï~~one for performing arts. Inside the performing arts scenario we developed a base architecture for building stand-alone open tools, specialized for analysis, feature extraction, documentation and monitoring The target of our research is the development of software modules, used for various activities, such as signal processing or symbolic calculation, for production and performance common to all arts (music, dance, theatre, video, interactive installations, etc). 2. STRATEGIES FOR SUSTAINABILITY Either hardware or software, active modules provide control and signal processing functions. Nowadays musicians use intensively graphical languages, like Max/MSP, PureData [3] or Reaktor, to implement almost any required process. Several strategies have been evaluated to face sustainability and re-performance requirements of works based on those environments. From one hand, the simplest way to make an artistic work re-performable is to keep safe all what was used in the first performance, including the knowledge to do that. This strategy leads to the institution of a kind of "museum of artistic works" and needs all the related cares (including maintenance, periodic test of devices, periodic retraining of technical personnel, etc.). On the other hand, the best solution would be to save only the meaning that is inside an artistic work, so that it could be re-performed at any time with the technology of the moment. This approach introduces the use of new languages needed to describe artistic works [4] and doesn't solve the problem of the already produced works. In the same perspective, some researchers have explored mathematical formalization of signal processing [5]. environment. This lack of contents makes it impossible to "translate" intentions automatically into a virtual language. So the strategy is, maybe, the best one for future productions, but only a partial solution for the whole problem. Part of the effort of our research is in the direction of defining significant indicators and developing tools to extract then from existing works. Many of the instruments for this purpose are still to be invented. Between the first strategy, conservative, and the second, innovative, some other ways can be followed. One way may be to virtualize the hardware, using emulators, and leaving the original software untouched. This solution has the advantage that the reperformance will use the most recent hardware available. However, an emulator needs to be developed for every used device of the past. In addition, this does not solve the problem of knowledge about works. Another way is to port the artistic work on more recent environments every time the last used is near to become obsolete. This solution only delays the problem but does not solve it. In fact, the author must participate in every new porting process. Generally the author introduces changes into the new work. So, a new artistic work is generated and it has to be preserved as well. Finally, we can consider the so called "problem of authenticity". This means that every time we modify something within an existing artistic work, we have to prove that the new product is equivalent to the original. This can be achieved using specific authentication processes based on standard methodology, with absolute physical measures and throw the intervention of reference validators (authors, performers, musical assistants, etc.) [6]. 3. TOOLS TO SUSTAINABILITY 3.1. Structure tools We have developed a set of tools, named Patcher Tools, based on a parser of Max/MSP modules that make the whole structure of a patch and its sub-patches available. As an instance, let us consider the Max/MSP patch of Jupiter, composed by Philippe Manoury in 1987. This work, for flute and live electronics, is regularly performed since its creation. LIC 81 NC B.2 MAYJMP LIBMAX/MSP Figure 2. The simplified schema of the digital implementation for an artistic work. People involved in the performance, especially for the early works, were often specifically trained and all the information was transmitted orally. Nowadays some authors, performers and technicians are no longer available to reconstruct the original

Page  3 ï~~Ph p 2- Nialv'sux'y Jupiter vr$iorl Zf'.~"^'X d 4Y S!.; 1-$14^Ct,,,a,hies 14 fuMet 2.0,04!@v?+; sac u; s r-1tt rt+? >xas r-4- e; r q? tr si rt I,7 5 1 c&z f 3 Fes, k}i,:i }-:; Fu Li't4e3?l: 3=' i 3ETk'ITi=:3-f F Ii"' i: Fl4 P p:. Li-- 3.2. Repository tools Some of the artistic contemporary works are stored into existing repositories [7], some others are still resident in private archives, and for some we don't know references. External components (the libraries used in several artistic works) need to be documented by adding some further features (version, date of last update, etc.), and information on their behaviour. For the purpose of bringing all together we have developed a specific repository that is based on a portal architecture and we have provided it with several specialized portlets. The repository would be a media to store objective information, such as the features stated before, to collect external sources and to grab some subjective information from the user community. The last ones ideally should be handled by musical assistants, through one or several wiki portlets, that will store information such as migration information (heuristics...), comparisons, comments and so on. E,2 fm Figure 3. A screenshot of the main patch of Jupiter Looking at figure 4, that represents the top patch, the boxes in the left column are sub-patches. All together they make a sort of electronic orchestra: reverb is the module of reverberation, fshift is the frequency shifter (a signal process that adds and subtracts a certain frequency to the fundamental of the input signal), and so on. The horizontal series of buttons, from 0 to 13, at the top of the patch, enable the user to trigger the beginning of the corresponding sections into the score. Other boxes are for instance faders to adjust sound levels (input and output) or start/stop buttons. Within the development program, it is not possible to have an overview of the whole hierarchy of patches. That is the first reason for which we developed the PatcherMap tool. Another important feature of this tool is its ability to check the set of resources required inside the patch. Figure 4 shows various lists: on the left, the list of abstractions (all the required files), the list of externals (third-party objects), the list of missing references (referenced but not found patches), the list of script files used, and the list of data files. In the centre of the window, the hierarchy is displayed as a tree, with the possibility of showing only a part of it (limiting the depth or the width to be displayed). Mai [EN].................................................................................................................................................... Welcome to IRCAM Max/MSP Externals and Abstractions Repository lUe e 9l:t a 1 brarf m the upper wtncow. [ Figure 5. A screenshot of the portal for components In addition to the information provided, queries on the contents will be possible for the purpose of localization of newer versions of a component, or versions of the same component on a different operating system, as an example. Hash values will be provided in order to enable precise identification of the required components. The repository is thought to allow for the analysis of the texts stored, collected now as comments, in order to build thesauruses, dictionaries of terms, and relationships between entities. These elements will lead to the development of a specialized ontology of digital instruments. 3.3. Display tools The hierarchy provided by structure tools can be...._-..displayed using any standard tool. The purpose is to express information in the most Figure 4. A screenshot of the PatcherMap application convenient form for users' understanding. showing the hierarchy of modules of Jupiter. As an example, figure 7 shows a different way to present the structure of Jupiter.

Page  4 ï~~4. CONCLUSIONS Figure 6. A screenshot of GraphViz, a standard open source tool. These tools may be used to have an overview of patches during their reimplementation but also for the evaluation of scenarios complexity, as an example. 3.4. Software engineering tools Among the tools developed we can distinguish two different classes: the ones for static code analysis and the others for run-time performance diagnosis. The static code analysis class of tools is intended to provide, in structured schemes, further information about the inside of an artistic work, including environment description, project structure, file structure and catalogues for libraries (see figure 8). We developed an "intelligent" code coverage analysis technique and we are using it to identify code holes, lacks of consistency, complexity and styles of writing. All the collected information will be placed into the repository and will be available as meta-data of the work. Thanks to the open architecture that has been the basis of our solution, many other tools can be developed for cooperation in the future. By sharing the large amount of meta-data available for the archived works and enriching them with the important experience of users, we will be able to make contemporary arts safe from obsolescence and usable, so really still alive. Only the first part of the job has been done and we have to make a large amount of further research to make information user-friendly and its retrieval as simple as possible. Hopefully, we will also be able to supply future developers with useful and efficient guidelines: this is the way we have thought to have always straight routes to our roots. 5. ACKNOWLEDGEMENT Work partially supported by European Community under the Information Society Technologies (IST) programme of the 6th FP for RTD - project CASPAR contract IST-033572. The authors are solely responsible for the content of this paper. It does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of data appearing therein. 6. REFERENCES [1] Longton, M. 2004. Record Keeping Practices of Composers, a survey (revised in 2004). InterPares 2 Website, at http://www.inteiares org, accessed October 2006. [2] Bernardini, N., and Vidolin, A. 2005. Sustainable Live Electro-acoustic Music. In Proceedings of the International Sound and Music Computing Conference, Salerno, Italy, 2005. [3] Puckette, M. 2004. New Public-Domain Realizations of Standard Pieces for Instruments and Live Electronics. In Proceedings of the International Computer Music Conference, Miami, 2004. [4] Music Notation Journal, Fall, 1986, 4(2) pp. 47-48. [5] Orlarey, Y., Fober, D., Letz, S. 2002. An Algebra for Block Diagram Languages. In Proceedings of International Computer Music Conference ICMA 2002, Goteborg, Sweden, 2002. [6] Roeder, J. 2006. Preserving Authentic Electroacoustic Music: the InterPARES Project. In Proceedings of the IAML-IASA Congress 2006, Oslo, Norway, 2006. [7] Bachimont, B., Blanchette, J.-F., Gerszo, A., Swetland, A., Lescurieux, O., Morizet-Mahoudeaux, P., Donin, N., Teasley, J. 2003. 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. Figure 7. A screenshot of static analysis IDE. The run-time class of tools will provide the means for both adequate dimensioning of hardware and monitoring all aspects of performances. Based on professional profilers technology, they monitor global parameters like memory and CPU, but can furnish detailed values on every function running inside the project (number of instances, parameters passing overhead, memory usage, CPU usage, etc. as shown in figure 9). Tools are specially oriented to musical or graphical processing, so directly provide control over complex structures like buses, pipe-lines and special data formats. Figure 8. A screenshot of profiler, a dynamic analysis tool.