Data and Control Flow

While a Processing object is in the Running state it will receive, process and produce two different kinds of information:

• Synchronous data: That will be fed from and to the Ports every time a Do method is called. Processing objects consume Processing Data through their input Ports and produce Processing Data to their output Ports.
• Asynchronous data: Fed from and to the Controls whenever a control event happens. They usually change the internal state/mode of the algorithm

These two kinds of data clearly define two different graphs and flow control policies. We will now explain how these kinds of data affect a Processing object and will leave flow control issues to future sections (see section on Networks in 4.1.3).

Processing objects consume Processing Data through their input Ports, process it and leave the result in their output Ports. The Processing Data is consumed and produced in response to a call to the Do operation therefore when receiving such a message the Processing object must have valid data in its inputs and must have a valid location where to write the result.

It is important to note that in DSPOOM a data token is the atomic partition of any processing data that refers to an instant in time. Therefore a whole spectrum, whatever its size, is a data token. But a chunk of audio is not considered a token as its data spreads over time, in this case the data token is each of its sample. Processing objects though, do not consume a unique, not even fixed, amount of data tokens. Each processing object may configure the size of the data chunk needed for a single execution. A processing may need n spectrums or n audio samples in order to produce a valid output. In section 4.1.2 we will review the main features and services that these Processing Data objects must offer in the context of a DSPOOM metamodel.

Ports in a processing may be also understood as pointers that point to somewhere where the data to be processed is located (usually a memory location). If both the outport and one of the inputs are pointing to the same location, the processing object is said to be processing inplace. Not all the processing objects have the ability of processing inplace as this greatly depends on the algorithm that they encapsulate. Furthermore, input and output ports do not even have to be the same kind: the transformation or process introduced by the processing object on the incoming data can be so structural that even the data kind may change (e.g. a processing object may convert an input ``tree'' into and output ``piece of furniture'').

But, as already mentioned, apart from the synchronous data flow, Processing objects can respond to an asynchronous flow of events. This mechanism is encapsulated in the concept of Controls. A Processing object may have any number of input controls and output Controls. An input Control affects the non-structural aspect of the Processing object state. This means that the reception of an input Control does not produce a transition from one of the four main states to another, it rather produces an inter-state transition from one of the possible sub-states to the other. On the other hand, output Controls maybe generated at any time although it is usual for them to be the result of one of the two following cases: (1) a response to a received input Control or (2) a result of a particular algorithm that apart from (or instead of) producing output data also generates a number of asynchronous events.

Controls must also have a clear initial value. In most cases this value is set in the construction of the owner Processing object. In other cases, though it is interesting to associate this initial value to a particular configuration parameter. The initialization of the control value is performed in the Start transition so that every time that the Stop/Start cycle is followed the control is able to return to its initial value.

This distinction between data and control is directly related to the In-band Out-of-band Partitions pattern commented in section 1.5.3.