ï~~
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