Testing

This section attempts to show that the high level design of the system satisfies the requirements analysis.

• Transparent management of device location and usage status
  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 names (device_id’s).

• System provides a minimum set of ‘generic’ device classes
  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 rest.

• 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 (adambuckley@bigfoot.com), last edited on 16-May-2002.