Configurations are a special case of Dynamic Types that are used to configure Processing objects and, eventually, Processing Data objects (only complex Processing Data classes such as spectrum use this option). Configurations make use of all mechanisms provided by Dynamic Types and already mentioned. Configurations also include default initializers that add compulsory attributes and set them with default values.
Configurations are particular to each Processing class. As a matter of fact, every Processing class in the CLAM repository must have an associated Configuration class. Furthermore, when extending the framework, this requirement must also be made: every new Processing class introduced must be accompanied by a related Configuration class. Processing configuration classes must derive from the base ProcessingConfig class. The name of the configuration class should be the same as the name of the Processing object, adding the ``Config'' suffix. In some cases several processing classes may share the same configuration class. The FFT is a clear example of this. For example, figure 3.4 shows that several FFT classes exist for different algorithm implementations, but they all derive from a common FFT_base class, and they share a common configuration class: FFTConfig.
The role of the configuration class is to store all the necessary information to instantiate an object of the related Processing class. In fact, configuration classes may be described as a place-holder for parameters which would otherwise be specified as individual arguments in the processing class constructors.
Usual attributes that are implemented when writing a configuration class are number of inputs or outputs, values for parameters of the processing algorithm which the user may want to specify, and which will be fixed during the execution.