Processing Objects

We usually understand the verb ``to process'' as the action of transforming some existing data. This transformation can be a change in the data state or even its essence.

The DSPOOM Processing class is the abstract encapsulation of a process following the object-oriented paradigm. We call any instance of a Processing subclass a Processing object. Just as any object (see section 1.1.1) a Processing object has its own identity, behavior, structure and sequence of valid states. A DSPOOM Processing object is directly related to Processing objects in CLAM (see 3.2.2) but also to similar concepts in other environments. Therefore a DSPOOM Processing object can be seen as an abstraction of Marsyas' transformations (see 2.3.1), OSW's and Kyma's transforms (see 2.3.2 and 2.5), objects in Max (see 2.5) and sound objects in SndObj (see 2.3.3), unit generators in CSL and Aura (see 2.3.3 and 2.3.2), STK's instruments (see 2.3.2), processes in FORMES (see 2.3.3) or virtual processors in VSDP (see 2.2).

The Processing objects are the main building blocks of a DSPOOM modeled system. All processing in a DSPOOM model must be performed inside a Processing object. While the Processing object is running it receives and emits two kinds of output: synchronous data and asynchronous controls.

Figure 4.2: DSPOOM Processing class

Figure 4.2 illustrates the different concepts that are encapsulated in the Processing abstract class and therefore in any concrete Processing object. Its main components are a configuration, incoming and outgoing data ports, incoming and outgoing controls and any number of internal algorithms. We will now introduce all of these concepts and the way they interrelate.

First though it is important to note that in a processing object we define two different flows: from left to right we have the data flow and from top to bottom we have the control flow. The data flow is synchronous and thus controlled by an external clock. The control flow is asynchronous and event-driven. We will come back to the definition of different flows in section 4.1.1, when we are a bit more familiar with the processing internal structure.

When triggering the process, we are asking the Processing object to access some incoming data and, using the encapsulated algorithm(s), transform it to some output data. A Processing object is able to access external data through its connection Ports. Input ports, or Inports for short, access incoming data and Output ports, or Outports, send outgoing data. This same idea is found in other environments apart from CLAM. Ports, for instance are called inlets and outlets in OSW and Max (see 2.3.2 and 2.5)

Apart from the obvious interface for accessing encapsulated Processing Data, Ports must offer connection facilities. Pairs of ports can be connected as long as one of them is an Inport and the other and Outport and meet a further condition: they are of the same Processing Data type. Although this condition may be somehow relaxed by allowing connections of polymorphic Processing Data Ports, this is not the recommended nor the usual situation.

Besides receiving and sending data at a fixed rate through its Ports, a Processing object may also receive asynchronous Control events. These events affect the Processing object internal state and therefore are able to influence the result of the process itself. The Processing object can also broadcast these received events or some internally generated ones through its output Controls.

But all this mechanisms can be seen as auxiliary to the processing object main functionality, which is that of encapsulating one or more particular algorithms that work towards a clearly defined purpose. These algorithms are the ones actually in charge of transforming or processing the input data. The selection of one of the maybe alternative algorithms available is usually done upon configuration though some particular processing objects may be able to implement an Strategy pattern[Gamma et al., 1995] for dynamically selecting one algorithm or the other. Whether this policy is possible or not will depend, as in many other situations, on whether a change in the algorithm means a structural change or not.

The execution of the Processing functionality is triggered by sending it a Do message. This should be the only way to access a Processing object functionality and the response to this message must be well defined. On the other hand, dynamic changes (and by dynamic we mean those that can be applied without the object having to transition from one of the main states to the other) will be triggered by the acknowledgement of an input control. The response of a Processing object to a Do message depends on the values of the data in the input ports but also on the internal state, which depends on the input controls received.

Figure 4.3: Processing Class