<figure><img src="image_1.png" /></figure>

HAL
open science

# Reality Check -a framework for preserving real-time electronic music realizations

Miller Puckette

► To cite this version:

Miller Puckette. Reality Check -a framework for preserving real-time electronic music realizations. ICMC2024, ICMA, seoul, Jul 2024, Seoul (Korea), South Korea. hal-05120808

HAL Id: hal-05120808

https://hal.science/hal-05120808v1

Submitted on 2 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Reality Check - a framework for preserving real-time electronic music realizations

Miller Puckette

UCSD/IRCAM

Preprint - under review

## ABSTRACT

A framework is proposed for protecting an ongoing music production using a continuous integration (CI) para-digm. An enabling technology named Reality Check is described, which has been applied so far to two existing and one in-progress electronic music production. The benefits are at least two-fold: the pieces that are included in the CI system can be monitored for their continued viability; and also, the various software components used in their realization can use the pieces as unit tests to ensure their own continued back-compatibility.

## 1. INTRODUCTION

Live electronic music has a durability problem. Any realization more than a few years old is likely to require maintenance to adjust for changes in hardware or software. Pieces of live electronic music often fall into disuse for lack of the resources necessary to keep them current. Together with fixed-medium music, pieces of live electronic music can become unavailable because of deterioration of physical media, unavailability of equipment that can read the media, and/or difficulty of deciphering proprietary file formats and disk filesystems. In addition to these problems, live electronic music faces unique challenges.

Even if we suppose that we can access the primary digital materials used in a live realization, it can easily happen that essential software components used in a live electronic realization simply disappear or become unusable because of an operating system update or a lost copy protection key. Moreover, a dependency of this sort might not be evident at the time a piece is first realized - it might be hidden in a system library, plug-in, or configuration file stored somewhere else than the digital archive that supposedly constitutes the realization.

The purpose of this paper is twofold: first, to introduce a new software framework called Reality Check that aims to help keep both an electronic realization and its supporting software available over time; and second, to argue for a cultural change among practitioners of live electronic music that can help slow the processes by which the live music repertory degrades over time.

A further affordance of this work lies in its contribution to DAFNE+, a project supported by the European Com-

mission to apply blockchain technology toward the development and versioning of collaborative artistic projects. One major problem facing this project is that items on (or pointed to from) a blockchain are fixed digital documents that could easily fall into the same time traps as any other such document. In particular, if a live electronic realization is built up over a long collaborative process among several stakeholders, the problem of ensuring the continued usefulness of the data itself is multiplied. For example, an NFT describing a realization of a piece of electronic music is worthless if the realization doesn't work. If blockchain technologies are ever to become relevant to the real art world their contents will have to offer more than GIF animations.

It will certainly not be possible for any one effort, such as this one, to permanently solve the problem of realization rot. In many situations it will simply not be possible to use the tools or ideas described here. But even to somewhat mitigate the problems we now face will be well worth the effort.

In the sections that follow we first give a brief description of recent related work; then give a functional description of Reality Check and its use both in existing and one ongoing musical production. Finally we discuss the cultural and practical issues that arise in adopting Reality Check (or another such framework) in the development and production of live electronic music realizations.

## 2. A STATE OF AFFAIRS

The rich literature that bemoans the constant falling into obsolescence of pieces in the live electronic music repertory is too extensive to even outline here[1]. Both hardware and software slide perpetually into the oubliette as new, more exciting hardware and software appear. New techniques and tools energize composers as they pursue new and unexplored musical possibilities. But pieces of "new" electronic music, once no longer so fresh, are forgotten even as they are replaced by ever newer ones. There is clearly a problem here.

A bespoke circle of hell opens up for those who turn to specialized hardware to overcome the limitations of standardized hardware. Until about 1990, for example, general-purpose processors could not approach the speeds necessary to generate anything beyond the most simple electronic sounds in real time. Composers, both in institutions and as individuals, turned to off-the-shelf synthesizers and sound processors. At IRCAM for example, there was even the idea that composers who wrote for "personal systems" such as computer-controlled MIDI synthesizers would find

Copyright: ©2024 Miller Puckette et al. This is an open-access article distributed under the terms of the Creative Commons Attribution License 3.0 Unported, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.
<figure><img src="image_3.png" /><figcaption>**Figure 1.** Reality Check block diagram.</figcaption></figure>

ware and operating system should be made at a time when the older, working system is still available and running on a different computer. If the CI test succeeds on the older system but fails on the new one, this must be corrected in the application software. In the simplest case the software simply doesn't run on the new system and needs recompiling—for which we will need the sources to all the software at play. Most of the software components will doubtless be maintained separately, but the maintainer must be prepared for some software components eventually to be orphaned. The upkeep of all orphaned components then becomes part of the task of maintaining the realization.

Second, the application software may have become available in a new version that isn't strictly compatible with the one used in the realization. The temptation here would be to keep up the older software version, but this is dangerous, since the maintainer may end up in the position of maintaining an orphaned version of the software. The more forward-looking solution would be to use the existence of the CI test itself to apply gentle persuasion to the upstream software developers to maintain compatibility. As we will see below, this can be a practical approach in the case of widely used open-source software.

Finally, the composer might want to bring changes to bear on the piece itself. There are at least two classes of alterations that might be desired. First, the piece might be customized for a new concert hall or a new performer. A new concert hall might require reworking the spatialization of the patch's audio output. In the example currently under development, we are anticipating this by using the IRCAM spatializer software ("SPAT") as a separate process, considered as part of the specific performance production and not of the realization of the piece itself.

For another example, a performer might play along with one or more pre-recorded samples or tracks of the same instrument, and it might be desirable that the recordings be replaced by those of each new performer. This and similar adaptations can be made without bringing them back into the CI system.

On the other hand, often a composer decides to revise timings or levels or other parameters that are baked into the realization itself, either during rehearsals for a new performance or in a post-mortem studio session. In this case it is appropriate to re-introduce the changes into the CI sys-

tem. And while for the later delight of musicologists we will want ot keep both the new and old versions, we can probably leave off maintaining the older version in the CI system in favor of the newer one.

## 4. TEST CASE

A production is underway for an opera, to premiere in 2025, that will certainly put this whole framework under an excellent stress test. The software components being used are Pure Data, Antescofo[6, 7], the vstplugin-Pd external object[8], and the Synful VST3 plugin[9]. Two of these systems are open-source and the other two, Antescofo and Synful, are in the process of being released in open source as well. As suggested above, the output of the realization patch is not spatialized but is instead realized as 32 audio tracks that are passed on to IRCAM's spatialization software. For purposes of testing the 32 tracks are optionally mixed down by a reference spatializer inside the Pd patch that is only adapted for a specific 6-channel speaker arrangement. There are currently only four audio inputs but as the production unfolds this will grow to about twenty. A twenty-channel DAW project will serve as a mock-up of the inputs before the actual production, and a bounce of the 20 outputs of the DAW will serve as the initial reference input for Reality Check.

Conceptually, the realization of the piece consists of a Pd patch that is already stable, plus a growing Antescofo script that constitutes the electronic "score". Since the Antescofo script is still under continuous development, it was deemed desirable to also make a test script that exercises all the elements of the patch systematically. CI tests have been built that separately verify the patch using the test script, and also verify the script for the piece itself, which last test is updated as the piece takes shape.

Along with the ongoing production, we are starting a CI regime in which the piece, along with three other pre-existing ones, are run automatically at regular intervals, thus flagging any problems that crop up. This CI system will have to be periodically updated in the future as hardware, operating systems, and software components evolve.

This regime has already borne fruit by catching, on two occasions, regressions in Pd that were since corrected, as well as calling attention to variations in floating-point rounding that are not yet resolved.
# 5. OBSERVATIONS AND CONCLUSIONS

A CI system such as this one can only work if some person or institution will take on the task of maintaining it. In our particular case, the host institution has a team of several permanent computer music designers who understand from years of bitter experience why this will be a good thing to do. Furthermore, we hope that once the procedures described here become widely used inside our own house that other centers that maintain repertories of live electronic music will adopt this or a similar methodology. If adoption is widespread enough, software developers will be able to take advantage of separately maintained CI repertories as a very useful collection of unit tests that their own software can benefit from to maintain backward compatibility.

For Reality Check or any other CI system to work in this way requires that the software components used be able to run in a virtual environment (such as inside `pd~`) and also be deterministically able to guarantee exact reproducibility of audio output from one run to another, given identical inputs. This is apparently the case for the components used in our main test case, as shown by the fact that the CI system currently passes the realization. Precisely which real-time computer music environments offer this possibility is not known.

This requirement of determinism does not forbid the use of stochastic processes in a realization, provided they rely on pseudo-random number generators, as are almost universally used in computer music software. It would nonetheless be forbidden, for instance, to use the current date or room temperature as a random seed; such a seed would have to be fixed. Certain other non-deterministic operations are also forbidden, such as measuring CPU time or querying the current OS version.

There is also the issue of truncation errors that arise from rounding in floating-point computations. In the pieces being tested so far these give variations in the audio output that are very small in magnitude and fall beneath the declared error threshold in the CI system. But running an unstable process such as a Lorenz attractor would give rise to wide divergences in output for different rounding schemes. This is currently a problem for the developers of Pd, Antescofo, and Synful to attend to.

We have nonetheless shown that a CI system can be devised that helps in the maintenance of live electronic music realizations. The system not only flags problems, but its very existence is an invitation to composers to develop their music in CI-controllable form, using deterministic and reproducible software components. It is already also useful as a tool for software maintainers to catch and correct any incompatibilities that might crop up in progressive versions of their programs.

# Acknowledgments

This work is supported by IRCAM and by the DAFNE+ project under Horizon Europe Grant Agreement number 101061548.

# 6. REFERENCES

[1] S. Lemouton, “The electroacoustic repertoire: Is there a librarian?” *array.*, pp. 7–14, 2020.

[2] M. Akkerman, “‘This hardware is now obsolete.’ Marc-André Dalbavie’s Diadèmes.” in *Proceedings of the International Computer Music Conference*. Ann Arbor: International Computer Music Association, 2017.

[3] A. Vincent, A. Bonardi, and J. Barthélemy, “Pourrons-nous préserver la musique avec dispositif électronique?” in *Sciences humaines et patrimoine numérique*, 2010, pp. 1–1.

[4] A. Bonardi, “Rejouer une œuvre avec l’électronique temps réel: enjeux informatiques et musicologiques,” 2015.

[5] J. Rudi and J. Bullock, “The Integra project,” in *Proceedings of the 2011 Electroacoustic Music Society Conference*, 2011.

[6] A. Cont, “ANTESCOFO: Anticipatory Synchronization and Control of Interactive Parameters in Computer Music.” in *International Computer Music Conference (ICMC)*, 2008, pp. 33–40.

[7] J.-L. Giavitto, J.-M. Echeveste, A. Cont, and P. Cuvillier, “Time, Timelines and Temporal Scopes in the Antescofo DSL v1. 0,” in *International Computer Music Conference (ICMC)*, 2017.

[8] C. Ressi, “[vstplugin~]–A Pd external for hosting VST plugins,” *Revista Vórtex*, vol. 9, no. 2, pp. 20–20, 2021.

[9] E. Lindemann, “Music synthesis with reconstructive phrase modeling,” *IEEE Signal Processing Magazine*, vol. 24, no. 2, pp. 80–91, 2007.