ï~~ 4xy consists of a set of language extensions to the C programming language and a run-time environment. The compiler is designed to support the description of functions, called Actions, which will be executed in real-time and regarded as running in parallel, and to facilitate the interface of these Actions with the 4X patch language and hardware peripheral environment. Many of the constructs in 4xy are meant to simplify the coding of compositional algorithms, and to enhance the ability of such algorithms to be controlled in a real-time environment. MAX, realised by M. Puckette from MIT, is an implementation of a set of real-time process scheduling and communication ideas aimed at making it possible to design elements of a system which can be combined quickly and without changing code.MAX is partly written in 4xy language. MAX greatly speeds the development of new 4X applications, making it possible to use a 4X patch without writing a dedicated control program for it. The 4X patch language of P. Potacsek, described in earlier papers, has been equipped with a graphic interface on the Sun and Macintosh workstations. The power of the 4X and the multiplication of real-time controls has led to a system of increasing complexity. The development of interactive graphic tools addresses this complexity by providing an elegant and effecient mechanism for generating both binary code to be used directly by the system, and program text which can be incorporated in user applications. In the case of the.patch language, an interpreter is loaded into the 4X and executed. This interpreter reads commands sent it through a link with the graphic stations. On the screen, the user can manipulate symbols representing various 4X and higherlevel synthesis modules, connecting them to produce and control sound in real-time. Ensembles of such symbols can be grouped and given a name, to be used in other configurations. Once a patch has been developed, the source code for its realization can be output to a file. A similar tool for the PACOM control console has been developed by Emmanuel Favreau. The same communication link is used between the 4X and graphic host, which this time represents the devices available on the console. The user can assign the output of different devices to registers in the 4X controlling the patch, and immediately test the control on the console itself. The range of values output by each device can be defined, as well as various types of scaling which may be applied before sending a new control value to the 4X. The combination of this tool with the graphic patch tool described above engenders a powerful means of designing and developing patch programs for the 4X and real-time environments to control them. 2-ORPHEE A REAL TIME. UNIX-LIKE MONITOR FOR A 68000 VME-BASED SYSTEM (M. Fingerhut) This chapter describes the programming environment of the 4X system. This system is composed of three main parts: the 4X, the VME (a 68000 VME-based system), and the host (a Sun station).It provides a running environment for programs developed under UNIX and used to control the 4X and MIDI devices. ORPHEE, the real-time monitor, is distributed between the VME and the host. The VME resident part (henceforth referred to as the monitor) implements a Unix-like command language mainly used to manipulate files on the storage devices stored in a hierarchical directory structure, and to run programs; provides such system services as input-output (to local and remote files), memory allocation and remote program invocation through Unix-like system calls; and services real-time interrupt requests from the 4X and other peripheral devices-. The host's resident part (henceforth called the server) services such remote requests as file manipulations, navigation through its file system and communications with host resident processes. 2.1-Boot ORPHEE can be directly booted from any of the local disks or down-loaded from the host. 2.2-Development Tools This section lists the specific tools used to prepare a program to be run on the system. User programs are typically distributed between the 4X and the VME, and can be developed on the host or another remote computer. The VME resident programs can be written either in C or in an extension, called the 4xy language, while those to be run on the 4X are written in a language called patch. In adddition to such standard tools as editors, the following are available: ccvme compiler for VME programs written in C cpat compiler for 4X programs written in the patch language csco compiler for VME programs written in the 4xy language 2.3-Monitor Commands The monitor commands available at the keyboard are mainly used to manipulate local or remote files, and to navigate in the local or remote file system. Commands issued at the terminal are of one of two kinds: local (i.e., executed by the monitor) or remote (shipped to the host and executed by the server). Remote command names are preceded by a period. For example,is is the list command executed locally, while.Is is the shell (remote) list command. This also applies to command files: one whose name is not preceded by a period will be executed locally (even if it is found on the host), while if it is preceded by a period it will be executed by the shell on the host. Remote commands, being executed by the remote shell, can manipulate only remote files. Local commands can manipulate local files, and in most cases, also remote files. 2.4-File Names and Directories User files can reside either on the local or remote file system. The local one is currently composed of 2 drives, 0 and 1, drive 0 being a fixed disk dedicated to the system, and drive I a removable cartridge whose contents are left to the discretion of its owner. The remote file system is the one supported on the host. The local file system supports hierarchical directories, the root directory being denoted by '. There is always a current (local) working directory, displayed by the pwd command and altered by means of the cd command. A file name is a null-terminated string of ascii characters. Those built-in commands and monitor system calls which manipulate files may need the name(s) of one or more input or output files. These files may, in turn, be indifferently located on the local devices or the host. ICMC 86 Proceedings 370
Top of page Top of page