CREATE Logo

The CREATE Signal Library (CSL) Project CSL classes

The CREATE Signal Library (CSL, pron. "sizzle") is a cross-platform general-purpose software framework for sound synthesis and digital audio signal processing. It is implemented as a C++ class library to be used as a stand-alone synthesis server, or embedded as a library into other programs.
CSL provides simple and reusable implementations of all common sound synthesis and processing techniques, and includes support for a wide variety of audio I/O interfaces such as PortAudio, RTAudio, JACK, VST, CoreAudio and JUCE. As illistrated in the screen shots below, we generally use JUCE for graphical user interfaces to CSL programs (Qt is also still supported).

CSL Downloads

Project Description CSL patch diagram

Introduction

The CREATE Signal Library (CSL) is a flexible, portable, and scalable C++ software framework for sound synthesis and digital signal processing. The following sections describe the basic system requirements and present the current design and its implementation, giving extensive code examples along the way. The initial design of CSL dates back to 1998, but the current (version 4.2) implementation was undertaken by students in the MAT 240D Sound Synthesis Techniques course at UCSB in the Spring of 2006. A simple C++ implementation of a sound synthesis framework (in less than 1000 lines) was introduced at the start of the class, and during the quarter the students added a large number of synthesis classes (refining the basic framework significantly as they went). CSL is now an open source project; the current source code and documentation can be retrieved over the Internet from http://FASTLabInc.com/CSL/.

What CSL isCSL Granulator

 CSL is a simple yet powerful library of sound synthesis and signal processing functions. It is packaged as an object-oriented class hierarchy for standard DSP and computer music techniques, and is suitable for integration into existing applications, or use as a stand-alone synthesis/processing server. CSL is similar to the JSyn (Burke), CommonLispMusic (Schottstaedt), STK (Cook), and Cmix (Lansky) frameworks in that it is integrated as a library into a general-purpose programming language, rather than being a separate “sound compiler” as in the Music-N family of languages (Pope).
CSL is designed from the ground up to be used in distributed systems, with several CSL programs running as servers on a local-area network. These CSL DSP servers receive control commands via the network and send their output sample blocks to other servers over the network. A typical large-scale CSL configuration is illustrated in the figure below.


In this configuration example, each of the round-edged rectangles is a separate server program (which might all be running on different machines). The top four servers are CSL programs; the larger box in the middle is the CREATE Distributed Processing Environment (DPE, [Pope and Engberg]) manager, and the server at the bottom captures and maps user input (e.g., from instrumental performers).
The control links (shown as dotted lines) use the Common Object Request Broker Architecture (CORBA [OMG]) and Open Sound Control (OSC [Wright and Freed]) protocols, and the inter-program sample streams (drawn as arrows) use the CSL sample block protocol. The Distributed Processing Environment manages the distributed CSL application, starts up the individual CSL servers, and routes control messages coming from the gestural input devices to the appropriate server.

What CSL is notCSLL Spectrogram

CSL is not a music-specific programming language such as Music-N or SuperCollider (McCartney); rather, CSL programs (i.e., CSL-based servers) are written in C++ and compiled with the CSL library. CSL has no graphical user interface (as in Max [Puckette] or Kyma [Scaletti]), but it is expected that GUIs will be built that manipulate “patches” and “scores” for CSL. CSL is not a music representation language such as Smoke (Pope), rather it is a low-level synthesis and processing engine. CSL has no scheduler, it simply responds to in-coming control messages (received, e.g., via MIDI or OSC) as fast as it can.
This flexibility means, however, that CSL can serve a number of different purposes, from being used as a plug-in library for other applications to serving as the basis of synthesis servers for other front-end languages, such as MPEG4/SAOL.

CSL and JUCE

In the most recent version, CSL has been simplified to use the sound and sound file I/O facilities of JUCE (Jules' Utility Class Extensions). This means that fewer out-board libraries and APIs need to be installed to start using CSL. Users can still use other sound IO APIs (e.g., portAudio, RTAudio or platform-native APIs) or sound-file APIs (e.g., libSoundFile), but the JUCE-only version is simpler to install and get running. The only additional 3rd-party library needed for the CSL core is FFTW.

The CSL Core oscillator classses

In contrast to the traditional MusicN stand-alone sound compiler, CSL is packaged as a class library in a generalpurpose
programming language (C++). The simplest CSL program is a 5-line main() function in a simple C program, and it is intended that CSL can be used in several ways, including for the development of stand-alone interactive (MIDIor OSC-driven) sound synthesis programs, serving as a plugin library for other applications or plug-in hosts, or as a back-end DSP library for programs written in scripting languages. CSL is designed from the ground up to be used in distributed systems, where networks of CSL programs run as servers on a local-area network, streaming control commands (MIDI and OSC) and sample buffers (RTP) between them.

CSL Example

    // This is a simple FM test program -- paste this into a main() function

    float frq = 440.0f;                  // float values for freq and dur
    float dur = 0.2f;

    JUCEIO theIO;                        // create a JUCE IO object
    Sine car, mod(frq);                  // declare 2 oscillators: carrier and modulator
                                         // amplitude env = std ADSR
    ADSR a_env(dur, 0.1, 0.1, (dur - 0.6), 1); 
                                         // index env = time/value breakpoints
    Envelope i_env(dur, 0, 0, 0.1, 2, 0.2, 1, 2.2, 8, dur, 0);
    a_env.setScale(0.2);                 // make ampl envelope quieter
    i_env.setScale(frq * 3.0f);          // multiply index envelope by mod freq * 3 (index depth)
    mod.setScale(i_env);                 // scale the modulator by its envelope
    mod.setOffset(frq);                  // add in the base freq
    car.setFrequency(mod);               // set the carrier's frequency
    car.setScale(a_env);                 // scale the carrier's output by the amplitude envelope
  
    logMsg("CSL playing FM...");         // print a message and play
    theIO.setRoot(car);                  // set the IO's root to be the FM carrier
    theIO.open();                        // open the IO
    theIO.start();                       // start the driver callbacks and it plays!

    a_env.trigger();                     // reset the envelopes to time 0
    i_env.trigger();   

    sleepSec(dur + 0.25);                // sleep for dur plus a bit

    logMsg("CSL done.");
    theIO.stop();                        // stop the driver and close down
    theIO.close();   

For more information, please contact Stephen Pope.

line

Go to CREATE Home