Next: CLAM becomes public Up: A brief history of Previous: A brief history of
CLAM was started in October 2000. At that time, it had become clear that some sort of organization had to be introduced to the source code that was being generated at the Music Technology Group [www-MTG, ]. The SMSTools, application that had become some sort of flagship of the group[Bonada, 1997], was the result of the work of a single person and not much care had been put into applying any sort of strategy that would enable maintainability or re-usability. Furthermore, the application had been developed exclusively for the Microsoft Windows platform. On the other hand, new projects were being started all of the time. Many of them saw the potential benefits of reusing code and algorithms that were in the SMS code. But the learning curve to understand the code and internal organization was unbearable. This is even more if we take into account that the code had also been intensively optimized for real-time processing, compromising understandability and maintainability to speed, many times with misconceptions.
In this context, the idea of starting the CLAM project was born. The original name was MTG-Classes, name that already reflects two of the original restrictions (which latter were suppressed): MTG, thus the project was to be an internal project, and Classes, thus the initial intention was not to build a framework but rather a class library. The original goal, as quoted from the first draft, was:
``To offer a complete, flexible and platform independent Sound Analysis/Synthesis C++ platform to meet current and future needs of all MTG projects.''
The three main axes of this goal were defined as (from CLAM first draft document):
These initial objectives have slightly changed since then mainly to accommodate to the fact that the library is no longer seen as an internal tool for the MTG but as a library that is made public under the GNU-GPL in the course of the AGNULA IST European Project. But the truth is that as a summary of the philosophy of the framework they are as valid as the first day.
When CLAM was started it was not seen as a framework but rather as a class library that would some day offer ready-to-use C++ classes that would be incorporated in any audio or music processing project. Because of this, in this first phase most effort was put forward in the development of useful signal processing and basic tools such as sound input/output. The implementation of some algorithms was put in the hand of signal processing engineers with hardly any knowledge in programming, object-orientation or C++.
Although some basic coding conventions had been defined, no real effort was put in defining a common infrastructure. The result was highly unstructured and hardly maintainable. All of the algorithms were encapsulated in classes but the classes interfaces often differed and the framework presented too many ``hot spots''[Johnson and Foote, 1988,Roberts and Johnson, 1996].
This first phase should be understood as a exploratory phase in which the idea of a ``class library'' was studied and discarded as not sufficient: MTG-Classes should become a framework and even the name now seemed not appropriate.
About this same time it was clear that the development of the framework should be application-driven as recommended in [Johnson, 1993]. Three different applications were chosen for different reasons. SMSTools was at that time the flagship application of the group (see figure A.1) and had been, as already mentioned, the main reason for starting the development of the project. It was obvious that this application should be one of the chosen to drive the development. SMSTools is an off-line application for analyzing, transforming and re-synthesizing sounds. Another application was what we called the ``dummy test'' (see Figure A.2). This application is a multi band spectral delay artificially designed for testing what were thought to be the most demanding signal processing related requirements: spectral domain real-time processing, multiple branch processing graph with variable delay and interacting graphical interface. The last application, Salto, did not exist at that time. It is a real-time spectral domain sax synthesizer designed to be played through a wind controller MIDI interface. (See section 3.2.3 for more details on these and other CLAM sample applications).
These applications introduced more focused requirements for both tools and architecture. New people joined the team and on this next phase many efforts were put on the development of a general infrastructure. The XML format was chosen as a general format for passivation in the framework. MIDI input was also implemented. But the biggest challenge of all was to define a general infrastructure for two basic concepts: Processing and Processing Data classes.
Following the idea of a white-box framework [Johnson and Foote, 1988] abstract classes should be offered so as to enforce a common interface. The base ProcessingA.1 class was implemented and all encapsulated algorithms were forced to follow a common abstract interface (see section 3.2.2. As for the data infrastructure a big investment was made in order to have data classes with the following requirements: dynamically instantiable attributes, tree-like structure, introspection and passivation. For all these reasons Dynamic Types were implemented and have been one of the trademarks of the framework ever since (see section 3.2.2).
Soon after the project was born the idea of having two different modes related to the framework was discussed. The two modes were called supervised and non-supervised (names that will be kept to honor the history of the framework but that are admittedly ambiguous). In the supervised mode some entity of the system called Flow Control should be in charge of managing the whole data and control flow. The final idea was to create some sort of ``visual builder'' [Johnson and Foote, 1988] so the user could create rapid prototypes by just combining pre-existing blocks. In the non-supervised mode the user/programmer should be in charge of managing the system flow. The framework was in this sense understood as a combination of black-box and white-box (see section 1.3.3) where ready-to-use components were combined with code completely developed by the application builder.
Ever since the beginning and up until release 0.4, the development has concentrated in the non-supervised mode as it was the one that had the clearest requirements and was first needed, especially due to the example-driven development that had been imposed on the process. Even so, compatibility with the supervised mode was intended in every new feature that was added: the functionality was not added but the code was ready to accept this addition with minor refactorings.
After the basic infrastructure in the framework was more or less useful, more internal users were convinced of the benefits of using the framework. Now the time investment needed to master CLAM was less than the time most of the developers would need to implement their application from scratch [Booch, 1994a]. It must be said that at that time (and still now) many of the framework users had very limited programming skills and with the help of the framework they were able to implement quite complex applications.
New projects joined the CLAM community. Especially important was the CUIDADO project, an IST European project focused on the analysis and extraction of semantic information from audio signals. This project made extensive use of the XML facilities of the framework in order to produce MPEG7 compliant descriptions [Manjunath et al., 2002]. But CUIDADO also contributed notably to the framework by improving and enhancing analysis algorithms and procedures.
Not only newly started projects decided to use CLAM but also some existing ones decided that it was worth to port the code to CLAM before continuing. The most notable case was that of the Time Machine project. Time Machine is a near-lossless time-stretching algorithm developed for the Yamaha company and included in their SOL software sequencer package. The algorithm was ported to CLAM, gaining in performance, efficiency and code understandability/re-usability.
2004-10-18
![\includegraphics[%
width=0.80\textwidth]{images/chAnnex/png/SMSTools2.ps}](img109.png)
![\includegraphics[%
width=0.95\textwidth]{images/ch3-CLAM/draft/SpectralDelayBlockDiagram.ps}](img110.png)