|Serveur © IRCAM - CENTRE POMPIDOU 1996-2005.
Tous droits réservés pour tous pays. All rights reserved.
Proceedings of the International Computer Music Conference, Hong Kong (1996)
Copyright © Ircam - Centre Georges-Pompidou 1996
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.
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 platforms that have standard ANSI-C compilers (UNIX, Macintosh...). This makes the underlying paradigm even more independent from the platform.
The introduction of a communication protocol between the client and the server made it possible to connect a client to an FTS server in a "remote" way. Max Ircam/OpCode itself can be one of the clients of FTS [Dechelle and Dececco, 1995].
The implementation of the system on a new platform brought the IRCAM engineering team to a redesign of the underlying architecture in such a way that it provides the user and the developer with enhanced new features. This can be achieved by designing a modular system based on portable layers of software, looking for a more general solution to the problem of integrating the computational engine with the graphic user interface.
The new architecture will be embeddable in the sense that the integration of the system in other complex systems will be as easy as possible; furthermore, the separation of different functional layers of software makes it possible to easily evolve the architecture as soon as other software technologies become available.
The different layers of software, that will be analized more in depth in the next paragraph, allows a modular design in which each 'layer' can become an active reusable part, for example in an OpenDoc context.
Of course, a strong accent was put on the portability of the whole system, in its computational part as well as in the graphic part. A portable file format specification will make it easier to exchange information between platforms while mantaining compatibility with the old patch file formats.
The portable graphic layer provide the user with the ability to create and handle simple graphic objects and simple data types (coordinates, sizes, fonts). A good strategy to achieve a certain degree of (client) portability is to define the interface that the graphic layer presents to the application, hiding the implementation that will be platform-dependent. Of course, a complete graphic application would use more capabilities than the simple abstraction provided in the graphic layer, so an effort will be required in order to port the parts of a client that are platform-dependent.
Figure 1: the software architecture
The application layer, on the other side, is a software component whose 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 I/O, 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 registration-callback mechanisms, in such a way that each subsystem could be easily re-implemented with different technologies (ex. OpenDoc component) without big modifications of the client code.
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.
Server © IRCAM-CGP, 1996-2008 - file updated on .
Serveur © IRCAM-CGP, 1996-2008 - document mis à jour le .