CLAM: A Framework for Efficient and Rapid Development of Cross-platform Audio Applications Xavier Amatriain CREATE University of California Santa Barbara Santa Barbara, CA xavier@create.ucsb.edu Pau Arumi Music Technology Group, UPF c/Ocata, 1 08003 Barcelona, Spain parumi@iua.upf.edu David Garcia Music Technology Group, UPF c/Ocata, 1 08003 Barcelona, Spain dgarcia@iua.upf.edu ABSTRACT CLAM is a C++ framework that offers a complete develop- ment and research platform for the audio and music domain. Apart from offering an abstract model for audio systems, it also includes a repository of processing algorithms and data types as well as a number of tools such as audio or MIDI input/output. All these features can be exploited to build cross-platform applications or to build rapid prototypes to test signal and media processing algorithms and systems. The framework also includes a number of stand-alone ap- plications that can be used for tasks such as audio analy- sis/synthesis, plug-in development or metadata annotation. In this article we give a brief overview of CLAM’s features and applications. Categories and Subject Descriptors D.2.11 [Software Architectures]: Domain-specific archi- tectures General Terms Design Keywords Frameworks, Multimedia, Audio 1. INTRODUCTION CLAM stands for C++ Library for Audio and Music and it is a full-fledged software framework for research and appli- cation development in the audio and music domain. It offers a conceptual model; algorithms for analyzing, synthesizing and transforming audio signals; and tools for handling audio and music streams and creating cross-platform applications. The CLAM framework is cross-platform. All the code is ANSI C++ and it is regularly compiled under GNU/Linux, Windows and Mac OSX. CLAM offers a processing kernel that includes an infras- tructure and processing and data repositories. In that sense, CLAM is both a black-box and a white-box framework. It is black-box because already built-in components included in the repositories can be connected with minimum program- mer effort in order to build new applications. And it is Copyright is held by the author/owner(s). MM’06, October 23–27, 2006, Santa Barbara, California, USA. ACM 1-59593-447-2/06/0010. white-box because the abstract classes that make up the in- frastructure can be easily derived to extend the framework components with new processes or data classes. CLAM also includes a number of tools for services such as audio i/o or XML serialization and applications that have served as a testbed and validation of the framework. The CLAM infrastructure is a direct implementation of the 4MS metamodel, which will be explained in the follow- ing section. In the next sections we will also review the CLAM repositories, its tools and applications. Please re- fer to CLAM’s website (www.clam.iua.upf.edu) for further information, documentation, and downloads. 2. CLAM’S METAMODEL The Object-Oriented Metamodel for Multimedia Process- ing, 4MS for short, provides the conceptual framework (metamodel) for a hierarchy of models of media data pro- cessing system architectures in an effective and general way. The metamodel is an abstraction of many ideas found in the CLAM framework but also of an extensive review of simi- lar frameworks and collaborations with their authors. Al- though derived and based in particular for audio and music frameworks, it presents a comprehensive conceptual frame- work for media signal processing applications. For a more detailed description of the metamodel and how it relates to different frameworks see Xavier Amatriain’s PhD [1] . The 4MS metamodel is based on a classification of signal processing objects into two categories: Processing objects that operate on data and control, and Processing Data ob- jects that passively hold media content. Processing objects encapsulate a process or algorithm; they include support for synchronous data processing and asynchronous event-driven control as well as a configuration mechanism and an explicit life cycle state model. On the other hand, Processing Data objects offer a homogeneous interface to media data, and support for meta object facilities such as reflection and se- rialization. Although the metamodel clearly distinguishes between two different kinds of objects the managing of Processing Data constructs can be almost transparent for the user. Therefore, we can view a 4MS system as a set of Processing objects connected in a graph called Network. Processing objects are connected through intermediate channels. These channels are the only mechanism for com- municating between Processing objects and with the outside world. Messages are enqueued (produced) and dequeued (consumed) in these channels, which act as FIFO queues.