This section attempts to show that the high level design of
the system satisfies the requirements analysis.
- Transparent management of device location and usage
A devices usage status is recorded and managed by the
scheduler. If the user wishes to use any device, they
must do so via the scheduler.
The device registry contains all details necessary to
hiding the location of devices, and presenting the
application with device class names, or device instance
- System provides a minimum set of generic
The device registry contains the universal set of generic
devices, and the device_id mappings. This provides a
level of universal portability.
- Transparent management of routing matrixes
The file processor and the virtual routing matrix devices
manage the routing of signals transparently. The user
need only connect the input of one device to the output
of another device, and the system will take care of the
- Use of encapsulated audio-visual files
Files encapsulate audio and visual data as events, which
are bound to a device class. The files do, however, rely
on an external library of device classes.
- Devices are specified as a device class, which is matched
to a real instance of a device
The device registry holds a database of all device
classes attached to the system. The scheduler converses
with the device registry to find a satisfactory match for
the specified device class.
- Input control devices affect playing files in real-time
If the user wishes to use an input device, eg. a slider,
to control another device, then the user must specify
this in a dataflow structure by routing an input device
(slider) through a modifier which converts the
value keyword to another GEL keyword, eg.
volume. The updated GEL stream is then
assigned to a block in the dataflow structure which
represents the device to be controlled. The file
processor will control the flow of event streams
transparently. See examples in 8.2.
- Multi user
The scheduler and file processor can be called by any
sequencer attached to the system.
- Open system
GEL files are held in ASCII, in a format which users can
view using a simple text viewer. Event processors may be
written by third parties or any user with the skills
necessary to create the software implementation.
- Backwards compatible
A MIDI clock virtual device produces conventional MIDI
clock data, to allow time-synching of legacy systems. No
facility to export a composition in MIDI format was
provided, however. A separate program to compile a
composition into MIDI could be created, or the
composition could be recorded as it plays. This would
mean that each virtual device spools device-specific
events to a file as is plays. Collating all the spool
files would result in a MIDI file. If only one MIDI port
was used (a standard network of 16 MIDI channels) then no
alteration would be necessary. If more than one MIDI
port, or more than one computer was used, then the
channels and port settings of the MIDI file would need to
be manually configured.
This document composed by Adam Buckley (firstname.lastname@example.org),
last edited on 16-May-2002.