Page  00000001 KITTy: A PACKAGE FOR EXTERNAL PATCHES COMMUNICATION MANAGEMENT IN MAX/MSP - A PROGRESS REPORT Antonio de Sousa Dias Centre de Recherche Informatique et Cr6ation Musicale (CICM) - Universit6 Paris VIII 2 rue de la Libert6 93526 Saint-Denis Cedex ABSTRACT We present KITTy (Kit d'Interfaqage Tout Terrain), a package programmed in Max/MSP allowing users to design their own network of integrated external patches. This package provides persistence and state-storage mechanisms within a network scheme. Another important feature relies upon the capability of integrating standalone applications written in Max/MSP by other users. 1. INTRODUCTION Approaches to software design for musical composition assistance and/or sound synthesis generally fall within two main categories. On one side we have a closed solution approach, a software tool supposed to carry a complete and specialized task, general enough to serve a wide community but nonetheless closed to individual adaptation. On the other hand, there is an open solution approach, providing the possibility of software tailoring. The last approach presents itself generally in an environmental or kit form, allowing the adaptation of the software to the user needs at the cost of time-spent programming. Of course, there are solutions situated somewhere in between, such as, for example, the use of plug-ins (eg, VST plug-ins), or the possibility of adding new modules to the original code, as in Csound [21] or Max/MSP [22], or even that of generating a stand-alone application from a patch. These different approaches also correspond to different composition approaches. In our own the use of different software tools (under the form of programs or patches constituting a network) led us to prefer an open solution, due to the compositional strategies we use, mainly with the Max/MSP/Jitter environment, along with the use of other software as Csound, OpenMusic [1], among others. The problem concerning the use of different external patches in Max/MSP lies in the lack of a method to keep track of external patches interconnection state. KITTy (provisional name for Kit d'Interfagage Tout Terrain) stands within the second category of software described above, presenting itself in the form Paulo Ferreira Lopes Centre de Recherche Informatique et Cr6ation Musicale (CICM) - Universit6 Paris VIII 2 rue de la Libert6 93526 Saint-Denis Cedex Z.K.M. | Zentrum ffir Kunst und Medientechnologie Institut ffir Musik und Akustik Lorenzstr. 19 - 76135 Karlsruhe - Germany of a package containing a main patch and a series of proposed external patches allowing the constitution of a network where different patches contribute to sound processing. 2. BACKGROUND The research direction carried with the development of KITTy can be traced out from two different issues. The first one deals with problems related to interface design and interaction [9]. Regarding this point our research tries to establish a communication management facility by proposing to the user a surface structure (an interface) that enables him to trace his own path directing the emergence of an abstracted and underlying structure (an instrument). Within this framework, among the various operations and transformations proposed in KITTy implementation, we observe that the achievement of the processes in which the computer is integrated as a mediator agent in the functionalities of instrument access, depends mainly on the qualities of the interface, implemented interaction typologies and conversion models applied to different types of representation. This means that the total structure of operation of KITTy, conceived beforehand in the form of representations classified in symbolic systems categories, strongly depends on the interactions resulting from the various transformation operations, among which arithmetic operations, under a sub-symbolic level, translate directly extrapolated paradigms of the musical operations inside the major structure (the instrument). The second issue focus the problems arising from the need of data transfer between different platforms as a mean of preservation and knowledge constitution. This problem has been stressed in some of Risset writings (see for example [15]) and there are some proposed solutions available ([13], [14], [16], [10], [18]). Also, and prior to KITTy conception, one must mention the important conceptual aspects brought by Duchez [7] and Solomos [17] regarding the transformation of musical material, as well as the flexible and dynamical approaches provided by Bayle [2], in the electro-acoustic music qualitative domain, or

Page  00000002 Vaggione ([19], [20]; see also Budon [4]) in a more specifically digital-based system, integrating the concepts of network, dynamics, flux and different types of representation within a compositional context. The use of some concepts borrowed from information science in the conception of KITTy can be traced in database systems theory (e. g. [6] or [3]); for a discussion on the artistic impact of these concepts see Manovich [11]. 3. KITTY'S OVERVIEW AND DESCRIPTION Briefly, this work consists in the design of a Max/MSP patch responsible for sound output, which is able to manage a network of associated external patches to sound generation (a "Setup"), keeping all information concerning each patch current state, and also "photographs" ("Snapshots") of selected states of this network taken at different times. The main difference between KITTy and other similar approaches consists in the existence of a memory allowing the permanence of the network in time, i.e., one can save a specific network, along with some of his states, for future re-use. The user can provide the external patches, and their constitution corresponds somehow to the "degenerated instruments" referred by Mathews [12], i.e., instruments that generate or process some kind of signal but not the final result. 3.1. General Structure KITTy constitution is as follows: * A main patch (see Fig. 1); * Several text files: (1) a file containing the description of the signal input-output labels ("MatrixMenu"), (2) a file containing the local syntax ("Output-matrix.stx"), (3) a file containing the names of associated patches ("PatchesMenu"), (4) a file keeping the persistence ("temp.stp", at the application level - here Max/MSP) and (5) various files containing the description of different setups (<name>.stp); * A folder for the subpatches containing: (1) a subfolder with all subpatches either used by the main patch, or to integrate in the associated external patches; (2) different folders for the associated external patches (not compulsory as it depends on the path preferences definitions). 3.2. Main features There are some important features and properties of this "environment" that we must point out: * Persistency. Once the main patch loads, it recovers the last network assembled as well as his current state before the patch closing. * This environment is based upon a principle of delegation or trust. The main patch keeps all information concerning all associated external patches, but it doesn't know their meaning. Each external patch is responsible for the management of his own local syntax previously defined by the user. * Presets have a double behaviour. They are shared by all the instances of the same patch (presets are saved in the form of a common "coll" text file). However, even if modifications are not saved in the local presets files, they are saved in the Setup, allowing a cross-use of local-global states. n patch (lett) and three associated external patches, showing an example ot audio signal tlow.

Page  00000003 .A U smamt*ixempwan!e.............................. This patch shows how to set up a patch to use within the main patch "Matrix" ea s ometsOnvetiossi bleCliskMeC <- This bypatcher manages the audio input S<- Here, you send and reoeive information about I i it-iiii:8a Oa:::::::ii the status of the settings H:e s In s ~Kg - - - -----. -- This is "your" routine (please double click) | il FASlIF OUTPUT ETTINGS <- This bypatcher manages the hIl Rees enu Ir- mF -t i audio output Figure 2. Patch template. 4. ASSOCIATION OF EXTERNAL PATCHES Patches are not integrated in the main patch: they are associated, but they keep their autonomy. Nevertheless, joining the network, that is, when invoked by the main patch, they become, in some way, instances of a class. 4.1. Description of the components to add to associated patches Even if keeping their autonomy, there are changes to carry out in the external associated Patches. Those relate to the signal input and output, and to the introduction of Presets and local syntax. There is a patch template (Fig. 2) providing all subpatches to include in an external patch along with some help. Template textual files are also provided, in order to keep this process as simple as possible. The list of the modules and modifications to be made are as follows: * Incorporation of a bypatcher containing a patch for the signal input (optional if it is a sound generator patch); * Incorporation of a bypatcher containing a patch for signal output; * A subpatches ensemble constituted by subpatches to the management and control of the messages local syntax and a Bypatcher, which purpose is the management of Presets. Finally one has to create two text files containing the syntax for the messages (<filename>.stx) and SPresets (<file_name>.prs). By default, these files have the name taken from their file-class with a different extension. 4.2. Main patch modifications On the main patch level, this association is accomplished by means of the addition of a text line containing the name of the patch in a text file outside the main patch, in a "coll" text file syntax style. Thus, it is not necessary to make adaptations to the patch himself. This is also valid for the signal communication with external patches from other authors: once one gets the names of the "Send-" and "Receive-" objects in these Patches one only has to add these names to another text file containing the signal input and output names ("MatrixMenu"). Hence, if KITTy can act, on the one hand, as a musical instrument, on the other hand it moves away from the concept of traditional instrument because it allows to reach: * A gesture quantification of the corresponding musical contents. * A temporal non-synchronization between the handling of control elements and the interface, and their repercussion in the musical results * Musical results which are not directly related to the interface handling causality. 5. PERSPECTIVES At the time of writing of this paper, there are important aspects whose implementation is still in progress: (1) Larger flexibility at the auto-reprogramming level: as an example, for the moment, all the inputs and outputs remain bi-channel (stereo). At the present moment, we are programming the possibility of different channel number controlled by scripts. (2) The need of controlling patches. Besides the parameter circulation between the main patch and external associated patches, the only circulating data in the network is the audio signal data type. We are tackling the problems arising from the implementation of other types of data circulation, including, for example, MIDI data. (3) The limitation of the memorization of some network instantaneous states ("Snapshots"). We are dealing with the design of mechanisms to record actions carried out along a certain time span, i.e., "gesture movies". (4) Improved parsing methods to keep track of inconsistencies generated by the continuous network reorganization. (5) The reprogramming of KITTy in order to benefit of the Java's facilities introduced by the OsX 4.5 version of Max/MSP.

Page  00000004 6. CONCLUSION We have just presented KITTy, a package for patch network handling in Max/MSP, allowing users to interconnect their own external patches in a progressive, flexible but systematic way. We believe that KITTy's main interest point relies on the possibility of integrating memory capabilities in a system preserving at the same time the flexibility of patch programming, responding to compositional needs. The fact that KITTy's core is presented as a patch instead of a stand alone application, allows the interconnection with other Max/MSP stand alone applications as, for example, Irin - former Mixage [5] or Source_Mov - Spatial sound diffusion application [8]. 7. ACKNOWLEDGMENTS We would like to thank Horacio Vaggione for his support on this research as well as his advice and comments. We would like also to thank Carlos Caires for the stimulating discussions on this subject. This work has been developed with the support of Fundacao para a Ciencia e Tecnologia, in Lisbon. 8. REFERENCES [1] Agon, C. and Assayag, G. OpenMusic (OM) 4.4 User's Manual Reference & Tutorial.: IRCAM - Centre Georges Pompidou, Paris, 1997 [2] Bayle, F. Musique acousmatique -propositions......positions. Paris: INA/Ed. Buchet/Chastel, Paris, 1993. [3] Benzaken, V. Bases de Donnees Orientees Objet - Origines et Principes. Armand Colin Editeur, Paris, 1993. [4] Budon, O. "Composing with Objects, Networks and Time Scales: An Interview with Horacio Vaggione", Computer Music Journal 24:3, 2000, pp. 9-22. [5] Caires, C. "Vers une ecriture des processus de micromontage" in Actes des dixiemes Journees d'Informatique Musicale, Montbeliard, 2003. [6] Delobel, C.; Lecluse, Ch.; Richard, Ph. Bases de Donnees: des systemes Relationnels aux systemes a Objets. InterEditions, Paris, 1991. [7] Duchez, M.-E. "L'evolution scientifique de la notion de materiau musical" in: Barriere, JeanBaptiste (Ed.), Le Timbre - Metaphore pour la composition. Christian Bourgois / IRCAM, Paris, 1991, pp47-81. [8] Ferreira Lopes, P. Rapport de Recherche. Karlsruhe: Zentrum fuir Kunst Medientechnologie / Fundagco Ciencia e Tecnologia, 1999. [9] Ferreira Lopes, P. Etude de moddlesinteractifs et d'interfaces de contr6le en temps rdel pour la composition musicale. Universit6 Paris VIII (Th6se de doctorat), Paris, 2004. [10]Lorrain, D. Analyse de la bande magndtique de l'oeuvre de Jean-Claude Risset "Inharmonique". Centre Georges Pompidou (Rapport IRCAM n~ 26/80), Paris, 1980. [11]Manovich, L. The Language of New Media. The MIT Press, Cambridge, MA, 2001. [12] Mathews, Max V. et al. The Technology of Computer Music. The MIT Press, Cambridge, MA, 1969. [13] Risset, J.-C. An introductory catalog of computersynthesized sounds, 1969. Reprinted with C.D. Wergo 2033-2, The historical CD of digital sound synthesis, 1995, 109-254. [14]Risset, J.-C. (1995). "My 1969 Sound Catalogue: Looking Back from 1992". in C.D. Wergo 2033-2, The historical CD of digital sound synthesis, 1995, pp88-108. [15]Risset, J.-C. "Ivolution des outils de creation sonore". In: Vinet, H.; Delalande, F. (eds.), Interfaces homme-machine et creation musicale. Hermes, Paris, 1999, pp. 17-36. [16] Risset, J.-C., Arfib, D., de Sousa Dias, A., Lorrain, D., Pottier, L. "De "Inharmonique" a "Resonant Sound Spaces": temps reel et mise en espace" in Actes des neuviemes Journees d'Informatique Musicale, ADERIM-GMEM, Marseille, 2002, 83-88. [17] Solomos, M. "Le devenir du materiau musical au XXeme siecle" in Soulez, A.; Schmitz, F.; Sebestik, J. (eds.) Musique, rationalitd, langage - L'harmonie. du monde au materiau, Cahiers de philosophie du langage (n 3). L'Harmattan, Paris, 1998, pp137-151. [18] de Sousa Dias, A. "Transcription de fichiers Music V vers Csound au travers de OpenMusic" in Actes des dixiemes Journees d'Informatique Musicale, AFIM, Montbeliard, 2003. [19] Vaggione, H. "Composer avec des reseaux d'objets", in: Academie Bourges, Actes III 1997 - Composition / Diffusion en Musique Electroacoustique. Acteon - Mnemosyne, Bourges, 1998. [20]Vaggione, H. "Some Ontological Remarks about Music Composition Processes" in Computer Music Journal, 25:1, 2001, pp. 54-61. [21]Vercoe, B. CSOUND. A Manual for the Audio Processing System and Supporting Programs. MIT Media Laboratory, Cambridge MA, 1986. [22]Zicarelli, D. "An Extensible Real-Time Signal Processing Environment for Max". In Proceedings of the International Computer Music Conference 1998. International Computer Music Association, Ann Arbor, 1998, pp463-466.