Platform abstraction

Under this category we include all those CLAM tools that encapsulate system-level functionalities and allow a CLAM user to access them transparently from the operating system or platform.

Audio I/O

The core of CLAM audio input/output is the AudioManager class. The Audio Manager takes care of all administrative tasks concerning the creation and initialization of audio input and output streams, using the internal, system dependent AudioDevice class.

The first thing that needs to be done in order to use audio is create an AudioManager object. While this object is present all subsequent audio I/O objects created will use it. Samplerate and latency should also be specified. The latency is used to control the internal buffer size, and depends on the hardware.

The actual audio I/O classes, called AudioIn and AudioOut, can than be uses to create processing endpoints to retrieve audio from, or write audio to. The AudioIn and AudioOut objects have to be created with an AudioIOConfig object that can be used to specify the device, the channel and the sample rate to use.

The device is referred to with a string that has the following form:

"ARCHITECTURE:DEVICE"

The available devices depend on the hardware and system configuration. A list of available devices for the platform in use can be obtained from the AudioDeviceList class. However, if the device is not specified, or the string "default:default" is used, the Audio Manager will choose the device that seems most adequate for the current architecture.

In order to have a flexible multi channel system, the channel for each AudioIn and AudioOut can be specified. The Audio Manager will use this information to initialize the internal audio handling.

We can consider the AudioFile I/O tools as a complement to the general Audio I/O ones. Nevertheless, these tools do much more than this. To start with, using some external libraries (see A.2) the CLAM AudioFileIn and AudioFileOut classes are able to handle multiple audio formats such as MPEG1-Layer3 (alias mp3), Ogg-Vorbis (a similar yet better and Free compressed format), or any flavor of the PCM formats.

On the other hand, using the AudioFile class, we access other interesting information available in the file other than what is strictly the audio signal. ID3 metadata is handled and can be used for any content-based application.

MIDI I/O

The MIDIIO approach has several similarities with the AudioIO one. The core of CLAM midi input is the MIDIManager class. The MIDI Manager takes care of all administrative tasks concerning the creating and initialization of MIDI input streams, using the internal, system dependent MIDIDevice class. Inorder to use MIDI, a MIDIManager object has to be instantiated. This object will be a Singleton (see [Gamma et al., 1995]), and all subsequent MIDI input objects created will use it.

The actual MIDI input class, called MIDIIn, can be used to parse incoming MIDI data, and handle it in any way. A derived class, MIDIInControl, has one or more OutControls, and can be used to convert the MIDI data to CLAM ControlData. The MIDIIn objects have to be created with a MIDIInConfig object, that can be used to specify the device, and settings for the filter that decides which MIDI data will be parsed to this MIDIIn object. The MIDI Manager and MIDI Devices use this information to create a very efficient MIDI parsing table.

The device is referred to with a string that has the following form:

"ARCHITECTURE:DEVICE"

Currently, the implemented architectures are ALSA and Port MIDI, and the "virtual" MIDI file device. The available devices depend on the hardware and system configuration. A list of available devices for the platform in use can be obtained from the MIDIDeviceList class. However, as in the AudioIO layer, if no device is specified or if "default:default" is selected, the MIDI Manager will choose the device that seems most adequate for the current architecture.

The MIDIInConfig class has three parameters that control which MIDI data will be delivered to a certain MIDIInput object: ChannelMask, MessageMask, and Filter. ChannelMask and MessageMask are bitmasks, and Filter optionally specifies a filter on the second byte of the MIDI message. The ChannelMask allows to create a MIDIIn that receives MIDI messages on a certain channel or channels only. The MessageMask allows to create a MIDIIn that receives MIDI messages of a certain type only. The Filter allows to create a MIDIIn that receives MIDI messages where the second byte (first data byte) has a certain value. This is particularly useful for control change messages, where the second byte specifies the type of control change.

The derived class MIDIInControl implements MIDIIn with one or more OutControls. The actual amount depends on the filtering used. Outputs will be generated for each message that the MIDIInControl will receive. If. for example, a MIDIInControl is configured for eNoteOn messages, two OutControls will be used, one for key, and one for velocity.

When the MIDI input comes from a device, typically live input, MIDI messages gets delivered through the controls as soon as they come in. In the case of the special "virtual" FileMIDIDevice, this situation is slightly different, and a MIDIClocker should be used to control the sequencing of the data in the MIDI file.

SDIF SUPPORT

SDIF or Sound Description Interchange Format is a binary format defined and supported by various research teams [Schwarz and Wright, 2000,Wright, 1999,Wright, 1998b]. It was created with the goal of having a common format for exchanging synthesis samples, usually spectral domain data coming from a previous analysis.

The mapping of CLAM data to a SDIF File is fairly simple; it is always done from a CLAM::Segment object (see section 3.2.1). The Segment internal structure can very easily be mapped to SDIF as it basically holds inside an array of time-ordered frames. Out of the different data inside a frame, only the necessary for the synthesis process is stored into SDIF. That is, residual spectrum, sinusoidal peaks with track number and fundamental frequency. Due to the SDIF specification, all magnitude data needs to be stored in linear scale (as opposed to what is usual in CLAM, where data is in dB).

All this is done using two CLAM Processing: SDIFIn and SDIFOut. SDIFIn takes a Segment in its output port because it needs a single reference where to store the created frames. SDIFOut takes frames in its output port and enables storing frames even from different segments.