The Network Editor is one of CLAM's most important applications. It is a graphical application for directly interacting with CLAM's graphical model of computation by editing a CLAM::Network object (see section 3.2.2). It can by itself be an environment comparable (conceptually, not in features) to graphical environments such as Max (see section 2.5). Nevertheless, in the context of the CLAM framework, we consider that it is no more than a rapid prototyping tool that can help in modeling signal processing systems that can later be optimized and converted into real applications.
The Network Editor has not been designed with immediate artistic or musical usage in mind. Nevertheless, with slight modifications, it could clearly have application in this field and some experiences in this direction are already under way.
The Network Editor interface (see figure 3.14) is divided into two parts. On the left side there is list of available Processing classes while on the center to right side there is a graphical representation of the system under study.
The list of Processing classes is obtained from the CLAM framework factory register, which is a central repository list of available Processing classes. So, in order to be able to use a Processing class from within the Network Editor it must first be registered in the factory. This represents an inconvenience when writing new classes as the application has to be rebuilt. For that reason, dynamic loading of pre-compiled libraries that would allow a plug-in like functioning is on the todo list. Nevertheless the Network Editor does allow to load generic Ladspa plugins. Finally, another interesting property of the available class list is that it automatically classifies classes into categories using the available class information.
The graphical representation of a Processing object that is inserted in the graph is also obtained automatically from the class definition. A Processing object is represented by a rectangle that includes the class name on the low inner half. The object name that appears on the top inner side can be provided by the user or else is generated automatically. Input/output ports are represented as small rectangles, input ports located on the left and output ports on the right side of the Processing object. Controls are represented by small triangles, input controls on top of the Processing object and output controls below. and a graphical representation of input/output ports (as small rectangles ) and input/output controls (as triangles).
Data connections linking input and output ports are represented by a thick curved line while control connections are represented by a thin line in a different color. The path of the connection is determined automatically and, for the time being, cannot be modified by the user who is just in charge of deciding the input and output ports to connect.
When double-clicking on any Processing object representation an automatic configurator object is shown. This graphical widget allows the user to change the configuration of the given Processing object.
The resulting Network description can be stored into XML. This XML file is composed of two parts: the processing Network description and the graphical layout. It therefore acts as a project file that can be loaded afterwards to recall the exact project state that was stored.
The application does not generate code, and therefore nor a compiled binary, but this feature is planned for future releases.