The Evolution of the Graphic Editing Environment for the IRCAM Musical WorkstationSkip other details (including permanent urls, DOI, citation information)
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 3.0 License. Please contact firstname.lastname@example.org to use this work in a way not covered by the license. :
For more information, read Michigan Publishing's access and usage policy.
Page 185 ï~~The evolution of the graphic editing environment for the IRCAM musical workstation Enzo Maggi real time systems group email@example.com Francois Dechelle real time systems group dechelle @ ircam.fr IRCAM - 1, Place Igor Stravinsky - 75004 Paris Abstract Since its introduction, the 'Max' programming language and real-time environment has had a continue evolution: it was separated from its computational engine (the FTS system), it evolved into a full featured industrial product (Max IRCAM/OpCode) and experienced a constant growth of its external modules library. From the beginning, Max had an object-oriented approach to the description of computations (patches) and to the extension of the system through external modules. Now, the Max paradigm is evolving again into a system that is capable of dealing with complex and more rich types of intercommunications, such as the ability of being a "part" into a compound document, and at the same time to communicate with fast real-time engines such as FTS. 1. Introduction Speaking about the graphic environment for the IRCAM worksation, after many years of its introduction, means to deal with a paradigm that imposed a standard in the Computer Music community. Max infact introduced for the first time in a real time system the concept of graph based execution, with a message-based logic very close to the modem object oriented paradigms. The advantages of such an approach are much greater, from the user point of view, than the limitations imposed by the different implementations. This has been demonstrated by the wide success in the user community. Max macintosh and Max workstation have two different set of functionalities and different targets. The first is suited mostly for MIDI data handling and therefore used in small MIDI-equipped studios. On the other side, the workstation implementation provides the user with real-time audio signal processing, using a well-defined real time engine (FTS) and a graphic interface that is a client of such an engine. The target of this environment is the production of computer music works and the research and experimentation in the field of signal processing. This paper describes the main choices followed in the development of the environment together with a view at the current and future developments. 2. The Max / FTS paradigm A first important hypothesis that is at the base of the new developoment of the environment is the possibility to separate the "Max graphic interface" from the "Max computational engine". This separation led to the possibility to focus the development toward the direction of a real-time DSP engine as described in the introduction. At the same time, this was the building block for a client-server architecture that made it possible to write client applications (other than Max) on the same computing base. Today, it is possible with a little effort to control the synthesys functionalities of the IRCAM station by the mean of specialized editors. The second step toward a more flexible architecture has been the choice to make the FTS engine as portable as possible on a wide spectrum of platforms. At the present, the code base of FTS is highly portable on the.ICMC Proceedings 1996 185 Maggi & Dechelle
Page 187 ï~~main aim is to provide an interface for client applications (not only max) providing them with a set of FTS-related services. These services also allows an application to communicate with FTS with a "high level" programming interface. This layer is a mirror of FTS objects, defining the FTS object abstraction, and offering other services such as file 1O, direct-to-disk, and so on. The graphic of the FTS Editor is built on top of the portable graphic layer, which is not a complete substitution of the native graphic on each platform. Even if portability graphic toolkit exist currently on the market, the development of software based on these toolkits poses a big limitation on software reusability, and force the software development to follow the toolkit life-cycle as a product. The interactions between the client and its servers are based on registrationcallback mechanisms, in such a way that each subsystem could be easily reimplemented with different technologies (ex. OpenDoc component) without big modifications of the client code. 5. Conclusions The new strategy for the evolution of the graphic editing environment involves the FTS integration into new highperformance PowerPC native implementations, the design of a new editor based on portable layers of software, up to the specification of a common layer for the synchronization and the data exchange between the musical applications currently developed at IRCAM (OpenMusic architecture). The dynamic linking facility of the new editor is going to be extended in order to communicate with non-local objects and services, with the future perspective of patches execution that is indipendent from the physical location of the components involved in the computation. The project will have as immediate benefits the integration of audio capabilities, and the possibility to build compound documents in which 'Max like' patches will play the role of interconnected real time computation. References [Dechelle and Dececco 1995] Francois D6chelle, Maurizio De Cecco. The IRCAM Real-Time Platform and applications. ICMC 95, Banff [Dechelle et al., 1996] Francois D6chelle, Maurizio De Cecco, Enzo Maggi, Norbert Schnell. New DSP applications on FTS. ICMC 96, Hong Kong. ICMC Proceedings 1996 187 Maggi & Dechelle