Bottom-up CASA systems are typically built in a modular fashion from fairly standard components. The CASA Toolkit aims to ease the design of CASA systems by offering the user a library of well documented pre-defined processing blocks and a mechanism for combining them in an arbitrary fashion.
At the heart of the CASA toolkit is a library of `primitive blocks'. These blocks are defined in terms of the foll owing:
Figure 3.1 illustrates several primitive blocks.
 |
Block's may be broadly divided into 3 distinct types: source blocks, processing blocks and sink blocks.
A source block has output sockets but no input sockets. A source block will generate its own data (e.g. a pink noise generator block) or will represent a file of stored data ( a WAV file reading block). The data that is read or generated is passed to the source block's output socket.
A processing block has both input sockets and output sockets. A processing block will take data from its inputs, perform some operation on the data and pass the result to its output sockets. For example an FFT block takes a frame of data from its input, performs an FFT and passes the transformed frame to its output.
A sink block is a block that has inputs but no output sockets. Sink blocks generally represent output files or data displays.
At the lowest level of description a CASA sytem is described by a set of primitive blocks, their parameters, and the connections that exist between them. However, when designing systems it may be more convenient to describe the system at a higher level as a set of sub-components which are themselves composed of primitive blocks. This may be convenient if identical sub-components are used more than once in the same system, or if the user wishes to reuse identical sub-components in other systems.
The toolkit allows the user to define a sub-component, or intermediate block in terms of the primitive blocks it is composed of. Once defined this sub-component may be used as though it were itself a primitive block.
This heirarchical sub-component design may be extended so that higher level intermediate blocks may themselves be composed of mixtures of primitive blocks and lower level intermediate blocks.
CASA systems and system sub-components (i.e. intermediate blocks) may be described using a simple script like language and stored in files with the extension `.ctk'.
A .ctk file may contain the description of one or more sub-components, or a complete system. In either case the description includes a list of all the blocks contained in the system or sub-component together with their parameter values and a description of the connections between their inputs and outputs.
Chapter 4 provides a tutorial describing in detail how to write CTK scripts.
Although writing scripts for small simple systems is straighforward, more complicated system can be hard to visualise from the linear script description. A graphical interface has been provided that allows the user to design systems and examine and edit existing scripts in an intuitive manner. The interface can also be used as a platform from which to interactively experiment with CTK systems.
Use of the CTK GUI is cover in Chapter 5.
The toolkit is distributed with a library of existing primitive blocks. These primitive blocks are written in C++ and compiled into the toolkit. However, the toolkit is designed to be easily extendible. It is hoped that with the help of developer's documentation and the example of the source code for the existing inbuilt blocks, users with a little knowledge of C++ will be able to write their own inbuilt blocks for incorporation into the toolkit library.
Chapter 6 describes the necessary steps for adding a new primitive block to the system.
