.ds LH PLAYER 
.ds RH 2.2
.ds CF DRAFT
.TL
State of the Implementation
.AU
Gareth Loy
.AI
Computer Audio Research Laboratory,
Center for Music Experiment,
Q-037 UCSD, La Jolla, CA 92093.
ucbvax!sdcarl!dgl
.LP
This document covers the 2.2 release of Player.  
There have been numerous bug-fixes and other changes.
Most notable changes are the following:
.IP \(bu
\fBargc\fP has been renamed \fBArgc\fP, and \fBargv\fP has been renamed 
\fBArgv\fP to make the naming policy more coherent.
.IP \(bu
The specification of relative octaves in pitch cyclic list format
has changed slightly.  See section 28.3.1 of the Manual.
.IP \(bu
\fBOut_proc\fP has been renamed \fBPrint_notes\fP.
.LP
This implementation includes most of the initial design motivations, namely,
.IP \(bu
parallel processing with hierarchy,
.IP \(bu
time-ordered program execution,
.IP \(bu
extensible music data representations,
.IP \(bu
message passing among processes,
.IP \(bu
support for realtime operation (including integer-only hardware).
.PP
The first three elements were there more or less from the beginning.
Player has been used over the last two years under the UNIX
timesharing system for generating compositional
algorithms for software sound synthesis, and in generating streams
of MIDI data out of realtime.
.PP
Facilities for message passing in Player are still basically nonexistant.
At this point, Players use \fBP\fP-variables to communicate, which works
fine, but is not elegant.  When finally addressed, message passing
will require some language restructuring.
.PP
It was always my intention to implement Player in realtime, to take
advantage of the C language's tight compilation.  A first pass of this
implementation is now complete.  
Without any code optimization, it seems that Player runs medium fast,
executing a reschedule of a Player in about 5ms on a 10MHz 68000 processor.
With optimization, this figure
might be reduced to below 1ms or so, I suspect.
The binary image of the runtime library for the realtime version is on
the order of 4KB.  Each process requires a minimum of about 100 bytes or so of
memory.
While Player was not difficult to port,
the initial realtime port required considerable rewriting of the
timesharing version, all of which is now finished.
The two versions share all sources that are not required to be different.
It should not be difficult to port it wherever there is a processor with
a C compiler and a way of measuring the flow of time.
.PP
Player is thus starting to live
up to its name, which was chosen to convey my intention that it
support realtime performance processing.
