Laurens van der Wee, MMus : Independent Artist, HKU School of Music and Technology graduate, ‘t Goy, The Netherlands ; l.vanderwee@gmail.com
Roel Van Doorn, MA : Independent Artist, HKU School of Music and Technology graduate, Rotterdam, The Netherlands ; roelvandoorn@gmail.com
Jos Zwaanenburg : Conservatory of Amsterdam, The Netherlands ; zwaanenburg@open.net
Abstract
This paper reports on the reconstruction from the score of the software for Pierre Boulez’ Anthèmes 2, for violin and live electronics. This increasingly popular piece, judged by the number of performances recently, has been rebuilt from scratch for the very first time. We will put this work into context, give a short description of the composition’s electro-acoustic system, describe our approach and take a look into the future.
Introduction
If one is interested in creating live-electronic music compositions that can be performed in the future, technological issues arise. Especially when using closed-source applications, there is no guarantee whatsoever that computer programs, patches or scripts will be usable in the future. With most live-electronic music compositions however, the score is published together with a computer program.
Pierre Boulez’ Anthèmes 2 for violin and live electronics was premiered in 1997, the score [1] was published in 2005. For its performance, software can be obtained from Ircam1, however, the publication of Anthèmes 2 doesn’t include the software, instead it is possible to create software from the score, since the electro-acoustic behavior is transcribed as well. Building this software can be done by interpreting the score according to the instructions in the technical manual [2], included in the publication.
This was done with the aim to investigate whether this approach can serve as an alternative for the common practice of releasing a score together with a computer program and with the performability of live electronic music in the distant future in mind2.
The authors built a new version of the software according to the score and report on this process in this paper.
Relevant Work
Obsolescence of live-electronic music computer programs is a major issue in light of its performability [3]. This is obviously not only an issue in the case of Anthèmes 2. Other people have reconstructed historically relevant electronic music repertoire, not necessarily computer-assisted, that may be difficult to bring back on stage otherwise. These reconstructions often involve introducing computers into a certain technological setup. Many compositions use technology that at the time of conception was state-of-the-art but has become rather inefficient by now. To allow these pieces to be performed more often, computer assisted versions are developed. Of course, a lot of technological issues, as well as aesthetic and conceptual ones, arise in the process. Some of this work is documented [4,5,6,7]. [8] describes the process of increasing performability by recreating works using open-source technology.
Furthermore, tape music has also been reconstructed [9]. Also worth noting is a version of Boulez’s Dialogue de l’Ombre Double for recorder (Erik Bosgraaf) and electronics (Jorrit Tamminga)3 (the original composition is for clarinet and live electronics).
However, none of these electro-acoustic realisations are based solely on a published score.
Description of the piece
General
Anthèmes 2 is an approximately twenty-two-minute piece for solo violin and live electronics by Pierre Boulez, first performed in 1997. The score comes with a solo violin part, a régie informatique and a technical manual. In the latter, the designer of the first versions of the system, Andrew Gerzso, describes the system and how to build it ‘from the score’.
At any moment in the piece, the sound from the violin is processed in a number of ways and/or extra sound samples are played back. All this is then projected in the space over a 2D sound projection system. This serves three purposes: extending the sound palette of the instrument, extending the compositional structures, and to introduce a spatial element into the composition [2, p.10].
Processing Modules
The sound of the violin is processed by a number of digital signal processing (DSP) units. In every part of the piece a number of different combinations of units are used, resulting in the following modules:
- FS: frequency shifter;
- FSD: frequency shifter with delay;
- 6FS: six frequency shifters;
- 6FSD: six frequency shifters with delay;
- 2RMC: two ring modulators mixed to one comb filter;
- IR: ‘infinite’ reverberation;
- HR: harmoniser;
- 2HR: two harmonisers;
- 4HR: four harmonisers;
- HRD: harmoniser with delay;
- 4HRD: four harmonisers with delay;
- S: sampler;
- S-IR: sampler with infinite reverb.
The latter two do not transform the violin sound but rather play back pre-recorded violin samples and sinusoids.
There is a maximum of six simultaneously playing modules that are routed to so-called ‘sources’ that go into the spatialisation system.
Sound Projection
Systems Used
According to the manual, the original version uses a six-speaker setup, plus extra speakers for the amplification of the violin sound. This six-speaker setup is basically an equally distributed eight-speaker surround setup with the front and rear speakers omitted. The latter two positions are also referred to in the score and moving sound will pass through these positions. The spatialisation system used in the original version [10] compensates for these gaps.
Movements
Besides the six main positions—front-left (FL), middle-left (ML), back-left (BL), back-right (BR), middle-right (MR) and front-right (FR), the score prescribes a number of standardised movements:
- choose a random position from the main positions;
- choose a random position from a specified group of positions;
- choose a random position from the main positions every n milliseconds until further notice;
- go from B to F in a continuous movement, either via BL-ML-FL or BR-MR-FR;
- start a rotation in a random or specified direction of a specified length, starting from the current or a specified position;
- sweep back and forth between two positions in a specified time until further notice.
The Perception of Space
The technical manual describes an approach towards the perception of space in which the composition doesn’t imply a specific speaker layout. It does so by introducing three main parameters, i.e. direction, presence in terms of distance and presence in terms of the perception of space. The previous may be true for direction, the latter two, however, are translated to more technical terms: direct sound, early reflections level, reverberation level and reverberation time, all of which are used as compositional parameters in the piece. So instead of composing with explicitly defined distance and space, leaving the implementation to the system designer, technical parameters are used compositionally, as with the processing system, and a specific approach towards reverberation is explicitly defined.
Imagine the use of for example Wave Field Synthesis (WFS) [11], as suggested in the technical manual [2, p.3]. In this system, the perceived distance is created in an entirely different way, one could even say that it’s the raison d’être of WFS (the description of which goes beyond the scope of this text). Distance, however, is not a parameter in the score, it results from the reverberation settings. Consequently, the algorithms in WFS responsible for distance will be hardly of use and the WFS system will be using only a small part of its resources. Hence we feel that the spatialisation of this piece is about surround projection, compositionally but also to some extent technically, and that it isn’t as setup-independent as the technical manual suggests.
Cueing
In the score, every time a parameter change happens (meaning that processing module or spatialisation settings are changed or running dynamic processes are stopped), a cue is notated. Cues serve as a way of telling the system ‘where we are’. This can be done manually (button, keystroke or mouse click, for example), however, for a number of parts of the composition score following [12,13] is necessary [2, p.5].
Existing Versions
The Original Version
The very first version, which was used for the premiere at the Donaueschingen Festival in 1997, employs a NeXT computer with three ISPW processing boards running at a 32 kHz sample rate, running Max 0.26, and controlling an AKAI sampler. Already here, a version of Spatialisateur [10] was used.
Shortly after, a new version was built, running jMax on two Silicone Graphics Octane bi-processor computers, interconnected via MIDI. This version was used until 2004 and for recordings for Deutsche Grammophon.
In 2005 a third version saw light: two Apple G4’s, connected via Ethernet for control syncing, running Max/MSP 4.5. More versions would follow and at least from 2008 on, the system ran on just one computer.
For quite a long time, IRCAM has been working on the development of score-following systems, now known as ANTESCOFO [14], versions of which are used in the different original systems. System updates for Anthèmes 2 and the development of ANTESCOFO go hand in hand and (parts of) Anthèmes 2 are used for tests and demonstrations4.
Our Work
In November 2007 we started working on our first version of the software. This was done in the context of our internship at the Conservatory of Amsterdam (CvA). In February and March 2008, we put on stage two performances, the last one at the Expert Meeting at the CvA, organised by Jos Zwaanenburg. Later that year, in December, we performed it twice more. After this the project ended, for other projects took over our attention. In 2015 we started working again, aiming to put on a series of performances, once more with Marleen Wester. The plan is to investigate the current versions and performance practice, review our work from 2008, and finally start work on a new version, addressing issues such as performability, proprietary software, workflow and system design.
First Remake
As mentioned above, our version is the first, and as of yet only, alternate version of the software for Anthèmes 2. In this section we will describe the several components of our system and the setup we used.
We would like to emphasize that we built the system as part of our internship as undergraduates. References to existing techniques in this paper are made in retrospect. In reality, everything was built with our best knowledge of that time, without paying much attention to existing work, other than the programming environment that we worked in.
Framework
The system is built in Max 5. See Figure 1 for an overview. In the process of building it, we found out that we needed to split the system over two computers. We decided to run the main system, including processing and score following, on the master computer, the second computer runs the spatialisation, listening to control messages from the master. This communication runs over an Ethernet connection. Both computers are equipped with a MOTU828 audio interface, interconnected with ADAT.
A maximum of six sources sound simultaneously. We also made the amplification of the violin part of the system, so a total of seven sources are defined, meaning that seven channels of audio are sent to the spatialisation computer.
During performance, a human being, called the supervisor, keeps an eye on the system and interferes whenever necessary.
For the violin sound we used a DPA clip-on instrument microphone. We also introduced a Schertler contact microphone in the bridge of the violin for the score following to minimise the influence of disturbing environmental sounds or sound from the speakers feeding back into the microphone.
In early versions we worked with a foot pedal used by the violin player to advance sections. This didn’t work so well for the violin player, since it distracted her from her playing, so we decided to let the supervisor control this. To make sure there could be no misunderstanding about whether the system was ready for the next section, we introduced a little LED at the bottom of the music stand that turns on when the system is readily waiting for the violin to start and turns off consequently.
In terms of cueing we made a distinction between cue changes and section changes. On section change, the processing system, the spatialisation and the score following load new parameter data corresponding to that section’s cues. Also the processing modules’ output signal routing changes (but stays static for that section). Cue changes are generated by the score following and sent to the processing system and the spatialisation and are also used by the score-following system itself.
For rehearsal purposes we extended the system so one can skip to any cue at any time. This turned out to be of great importance to make the rehearsals a success. We would even go as far as to say that this should be a requirement for any such system.
Processing System
The processing modules mentioned in section 2.2 are implemented in separate patches. Using the Max poly~ object, processing modules that are not in use are turned off to save CPU power. The outputs of the processing modules are routed to one of the seven sources mentioned, according to the schematics in the technical manual [2, p. 5-8].
Score Following
An overview of the score-following system is shown in Figure 2.
For the score following we use the Schertler input. This is preprocessed by running it through a spectral gate. Since we don’t use this signal for any purposes other than score following, the reduction of audio quality due to this processing is no issue.
In order to achieve an accurate score following system, several methods of detection are stacked. The score following detects cues through the detection of volume or pitch changes.
Because of the preprocessing, attack detection can be very accurate. Some sections, however, have cues that are in the middle of a series of bowed notes, reducing effectiveness of attack detection. For these cues a pitch comparison algorithm is used. If a detected pitch falls within a predefined range, a cue is sent. In some cases, we needed to define a series of pitches to be detected to reduce the chance of a detected cue before the related note is played. Pitch detection was implemented using the, now obsolete, fiddle~ Max external. Only specific sections make use of pitch detection, most cues can be accurately detected using just attack detection.
Furthermore, detection is only allowed within set timeframes. This is implemented using an opening and closing gate. The timing of this needed to be defined beforehand. To achieve this, the complete violin part was recorded, and all cue data was entered in an audio editor. A simple export of these cues resulted in the complete temporal data of all cues. These files were made relative, i.e. every cue time was counted not from the beginning of a section but from the previous cue.
In practice, the speed with which sections are played changed during the rehearsal period. Therefore, timed detection gates weren’t accurate anymore. This was compensated for by introducing a scaling factor for each cue. This is comparable to the virtual vs. real-time mechanism described in [13].
On top of these different detection layers, there is the manual layer, i.e. the control of the score following by the supervisor. Although the detection is programmed to be accurate, there is always the chance of a glitch or wrong choice of the computer program. During the performance, the supervisor is responsible for following the score and making sure the cues are sent correctly. This can be done by closing another gate to stop detected cues. This gate comes after all other gates and detection. Several shortcuts on the keyboard are programmed to either hold back any detected cues or send a cue if a cue is missed, so everything is again synchronised.
It has never been the intention to use the score following without a supervisor. Although in some situations this system is operating very accurately, especially the attack detection, a supervisor knowing and following the score is necessary [15] to make definite choices.
Spatialisation
Nature of the System
The spatialisation system was built completely from scratch because we felt that to challenge the intentions of the authors, we should not use existing algorithms. Also, we based our design on the instructions in the score rather than on ideas of what comprises a complete, versatile spatialisation algorithm.
Speaker Setup and Amplification
We use a classic eight-speaker setup, mainly because the eight speaker positions are explicitly used in the composition (including front and back) as directional parameters.
We also decided not to amplify the violin sound over separate speakers but to mix this with the signal coming from the front-left and front-right speakers. In practice, we found that not every performance needed the amplification.
System Design
For each source a series of speaker output levels is calculated, based on the position parameter. A cosine envelope function is used for equal power distribution and a width factor has to be defined. The greater the distance between speakers, the bigger the width factor has to be to result in a correct distribution of the sound. Hence the necessity to be able to adjust this setting before performance, depending on the room in which the performance takes place and the way the speakers are set up.
The movement types are preprogrammed. Based on the list in section 2.3.2, a total of twelve movement types are defined, which are used to project the sources, according to cue information.
Conclusions
Reconstructing the software based on this score worked out really well in this case. We were able to compare our work with the IRCAM version through attending a concert at the Louvre Museum in Paris on November 21st, 2008. Although this cannot be called an objective observation in any way, we still think it’s worth noting that in our opinion our version wasn’t inferior at all. This success is of course partly due to the quality of the score and the clarity of the descriptions and instructions in the technical manual.
In terms of preventing live-electronic music computer programs from becoming obsolete, it’s hardly possible to make generalisations about the validity of the described approach, simply because this paper only describes one successful attempt at one composition. This work therefore cannot serve as proof that the approach suggested with the publication of the score of Anthèmes 2 is a feasible one per se. Nevertheless, we think it deserves more attention from the side of publishers and promoters, as well as composers and developers, to enable an informed appreciation of this approach.
Future work
Our ambition is to make a new version of Anthèmes 2’s software, using a truly open-source musical programming language, to address compatibility issues and perform with this in a series of concerts. It may also be an interesting experience, because both existing versions (the original Ircam version and ours) are built in Max.
Acknowledgments
We would like to thank Marcel Wierckx for his continuous support and advice, the Utrecht School of Music and Technology and the Conservatory of Amsterdam, the kind people at Ircam for their feedback and encouragement, Sjoerd van der Sanden for joining the team in 2007/2008, and last but not least Marleen Wester.
Our thoughts go out to friends and family of Pierre Boulez, who passed away on January 5th, 2016.
References
[1] P. Boulez, “Anthèmes 2”, Universal Editions 31160, 2005.
[2] A. Gerzso, “Anthèmes 2 – technical manual”, Universal Editions 31160b, 2005.
[3] M. Puckette, “The Deadly Embrace Between Music Software and its Users.”, Keynote address at the EMS Network Conference, Berlin, 2014.
[4] X. Pestova, M.T. Marshall and J. Sudol, “Analogue to digital: Authenticity vs. sustainability in Stockhausen’s MANTRA (1970).”, Proceedings of the International Computer Music Conference, Belfast, 2008, pp. 201-204.
[5] C. Burns, “Realizing Lucier and Stockhausen: Case Studies in the Performance Practice of Electroacoustic Music.”, Journal of New Music Research, 31.1, 2002, pp. 59-68.
[6] A. de Sousa Dias, “Case studies in live electronic music preservation: Recasting Jorge Peixinho’s Harmónicos (1967-1986) and Sax-Blue (1984-1992).”, Journal of Science and Technology of the Arts, 1.1, 2009, pp. 38-47.
[7] R. Esler, “Digital Autonomy in Electroacoustic Music Performance: Re-Forging Stockhausen.”, Proceedings of the International Computer Music Conference, New Orleans, 2006, pp. 131-134.
[8] M. Puckette, “New Public-Domain Realizations of Standard Pieces for Instruments and Live Electronics.”, Proceedings of the International Computer Music Conference, San Francisco, 2001, pp. 377-380.
[9] O. Baudouin, “A reconstruction of Stria.” Computer Music Journal, 31.3, 2007, pp. 75-81.
[10] J-M. Jot and O. Warusfel, “A Real-Time Spatial Sound Processor for Music and Virtual Reality Applications.”, Proceedings of the 1995 International Computer Music Conference, Banff, 1995, pp. 294-295.
[11] A.J. Berkhout, D. de Vries and P. Vogel, “Acoustic Control by Wave Field Synthesis”, The Journal of the Acoustical Society of America, 93.5, pp. 2764-2778, 1993.
[12] B. Vercoe, “The Synthetic Performer in the Context of Live Performance”, Proceedings of the 1984 International Computer Music Conference, Barcelona, 1984, pp. 199-200.
[13] R.B. Dannenberg, “An On-line Algorithm for Real-Time Accompaniment”, Proceedings of the 1984 International Computer Music Conference, Barcelona, 1984, pp. 193-198.
[14] A. Cont, “ANTESCOFO: Anticipatory Synchronization and Control of Interactive Parameters in Computer Music”, Proceedings of the 2008 International Computer Music Conference, Belfast, 2008, pp. 33-40.
[15] M. Puckette and C. Lippe, “Score Following in Practice”, Proceedings of the 1992 International Computer Music Conference, San Jose, 1992, pp. 698-701.
Notes
- Referred to in this paper as the ‘original version’. ↩︎
- This was confirmed in an email to the authors by Andrew Gerzso. However, no such intentions are described in the score or in the technical manual. ↩︎
- Published on Brilliant Classics, nr. 94842BR. ↩︎
- http://forumnet.ircam.fr/user-groups/antescofo/forum/topic/antescofo-getting-frankly-polyphonic ↩︎
