Prisma class hierarchy, Chroma polymorphism, Multi Spat Delay

In our last session we reviewed the multi-tier architecture of OMPrisma, providing an abstraction layer to separate the process of spatialization into stages for Authoring, Rendering, and Decoding.


Separation of Spatialization Process into Authoring, Rendering and Reproduction, using dedicated environments.


This approach provides an abstraction layer which allows for the rendering of alternative realizations of the same spatial sound scene using different spatialization techniques and loudspeaker arrangements.

OMPrisma class-hierarchy

This abstraction layer is realized using a class inheritance system (in terms of object-oriented programming) in which slots (corresponding to synthesis parameters) are inherited from “abstract classes” to construct concrete spatialization classes, implementing a specific spatialization technique.



As every spatialization process starts with a sound to be spatialized, all spatialization classes in OMPrisma share the same interface (and dsp implementation) for sound file playback. We discussed the parameters for controlling sound file playback using a tabulated representation and visualized/compared it to conventional graphical timeline-representation as used in Digital-Audio-Workstations or Wave-editing applications.

Timeline Representation of a sound scene containing two sources controlled via parameters of an OMPrisma class.


We then programmed the graphical example for sound file playback using an OMPrisma class. We also had a closer look at the synthesize function, in particular the use of keywords to control  synthesis parameters of Csound, such as:

  • kr (control rate)
  • sr (sampling rate)
  • rescale (value in dBFS for normalization)
  • resolution (bitdepth)

By setting the keyword run to nil, synthesize won’t call Csound to render the audio file, but instead return a list with two paths, i.e. to the orchestra and score file, respectively. This allows to visualize and study the synthesis instructions directly in OpenMusic.

Polymorphism of OMChroma matrix

We studied the structure of the OMChroma matrix, which can be thought of as a 2D-array (table). More specifically, we discussed  global slots, local slots (which correspond to Csound p-fields), and additional keywords.


We looked into the polymorphism of slots of type number, which allows to set the contents of the matrix not only using literal, but also functional and symbolic specifications. Dependent on the type of input, the semantics were:

  • number – gets repeated for every column of the matrix
  • list – if less elements than columns in the matrix the list gets repeated until the values of all columns have been filled. If more elements than columns in the matrix, it gets truncated
  • bpf - gets linearly resampled over the columns of the matrix


After some experimentation and examples we programmed an musical application: a Multi-Tap-Spatial-Delay using just a single pan.discrete OMPrisma class. We then used simple arithmetic functions in OpenMusic to create a Spatial-Beat-Shuffler which segments and re-arranges and spatializes individual segments. You can find these applications in the example patches on the Ilias server.





In our next session, we are going to introduce classes for dynamic spatialization, i.e. moving sound sources and apply perceptual cues that create a sense of auditory distance. As the next assignment, please write a short resumé about the seminal paper by John Chowning, titled “The simulation of moving sound sources”. Please submit the resumé before Thursday, January 28. You can find the article on the literature list.