MODERNISING LIVE ELECTRONICS TECHNOLOGY IN THE WORKS OFJONATHAN HARVEY

Jamie Bullock and Lamberto CoccioliBirmingham Conservatoire

University of Central EnglandBirminghamB3 3HG, UK

ABSTRACT

Many twentieth century works composed for instrumentsand live electronics are seldom performed due to their useof near obsolete technology. Some performing bodiesavoid such works because the necessary technology iseither unavailable or too expensive to hire. This paperdescribes the current status of a project to modernise thetechnical aspects of Jonathan Harvey's works in order toincrease the likelihood of performance and improvelongevity. The technical and ideological implications ofthe project are discussed in the context of a broader needfor the preservation of contemporary works involvingtechnology. The use of open source software and standardprotocols is proposed as a way of reducing technologicalobsolescence. New solutions for two of Harvey's worksare proposed, and discussed in relation to the problemsencountered with the project so far. Conclusions are thendrawn about the current status of the project and itsimplications for further work.

1. INTRODUCTION

As they have been invented, new forms of electronictechnology have been incorporated into new musicalworks as an addition to and expansion of traditionalmusical resources. Cage's Imaginary Landscape (1939)for variable speed turntables and Messiaen's Fête desBelles Eaux (1937) for six Ondes Martenot are some ofthe earliest examples of this. Through the second half ofthe twentieth century, composers continued to utilise newelectronic technology as it became available, to the extentthat a significant historical canon has now emerged.However, whilst the musical scores for many of theseworks are relatively easy to obtain and use, thetechnological elements are sometimes impossible torealise because the technology is nearing obsolescence.Many works of the 'eighties, for example, used hardwareFM synthesisers and samplers, and although softwareequivalents for these are now available, the media formany works have not been revised.

Another problem facing performers is the lack of clearand complete documentation regarding the technicalimplementation for a work. In a recent performance of acanonical piece for percussion and live electronics atBirmingham Conservatoire, several hours of rehearsaltime were wasted working out how real-time control datawas to be mapped onto sample playback parameters. Thiscould have been avoided if clear instructions had beenprovided with the score.

In other cases equipment is too expensive to hire, tooesoteric to be quickly set up, or unreliable due to its age.Some of the larger scale works from the 'eighties requirethe original and unique equipment for which they werecomposed, and a technical team to operate the equipment.

The problems associated with obsolescence in worksinvolving electronics are often exacerbated by theambivalence of composers to the longevity of their work.In a survey about the “Record Keeping Practices ofComposers” [1], Longton concludes that out of 161composers questioned, “almost half (47 percent) ... lostfiles they considered valuable due to hardware or softwareobsolescence.” He continues to conclude that the lack ofconcern for preservation (of their work) indicated byresponses to his questionnaire reflects the fact that“composers have not historically had to concernthemselves with preservation.” He also notes that 76percent of composers questioned used commercialsoftware and that this will be “important to rememberwhen considering how preservation strategies will affectthis community.”

There have been few attempts so far to address theseissues. Even when using software-based systemscomposers are often poor at record keeping. Whilstaccurate score production is a requirement of instrumentalperformance, the composer often performs their own liveelectronics part. In these cases, the composer's ownknowledge reciprocates the documentation, making theneed for clear instructions less immediate.

In his paper on “New Public-Domain Realizations ofStandard Pieces for Instruments and Live Electronics” [2],Puckette outlines a method and rationale for performingcanonical works “without resorting to special hardware orproprietary software”. He describes how the liveelectronics elements for four historically important workswere revised and modernised using PD (Pure Data)software running on a Linux PC. Puckette discusses thepractical need for more cost effective and widely availableperformance technologies, and suggests that realisationsbased on open source solutions might be “longer lastingthan previous realizations have been”. In addition to thisthe notion of a PD realisation as a musicological andpedagogical model is discussed, along with the need forfreely available standards-compliant documentation.

Some of the broader issues concerning the modernisationof canonical works and the portability of technology are

being addressed by Integra1, a new and unique projectfunded by the European Commission and currently beinghosted by Birmingham Conservatoire. Integra - 'AEuropean Composition and Performance Environment forSharing Live Music Technologies', seeks to form linksbetween academic organisations and performing bodies inorder to solve performance problems regarding worksinvolving live electronic media. In this paper we willdescribe a specific project for modernising the liveelectronics elements in the works of Jonathan Harvey.

2. PROJECT MOTIVATION

The project began with a discussion with the composerconcerning his requirements, and after various meetings alist of priorities was established. The list included 14pieces requiring a broad range of technicalmodernisations. These included the replication of a VCS3synthesiser in software and the re-writing of mixing deskconfiguration data for modern consoles. However, themajority of problems fell into two broad categories:sample playback and FM synthesis. Of the 14 worksoriginally discussed with the composer, 12 are ofparticular relevance. The work for the project thereforeconsists of modernising the primary technical elements ofthe following works (in order of descending priority, asagreed with the composer):

1. Madonna of Winter and Spring (1986) – YamahaTX816 and DX1, E-mu II, ring modulation andreverberation;

2. Wheel of Emptiness (1997) – E-mu E-64 samples onZIP;

3. White as Jasmine (1999) – two Yamaha SY77patches (already ported to Native Instruments FM7);

4. Soleil Noir/Chitra (1995) – SY77 and Eventideharmoniser;

5. Ashes Dance Back (1997) – CD player, two E-mu E-64 digital samplers, five-octave keyboard controller,ZIP drive, effects processor (Yamaha SPX 990), four-channel spacialisation;

6. From Silence (1988) – Yamaha DX7 patch (alreadyported to FM7);

7. Valley of Aosta (1988) – DX7 and Steinberg Pro24 onAtari ST;

8. Inner Light 2 (1977) – VCS3 synthesiser;9. Inner Light 3 (1975) – four-track tape;10. Gong-Ring (1984) – ring modulator;11. Inquest of Love (1992) – SY77 and two DX7s, ring

modulation, artificial reverberation, and hardware-based sampling,

12. Calling Across Time – SY77, hardware-basedsampling.

It is pertinent that two of the 12 works on the composer'slist have already been updated using proprietary solutionsand need further updating.

3. IDEOLOGY

Having considered Harvey's requirements, thought wasgiven to how the technical and aesthetic needs of theworks might be met with new technological means. Thetwo options that seemed most suitable were Max/MSP and

1http://www.conservatoire.uce.ac.uk/integra

PD. There are clear and successful precedents for the useof these applications in works with live electronics, and itwas decided that either package could meet the technicalneeds of the project. However, after careful consideration,the decision was made to use PD due to the fact that isfree, has better cross-platform portability, and is unlikelyto suffer from commercial restrictions such as companybankruptcy.

The use of PD avoids adding software purchase toperformance costs. PD runs on most modern platformsincluding MacOS, Linux, Unix and Windows. Even if theperforming body had to purchase a new PC specificallyfor performing a work by Harvey, a feasible performance-ready system could be set up for under £4002, whereas thelicense for Max/MSP alone costs $495(£260).3 An opensource solution has therefore been chosen because it meetsall of the requirements for modernising the technologicalelements, in the most cost effective manner .

PD (like Max/MSP) uses ASCII text files to store patchdata, and therefore files can easily be distributed. Anyexternal files used for the project, such as audio files, ordocumentation files, will be converted to formats forwhich the specifications are known and available. WAVformat will be used for all audio, because it is supportedby a wide range of software and platforms, and because ithas 'built in' facilities for setting up loops. It is also thesample data file format used by modern Akai samplers.All documentation will be produced in plain text or html.

The intention of the project is to modernise the technologyand media used for performance whilst keeping theperformance experience perceptually consistent for bothaudience and performer. Consideration has been given tothe notion of using sampling techniques rather thanresynthesis in order to replicate the sounds required forHarvey's works. This method has several advantages; it isquicker and easier in the short-term, it guarantees faithfulreproduction of the timbral qualities of the originalsounds, and it simplifies the process of performing furtherupdates (soundfile format conversion for example).However, whilst it seems reasonable to adopt thisapproach on a short term basis or for occasions wherethere is insufficient time to emulate the originaltechnology, it may not be so useful in the long term. Thefirst reason for this is that although creating a successfulemulator with software (a DX7 emulator in PD forexample) has a greater initial 'time cost', once the initialwork has been done the process of importing data(existing patches) is relatively fast. Adopting a sample-based strategy would always require the same process ofobtaining the relevant hardware and sampling each soundfor every piece. The second reason why this is onlyconsidered to be useful in the short term, is that it fixes theevolution of the sounds over time and restricts interactionbetween the electronics and performers. This isparticularly relevant to changes in tempo, where timbralchanges in a sampled sound might not be reproduced withthe correct proportions should a performer choose tochange the tempo of a piece.

2Price from DABS.co.uk as of 01/03/20053Price from Cycling74.com as of 01/03/2005

4. WHEEL OF EMPTINESS

Wheel of Emptiness1 is a work of approximately sixteenminutes duration, for sixteen players. It utilises an E-muE-64 sampler and a keyboard controller for triggeringsamples at various points in the work. This was the firstwork to be attempted, partly due to requirements for twoperformances, one in Berlin, and one by the BBC ScottishSymphony Orchestra in Glasgow.

The first stage in modernising the E-64 samples was tomake copies in E-IV format using an E-mu ESynth rack-mount unit. This meant that the samples could be readwithout conversion by a wide range of samplers. The E-IVversions of the patches were 'performed' against a goodrecording of the piece, to ensure that the sound wasperceptually identical to the E-64 versions. Several copieswere made onto fresh ZIP disks and checked forconsistency before being sent to the publishers for archivalpurposes.

Various attempts were then made to read the E-IVformatted disks using software, such as CDXtract2 on bothMac and PC platforms. This was unsuccessful, and due toan incompatibility between the SCSI I interface used bythe Esynth, and the SCSI III interface on the computer'sPCI card, the data could not be transferred directly to thecomputer's hard drive. The solution was to use an AkaiS5000 sampler as a translator to convert the samples intoAkai S5000 format. The S5000 uses WAV files to storesample data, and a proprietary file format to store Patchand Bank data. This meant that transferring the sampledata into PD was trivial. However, in comparing theoriginal E-IV Patches to the converted Akai versions,various significant discrepancies were noticed. Inparticular, none of the filter settings had endured thetransfer. It was therefore decided that given the timeconstraints, the Berlin and Glasgow performances of thework should use the E-IV versions of the files. In futurefurther conversion software such as Chicken System'sTranslator3 will be investigated in order to simplify andoptimise the Sample file conversion process.

The next problem posed by the project was how totransfer the E-mu patch performance data into PD so thatinformation such as velocity curves, panning andkeygroups could be preserved. Copying the information'by hand' seemed neither appealing nor beneficial forfuture work, and since the information (other than filtersettings) had endured the transfer onto the Akai S5000, itseemed sensible to start with the Akai copies. Thespecification for the AKP (Patch) file format has been'reverse engineered' by several developers, and can befound on the Internet. It was therefore decided that a PDAKP reader would be set up in order to facilitate thetransfer of the patch settings into PD. This was consideredto be a useful resource, not only for the Harvey project,but for anyone else needing to transfer Akai performancedata to PD. Work on writing the PD AKP patch iscurrently in progress, and should be complete bySeptember 2005.

1Harvey, J., Wheel of Emptiness, London, UK, Faber Music, 19982http://www.cdxtract.com3http://chickensys.com/home.php

The more difficult element of the transfer of the E-mu IVsamples into the PD environment is the modelling of E-mu's patented z-plane filters4. These filters allow the userto set the centre frequency, bandwidth and gain for 7 filter'sections' and then smoothly 'morph' between differentsets of coefficients. The morphing and settings can becontrolled in real time by user defined function curves orexternal control data. Harvey used the filters quiteextensively to 'shape' his material, so any copy of thefilters made in PD needs to be perceptually identicalwithin the context of the musical work.

Initial experiments have now begun into emulating the E-mu z-plane filters in PD. Unlike the conventional use ofthe term z-plane in filter design (as used to refer to thecomplex plane) E-mu's documentation uses the term todescribe a complex filter with the facility to interpolatebetween various preset coefficient sets. This z-axisinterpolation is controlled by a single 'morph'5 parameter.Some initial attempts to emulate these filters wereconducted using cascaded instances of PD's internalbiquad~ object, but this approach was consideredunsuitable due to the lack of audio rate control formodulating coefficients in real time. Instead experimentshave begun using the wide range of filters from theIEMLIB6 external library.

Consideration has also been given to using E-mu's ownEmulatorX software, which can import E-64 samplesnatively. However, this would mean replacing aproprietary piece of hardware with proprietary softwarethat even requires further proprietary hardware (from E-mu) in order to run. This option was therefore consideredunsuitable.

5. MADONNA OF WINTER AND SPRING

This was the second work to be attempted. It is a work fororchestra, incorporating synthesiser, sampler and ringmodulator, and lasts approximately 37 minutes. It uses aYamaha TX816 for synthesis, a DX1 for controlling theTX816, and an E-mu II sampler for sample playback. Asthe E-mu II does not use the same operating system (EOS)or file format as the E-64 and E-IV, an alternative methodis required for converting the sample and performancedata. In order to proceed, an Emulator II needs to beobtained so that further investigations can be conducted.

The TX816 patches for Madonna of Winter and Spring7

were provided on a Macintosh HFS formatted floppy diskalong with a patch librarian called DxEd. Unfortunatelythe librarian's 68k binary file wouldn't run on a G3running OS 9. There are however various open sourcelibrarians for the windows platform that can read TX816patch files, including Papareil Synth Labs SynLibsoftware8. There is also an existing open source DX7emulator called Hexter9. The rx7~ PD external, based onthe code from which Hexter is derived, is broken and doesnot work. Work is therefore in progress to make a PD

4US Patent 517695As described in the EOS 4.0 manual (available at http://www.emu.com/)6http://iem.kug.ac.at/pd/iemlib/7Harvey, J., Madonna of Winter and Spring, London, UK, Faber Music,19868http://m.bareille.free.fr/synlibdxtx/synlibdxtx.htm9http://dssi.sourceforge.net/hexter.html

object based on the Hexter code. The PD object willemulate a DX7, so that multiple instances of the objectcould be used to emulate a TX816. A PD patch will thenbe created, which reads data from the patch bank files anddirects it to the appropriate instance of the Hexter object.It is anticipated that this work will be completed byJanuary 2006.

Because many of Harvey's other works use similartechnology, once Madonna of Winter and Spring hasbeen completed, the process of modernising additionalworks should accelerate. Furthermore, works by manyother composers utilise Yamaha DX7-based technology.The aim of the project is therefore to make the process ofimporting patches and emulating synthesis in PD astransparent and straightforward as possible.

6. PROJECT DIARY

A project diary is being maintained as an online weblog1.This is a log of all work undertaken, problemsencountered and a running list of priorities alongside anyworking documents and files. The aim is that thedocumentation should be sufficiently detailed for anoutside party to take over the project at any time. The logis made available to all involved with the project via apassworded web link, and has the facility to be set up asan XML RSS feed if required. Because the project is in itsearly stages, and only preliminary research has beenconducted, it is currently not feasible to give detailedtimescales for project completion. However, it is believedthat the decision to base development work on opensource solutions should increase development timesignificantly. This is partly due to the availability ofshared knowledge within the open source community, andpartly due to the availability of existing solutions that canbe adapted rather than re-invented. Likewise contributionsand feedback are welcome from interested parties.

7. CONCLUSIONS

In terms of measurable outcomes, the project has so farconcerned itself with service provision to external bodiessuch as the BBC Scottish Symphony Orchestra (viaHarvey's publisher). This work has consisted of mediaformat upgrades and media duplication. This is preciselythe sort of work that the project seeks to avoid. Allmaterials should eventually be available online from thepublisher and run successfully on standards-complianthardware without modification. The project is currently inits early stages, but once the facility is available to importDX and TX series patches into PD running an emulatorobject, and it is possible to import Akai S5000 samples,with their preset data, it should be far quicker to updatenot only Harvey's works, but works by other composersthat employ the same technology.

8. REFERENCES

[1] Longton, M., “Record Keeping Practices ofComposers”, InterPares 2 website at<http://www.interpares.org>, accessed March2005.

[2] Puckette, M., “New Public-Domain Realizationsof Standard Pieces for Instruments and Live

1http://www.conservatoire.uce.ac.uk/harvey

Electronics” Proceedings of the InternationalComputer Music Conference, Miami, USA,2004.