This document describes how to use the soundfile comparison tool from the Reality Check package to test Max realizations. The procedure is more laborious than for Pure Data and as yet is not in active use for any of IRCAM’s currently maintained realizations, although there is an informal test of Serge Lemouton’s Max patch for Jupiter (Philippe Manoury, 1987).
For a variety of good reasons, many more piece of electronic music are realized in Max than in Pd. With some difficulty, the tools provided here can be adapted to verify Max realizations - and perhaps realizations in other environments as well - we won’t go into that here, but what follows could probably be adapted to Supercollider or real-time Csound for instance, by anyone needing to do so.
In any of these environments it will be essential to find a way to run the piece deterministically. In the case of Max (version 8 at least and probably 9 as well), this can be done by running it under Ableton Live to “bounce” the output of the realization to a soundfile. During a “bounce” the entire Ableton Live project runs out of real time, and Max is made to passively run in Ableton’s virtual time. Since “bouncing” should, for practical reasons, be a repeatable process, the Ableton scheduler is written to be deterministic when making a bounce.
The testing procedure is thus to bake the Max realization into a Max for Live device (an “amxd” file) that appears in an Ableton track as a plug-in. The track’s audio input is the audio input to the Max patch, which can be pre-recorded and placed in the track for treatment by the plug-in.
The piece will doubtless have various interactive inputs, not least a button to “start” the piece. These are encoded in a separate Ableton MIDI track that is sent to the plug-in. Most likely the Max patch for the piece will be embedded in another patch that translates MIDI messages to whatever Max messages the realization patch responds to. Moreover, the realization patch will require Max subpatch inlet and outlet objects that mirror the adc~ and dac~ objects so that the translation patch can send and receive audio as if it were the real world the realization patch would normally run in.
Here is an example of how to set up the Max patch:
The piece is assumed to start and progress based on incoming max messages, in this case the messages “start” and “next”. Audio I/O uses the usual “dac~” and “adc~” objects, but they are doubled by Max inlets and outlets so that a controlling patch can use it as an abstraction. The Ableton project then looks like this:
It contains a Max “device” that calls the piece as an abstraction and responds to MIDI messages by starting a qlist that sends teh piece “start” and “next” mesages as desired. In this example the qlist in the Max device contains these lines:
start bang;
2000 next bang;
1000 next bang;(The piece itself has its own qlist that defines the actions to be taken, whic contains startup messages plus two events.) The Ableton project’s audio trck contains the presumed instrumental input - in this test project, a constant sinusoid.
Once this is set up, bouncing the track’s output (using the “export” menu utem in Ableton) creates a soundfile with the piece’s virtul audio output, which can then be checked against a previously prepared control output. Reality check provides a pd patch to make the comparison, which appears in the release as “2.compare-soundfiles.pd”. This can be run on the linux or MacOS command line, thus:
pd -batch -nosound -nrt -noprefs -r 44100 \
-send "run-batch control.wav new-output-wav" 2.compare-soundfiles.pd(On Mac, replace “pd” by “[…]/Pd[…].app/Contents/Resources/bin/pd”.) This will return success or failure depending on whether the two soundfiles match within a tolerance defined in the comparison patch - currently, one LSB at 16 bit precision.
This work has received support from UCSD, IRCAM, and the DAFNE+ project under Horizon Europe Grant Agreement number 101061548.