Following the tradition of Pierre Schaeffer, Diffusion refers to the live spatialization of tape music, respectively fixed media content. Typically, the music is played back in a low channel order (e.g. Stereo) and sent to a large number of loudspeakers using an 'inverted' mixing desk.


Natasha Barrett diffusing on a 3D system at a TU Studio concert (Villa Elisabeth, 2018).

The Acousmonium

The GRM (Groupe de Recherche Musicale) Acousmonium is an elaborate loudspeaker setup, designed for the diffusion of acousmatic music. It is made for touring and was first presented in Germany at the 1983 “Inventionen” festival by François Bayle. The system returned to Berlin for the 2008 edition of the SMC, where it was paired with the large WFS system at TU Berlin's H104:


The Acousmonium at TU Berlin (H104) during SMC 2008.


The Birmingham Electroacoustic Sound Theater (BEAST) is a modern version of the Acousmonium approach. It features 100+ loudspeakers in multiple groups with specific characteristics and purposes:


Different loudspeakers of the BEAST system.


BEAST setup at CBSO Centre, Birmingham, May 2009 (Wilson, 2010).

The BEAST was presented in Berlin at the 2010 Inventionen Festival, when Jonty Harrisson was guest professor at TU Berlin. Read more in the online archive of the festival.


BEAST at Inventionen Festival 2008 (Elisabethkirche, Berlin).



SuperCollider: Synchronous vs Asynchronous

The Problem

Most examples in this class can not be run as a complete script. They need to be evaluated line by line or block wise. One reason for this is the difference between synchronous and asynchronous execution. This problem is in detail explained in the SC guides: https://doc.sccode.org/Guides/Sync-Async.html This site just gives a shorter answer.

Issues usually arise, when a command has been sent to the server and following command depends on the completion of that action. Examples can be the creation of nodes or the loading and filling of buffers. Running this simple block at once will result in an error. It creates a node and does not wait for completion before it uses the .set() method. The result is a FAILURE IN SERVER /n_set Node 1000 not found:


// create white noise node with gain control
~test = {arg gain=1; WhiteNoise.ar(gain)}.play;

// try to set the gain
~test.set(\gain, 0.1);


A Solution

There are several ways of dealing with the above introduced problem. One solution is to wrap the code block in a Routine, which allows to control the order of execution. In the case of asynchronous tasks, the command s.sync can be used inside a routine. It waits for the sever to finish all asynchronous tasks and the below example works without errors:


    // create white noise node with gain control
    ~test = {arg gain=1; WhiteNoise.ar(gain)}.play;

    // wait for the server to finish all asynchronous tasks

    // try to set the gain
    ~test.set(\gain, 0.1);


Plans and Directions

The original SPRAWL System was designed as a means for enhanced interaction in Local Area Networks (LAN) (read more). Due to the needs for online teaching and musical performance in 2020, the concept was extended to a Wide Area Network (WAN) solution. In the coming months, the project with be extended in a cooperation with LTU, Sweden and Ritmo, Oslo. The following areas can be tackled in this period.

Multichannel Clients

In this semester we will extend the system to incorporate clients and endpoints with difeerent configurations, including larger loudspeaker setups:


Extended SPRAWL System, allowing Access Points with different configurations.

Gestural Control

All three sites in the project will be equipped with a motion tracking system and multichannel loudspeaker setups, using different configurations. Experiments will aim at sharing spatial sound between the sites and manipulating them with gestural input.


21 channel Ambisonics setup with motion capturing system at BOL.

Clocking and Syncing

Another focus will be experiments with shared clocks and sequences, in cooperation with the RITMO group in Oslo: https://www.uio.no/ritmo/english/projects/dr-squiggles/index.html

We have the possibility to join the Rhythm Production and Perception Workshop for our closing concert on June 22-25.

Back to NSMI Contents

Using OSC in Pure Data

Vanilla Only

Sending OSC

The default version of PD is referred to as Vanilla. OSC can be used in Puredata without further packages, by means of the ojects netsend, oscformat and oscparse. The patch osc-send-vailla.pd sends a message to port 6666 on the localhost ( The message has the following structure and contains one float argument:

/oscillator/frequency/ [float]


Receiving OSC

The corresponding receiver patch osc-receive-vanilla.pd listens on port 6666. Using the route object, the message is unwrapped until the single float argument can be processed by the number box:



Send messages between the patches. If possible, use two computers and change the address in the send patch.

Using Externals


Sending OSC

The following example is based on additional externals. For using them, install the external mrpeach with the Deken tool inside Puredata: https://puredata.info/docs/Deken The send patch uses the hostname localhost instead of an IP address. The path /oscillator/frequency of the OSC message has been defined arbitrarily - it has to match between client and receiver. Before sending OSC messages, the connect message needs to be clicked.


Receiving OSC

Before receiving OSC messages, the udpreceive object needs to know which port to listen on. Messages are then unpacked and routed according to their path, using the routeOSC object.



Use both patches for a remote controlled oscillator. If possible, use two computers and change the address in the send patch.



  • Miller S. Puckette. Pure Data. In Proceedings of the International Computer Music Conference (ICMC). Thessaloniki, \\ Greece, 1997.
    [details] [BibTeX▼]


  • Miller S. Puckette. The patcher. In Proceedings of the International Computer Music Conference (ICMC). Computer Music Association, 1988.
    [details] [BibTeX▼]

Digital Filters

Digital filters are delay-based processing units. In short: they affect a signal by overlapping it with delayed versions of the same signal. There are two basic categories of digital filters:

FIR filters

Finite Impulse Response (FIR) filters can be considered simple convolution processors. They are implemented without recursion, respectively feedback. IIR filters are robust and easy to design, yet they are more CPU expensive.

IIR Filters

Infinite Impulse Response (IIR) filters are recursive computational structures. They are used for many time-critical operations, since they are less CPU hungry. In contrast to FIR filters, they can become unstable and may affect the signal in unwanted ways.

Both categories will be introduced in the following sections. In a detailed comparison, they show a couple of differences, both having advantages and disadvantages.