Low Level Design and Implementation

The focus of this project is at the infrastructure design level, and I am omitting further details on low-level design except for an example user interface. Needless to say, algorithms to provide the functionality required by the high level design must be produced according to the interface definitions given in section 4.

Furthermore, an implementation of the file processor is perhaps a project in itself.

User Interface

A screen shot of a possible interface is seen in figure 5.1

Here, we can see a view of the filestore, a scratch window and two views of the schedule. The ‘Now’ window contains files which are playing at present - ie. files which have been assigned to a file processor. The ‘Then’ window contains files which have been cued, and which will be played in the near future. Files which are looped are represented as having a trailing ‘ghost’.

Files which have not been matched correctly would be flagged according to the match variable held in the schedule (see 4.4.1). The scratch window shows two files, which are about to be grouped into a single file.

Each file has been given a recognisable texture to enable users to identify files easily (see 7.3). Moving the mouse over a file icon would temporarily display it’s name as a ‘tooltip’, as seen in fig. 5.4.

When files are dropped in the now, or the then window, this action is converted by the sequencer into a play(filename, start_time) message which is passed to the scheduler.

Another service provided by the sequencer is editing of a file’s dataflow diagrams, as seen in figure 5.3. The user creates a dataflow diagram by adding blocks from a stock of possible blocks, and connecting blocks together. Each block has properties which may be set as a list of GEL events, as seen in figure 5.4.

Figure 5.1 - A possible user interface.

Figure 5.2 - Editing a dataflow strucutre

Figure 5.3 - Property initialisations for the output synthesiser

Figure 5.4 - File icons

Implementation suggestion

CORBA

This type of system is suitable for implementation within a CORBA environment.

Briefly, this would result in:

• The scheduler, file processors, virtual devices, GEL modifiers and device registry, would be held as OMA objects, with static IDL skeletons.
• However, the GEL modifiers and virtual devices could also be held as OMA objects, but with dynamic IDL skeletons. This would mean that GEL keywords would not be specified with a definitive interface. Ie, the a note may be recorded as:

note(pitch="C3", length=96)
or note(patch="C3", length=96, velocity=64)

Both these instances would be played correctly regardless of whether the virtual device actually implemented velocity at the interface. If velocity was supported, then a default or the input value would be used. If velocity was not supported, then any velocity input value would be ignored. This method of specifying GEL keywords would be of most benefit in the long run.

• The Interface Repository would act as a natural device registry. It would know exactly which objects are available at run-time. The Interface Repository provides services which allow clients to browse the IDL definitions. The device registry, therefore, would consist of code necessary to perform match queries on the interface repository. However, this functionality may already be provided by the Dynamic Invocation Interface, and would mean the device registry is no longer needed - the scheduler would instead collaborate with the Dynamic Invocation Interface.

Problems with CORBA

Some of the operations performed by the system are in real-time, ie. passing a note from a virtual device to a physical device. In practice, a system making use of CORBA will experience delays when making requests, and is therefore not completely appropriate for real-time tasks. In this respect, real-time operations must be streamlined - the virtual output devices must function without using any time-consuming ORB services.

The delays imposed by CORBA must be considered when setting event look-ahead time in the file processor, and would become problematic when routing an input device to an output device over the ORB core, which is expected to operate in real-time.

Network

The system generates real-time, and near-real-time data, which is passed over a network. The type of network used by the system must therefore be the type which provides a consistent data rate, independent of the network load. Ethernet, in this respect, would not be appropriate.

This document composed by Adam Buckley (adambuckley@bigfoot.com), last edited on 16-May-2002.