DOCSLIB.ORG

Systems Level Liveness with Extempore

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Systems Level Liveness with Extempore Systems Level Liveness with Extempore Andrew Sorensen Henry Gardner Research School of Computer Science, CECS, Research School of Computer Science, CECS, The Australian National University The Australian National University Canberra, ACT 0200, Australia Canberra, ACT 0200, Australia [email protected] [email protected] Abstract real time: with physical systems such as loud speakers Live programs can be modified while the program is and digital musical instruments, with other Live Coders, executing in order to provide a more reactive experi- with conventional musicians and with streaming media. ence for the programmer. In demanding applications, Systems support for Live Coding has achieved a high such programs traditionally utilise pre-defined function level of sophistication in order to meet the computa- calls to compiled libraries. We present a system that tional demands of professional-level audio production enables demanding live programs to be built where the and equipment. The concerns of these systems are at supporting stack of libraries is, itself, live. In such sit- the vanguard of live programming. uations, the top level code might be thought of as a This paper describes an extension of Live Coding into simple \live environment" that can be created live and the realms of live systems programming. This enhance- that encapsulates code that has \bubbled-up" from the ment has been motivated by several desires: to improve supporting libraries. Our system enables this bubbling the performance and flexibility of Live Coding languages, up to be achieved in an ad-hoc way and with minimal to extend their capability to encompass supporting li- performance penalty. The deep, systems-level liveness braries and the operating system itself, and thence to that it exhibits is described and compared with other explore their real-world applications { both in artistic approaches to Live Coding and liveness generally. Live Coding and in the wider world of live programming The work described here has its origins in artistic Live systems. Coding of computer music and multimedia. As well Starting from the Impromptu system described by [30], as this application area we will also discuss its wider the present work has resulted in a new programming uses including the development of interactive multimedia language, a new support compiler and substantial library installations and the harnessing of scientific simulation. development { in total encompassing some 180,000 lines of source code. Its challenge has been to bring some CCS Concepts Applied computing ! Sound and of the run-time tooling, small compilation units and music computing; Software and its engineering late binding popular in dynamic languages, into a new ! General programming languages; Frameworks; system-level direct-to-native language and run-time en- Human-centered computing ! Interaction paradigms; vironment suitable for Live Coding. The new system, Keywords Live Coding, Live Programming, Liveness, called Extempore, has been running in production since Computer Music 2014 and has been used extensively for artistic perfor- mance, for research, and for commercial development. ACM Reference format: This is the first paper that describes the design and Andrew Sorensen and Henry Gardner. 2017. Systems Level architecture of Extempore and that justifies its claim to Liveness with Extempore. In Proceedings of Onward! 2017, Vancouver, BC, Canada, October 22-27, 16 pages. having systems level liveness. DOI: 10.1145/nnnnnnn.nnnnnnn After a review of Live Coding in the next section, we then describe the design and architecture of Extempore 1 Introduction in Section 3. We particularly discuss the new XTLang language which, together with Scheme, provides Extem- Over almost two decades, an international community of pore with its bilingual programming interface. In Section artists and computer scientists has developed an artistic 4, we then describe three examples of the application of performance practice known as \Live Coding" where Extempore: computer music, scientific simulation and computer programs are written and modified in front interactive multi-media. Each of these examples might of a live audience to generate, manipulate and respond be thought of as being characterized by an approach to music and visual media in real time. \Live Coders" where a \live language" has been \developed live" on write and modify code that interfaces with the world in top of a systems substrate with minimal penalty to either Onward! 2017, Vancouver, BC, Canada 2017. 978-x-xxxx-xxxx-x/YY/MM. $15.00 DOI: 10.1145/nnnnnnn.nnnnnnn Onward! 2017, October 22-27, Vancouver, BC, Canada Andrew Sorensen and Henry Gardner performance or low level flexibility. We discuss this sys- A similar situation exists in scientific computing, where tems level liveness in Sections 5 and 6 and we conclude higher level languages such as R, Python and Mathemat- with Section 7. ica are coupled to high-performance numerical frame- works written in C/C++/Fortran. The half-stack design provides scientists with a live \interactive programming experience", with the heavy lifting managed by coupled numerical libraries written in a lower level systems lan- 2 Live Coding and the Systems Stack guage. While an argument can be advanced that such a 2.1 Half-Stack Environments half-stack design represents a reasonable separation of A standard approach to developing musical Live Coding concerns, real-world problems have a tendency to bub- systems has been to take a managed higher-level pro- ble up through the software stack. When analyzing a gramming language, such as Ruby(Sonic Pi[2]), corpus of some 3.5 million lines of R code, Morandat et JavaScript(Gibber[25]), Scheme(Impromptu[29], al. [20] noted that the average run-time spent in calls Fluxus[10]), Clojure(Overtone[2]), Lua(LuaAV[37]), and to foreign functions was only 22%. This is despite the to couple that managed language to a native audiovisual expectation that R programs (and R programmers!) are framework (typically implemented in C/C++). Such expected to push heavy computational work down to Live Coding environments could be called \half-stack" the C FFI. Mordandat et al. showed that this is perhaps because their ability to \live modify" the behavior of the not happening in practice. With R's run-time perfor- underlying audiovisual framework is generally restricted mance trailing C by a factor of 500, the performance for reasons of performance, accessibility, or both. By implications of the 68% of the execution time spent in way of example, it is generally not possible to write non- the R layer is significant. Our purpose here is not to trivial real-time Digital Signal Processing (DSP) code in denigrate R (indeed we are fans of R and the interactive these higher-level languages. This is due to the lack of programming experience that it provides), but rather to sufficiently low-level access to the CPU instruction set highlight that programmers are still attempting to do required to write real-time DSP code as well as to perfor- significant computational work above the C abstraction mance limitations on these languages (even if low-level layer despite R's known performance limitations. In access were possible). practice, it seems that such programming problems are Despite these limitations, the half-stack approach has bubbling up through the abstraction stack. also been the dominant approach to building live pro- Ideally we would like the live programmer's program- gramming environments outside of Live Coding (outside ming environment to provide the performance and ac- of the audiovisual domain). Computer game engines cessibility necessary to solve any domain problems that (Unity3D, Unreal Engine, CryEngine, OGRE, Torque, might reasonably arise. Half-stack live programming etc.) commonly use managed languages (particularly environments, such as R, often fall short of this ideal JavaScript and C#) coupled to low-level, real-time game because they either (a) do not support the necessary engines (in C/C++), to provide a degree of \live in- low-level primitives required (such as explicit Advanced teractive scripting". The \scripting engine" supports Vector Extensions) or (b) do not provide the necessary programmer productivity while the underlying game en- run-time performance required (such as that needed for gine maintains highly specialized, and highly optimized, heavy numerical computation). run-time performance. Games programmers (the end- For systems-level programming, what constitutes \suf- users of game engines) are able to proceduralize many ficient performance", or “sufficient access", can be collo- aspects of their game at the scripting layer. However, quially benchmarked by the level of access and perfor- whenever high numerical performance, real-time I/O, or mance provided by the C language { a language com- hardware interfacing are required, games programmers monly described, in antipathy as often as reverence, as a are expected to drop down to the underlying C/C++ \portable assembly language". Ultimately, full-stack live substrate. Significantly, dropping down the game engine programming attempts to provide on-the-fly interactive abstraction tree from scripting language to C++ also real-time programming down to the machine (accessibil- means sacrificing the \live" interactive programming ity) with optimal hardware utilization (performance) as experience provided by the half-stack environment. To benchmarked against C. be explicit, there are limitations in the scripting layer that limit the domain of problems to which the scripting 2.2 The \Full-Stack" Experience layer can provide a reasonable solution. Beyond this The general ideal of \Full-Stack" live programming can \half-stack" the programmer is forced to change their be traced back at least as far as Smalltalk. Alan Kay operating environment, and in so doing, lose the ability envisaged a future where computer users would be com- to live program the system. puter programmers - computer programmers empowered Systems Level Liveness with Extempore Onward! 2017, October 22-27, Vancouver, BC, Canada from the elimination of conventional loading and system generation cycles"[15, p.22].
Load more

Recommended publications
  • Chuck: a Strongly Timed Computer Music Language
    Ge Wang,∗ Perry R. Cook,† ChucK: A Strongly Timed and Spencer Salazar∗ ∗Center for Computer Research in Music Computer Music Language and Acoustics (CCRMA) Stanford University 660 Lomita Drive, Stanford, California 94306, USA {ge, spencer}@ccrma.stanford.edu †Department of Computer Science Princeton University 35 Olden Street, Princeton, New Jersey 08540, USA [email protected] Abstract: ChucK is a programming language designed for computer music. It aims to be expressive and straightforward to read and write with respect to time and concurrency, and to provide a platform for precise audio synthesis and analysis and for rapid experimentation in computer music. In particular, ChucK defines the notion of a strongly timed audio programming language, comprising a versatile time-based programming model that allows programmers to flexibly and precisely control the flow of time in code and use the keyword now as a time-aware control construct, and gives programmers the ability to use the timing mechanism to realize sample-accurate concurrent programming. Several case studies are presented that illustrate the workings, properties, and personality of the language. We also discuss applications of ChucK in laptop orchestras, computer music pedagogy, and mobile music instruments. Properties and affordances of the language and its future directions are outlined. What Is ChucK? form the notion of a strongly timed computer music programming language. ChucK (Wang 2008) is a computer music program- ming language. First released in 2003, it is designed to support a wide array of real-time and interactive Two Observations about Audio Programming tasks such as sound synthesis, physical modeling, gesture mapping, algorithmic composition, sonifi- Time is intimately connected with sound and is cation, audio analysis, and live performance.
    [Show full text]
  • Confessions-Of-A-Live-Coder.Pdf
    Proceedings of the International Computer Music Conference 2011, University of Huddersfield, UK, 31 July - 5 August 2011 CONFESSIONS OF A LIVE CODER Thor Magnusson ixi audio & Faculty of Arts and Media University of Brighton Grand Parade, BN2 0JY, UK ABSTRACT upon writing music with programming languages for very specific reasons and those are rarely comparable. This paper describes the process involved when a live At ICMC 2007, in Copenhagen, I met Andrew coder decides to learn a new musical programming Sorensen, the author of Impromptu and member of the language of another paradigm. The paper introduces the aa-cell ensemble that performed at the conference. We problems of running comparative experiments, or user discussed how one would explore and analyse the studies, within the field of live coding. It suggests that process of learning a new programming environment an autoethnographic account of the process can be for music. One of the prominent questions here is how a helpful for understanding the technological conditioning functional programming language like Impromptu of contemporary musical tools. The author is conducting would influence the thinking of a computer musician a larger research project on this theme: the part with background in an object orientated programming presented in this paper describes the adoption of a new language, such as SuperCollider? Being an avid user of musical programming environment, Impromptu [35], SuperCollider, I was intrigued by the perplexing code and how this affects the author’s musical practice. structure and work patterns demonstrated in the aa-cell performances using Impromptu [36]. I subsequently 1. INTRODUCTION decided to embark upon studying this environment and perform a reflexive study of the process.
    [Show full text]
  • FAUST Tutorial for Functional Programmers
    FAUST Tutorial for Functional Programmers Y. Orlarey, S. Letz, D. Fober, R. Michon ICFP 2017 / FARM 2017 What is Faust ? What is Faust? A programming language (DSL) to build electronic music instruments Some Music Programming Languages DARMS Kyma 4CED MCL DCMP LOCO PLAY2 Adagio MUSIC III/IV/V DMIX LPC PMX AML Elody Mars MusicLogo POCO AMPLE EsAC MASC Music1000 POD6 Antescofo Euterpea Max MUSIC7 POD7 Arctic Extempore Musictex PROD Autoklang MidiLisp Faust MUSIGOL Puredata Bang MidiLogo MusicXML PWGL Canon Flavors Band MODE Musixtex Ravel CHANT Fluxus MOM NIFF FOIL Moxc SALIERI Chuck NOTELIST FORMES MSX SCORE CLCE Nyquist FORMULA MUS10 ScoreFile CMIX OPAL Fugue MUS8 SCRIPT Cmusic OpenMusic Gibber MUSCMP SIREN CMUSIC Organum1 GROOVE MuseData SMDL Common Lisp Outperform SMOKE Music GUIDO MusES Overtone SSP Common HARP MUSIC 10 PE Music Haskore MUSIC 11 SSSP Patchwork Common HMSL MUSIC 360 ST Music PILE Notation INV MUSIC 4B Supercollider Pla invokator MUSIC 4BF Symbolic Composer Csound PLACOMP KERN MUSIC 4F Tidal CyberBand PLAY1 Keynote MUSIC 6 Brief Overview to Faust Faust offers end-users a high-level alternative to C to develop audio applications for a large variety of platforms. The role of the Faust compiler is to synthesize the most efficient implementations for the target language (C, C++, LLVM, Javascript, etc.). Faust is used on stage for concerts and artistic productions, for education and research, for open sources projects and commercial applications : What Is Faust Used For ? Artistic Applications Sonik Cube (Trafik/Orlarey), Smartfaust (Gracia), etc. Open-Source projects Guitarix: Hermann Meyer WebAudio Applications YC20 Emulator Thanks to the HTML5/WebAudio API and Asm.js it is now possible to run synthesizers and audio effects from a simple web page ! Sound Spatialization Ambitools: Pierre Lecomte, CNAM Ambitools (Faust Award 2016), 3-D sound spatialization using Ambisonic techniques.
    [Show full text]
  • Isupercolliderkit: a Toolkit for Ios Using an Internal Supercollider Server As a Sound Engine
    ICMC 2015 – Sept. 25 - Oct. 1, 2015 – CEMI, University of North Texas iSuperColliderKit: A Toolkit for iOS Using an Internal SuperCollider Server as a Sound Engine Akinori Ito Kengo Watanabe Genki Kuroda Ken’ichiro Ito Tokyo University of Tech- Watanabe-DENKI Inc. Tokyo University of Tech- Tokyo University of Tech- nology [email protected] nology nology [email protected]. [email protected]. [email protected]. ac.jp ac.jp ac.jp The editor client sends the OSC code-fragments to its server. ABSTRACT Due to adopting the model, SuperCollider has feature that a iSuperColliderKit is a toolkit for iOS using an internal programmer can dynamically change some musical ele- SuperCollider Server as a sound engine. Through this re- ments, phrases, rhythms, scales and so on. The real-time search, we have adapted the exiting SuperCollider source interactivity is effectively utilized mainly in the live-coding code for iOS to the latest environment. Further we attempt- field. If the iOS developers would make their application ed to detach the UI from the sound engine so that the native adopting the “sound-server” model, using SuperCollider iOS visual objects built by objective-C or Swift, send to the seems to be a reasonable choice. However, the porting situa- internal SuperCollider server with any user interaction tion is not so good. SonicPi[5] is the one of a musical pro- events. As a result, iSuperColliderKit makes it possible to gramming environment that has SuperCollider server inter- utilize the vast resources of dynamic real-time changing nally. However, it is only for Raspberry Pi, Windows and musical elements or algorithmic composition on SuperCol- OSX.
    [Show full text]
  • Pynchon's Sound of Music
    Pynchon’s Sound of Music Christian Hänggi Pynchon’s Sound of Music DIAPHANES PUBLISHED WITH SUPPORT BY THE SWISS NATIONAL SCIENCE FOUNDATION 1ST EDITION ISBN 978-3-0358-0233-7 10.4472/9783035802337 DIESES WERK IST LIZENZIERT UNTER EINER CREATIVE COMMONS NAMENSNENNUNG 3.0 SCHWEIZ LIZENZ. LAYOUT AND PREPRESS: 2EDIT, ZURICH WWW.DIAPHANES.NET Contents Preface 7 Introduction 9 1 The Job of Sorting It All Out 17 A Brief Biography in Music 17 An Inventory of Pynchon’s Musical Techniques and Strategies 26 Pynchon on Record, Vol. 4 51 2 Lessons in Organology 53 The Harmonica 56 The Kazoo 79 The Saxophone 93 3 The Sounds of Societies to Come 121 The Age of Representation 127 The Age of Repetition 149 The Age of Composition 165 4 Analyzing the Pynchon Playlist 183 Conclusion 227 Appendix 231 Index of Musical Instruments 233 The Pynchon Playlist 239 Bibliography 289 Index of Musicians 309 Acknowledgments 315 Preface When I first read Gravity’s Rainbow, back in the days before I started to study literature more systematically, I noticed the nov- el’s many references to saxophones. Having played the instru- ment for, then, almost two decades, I thought that a novelist would not, could not, feature specialty instruments such as the C-melody sax if he did not play the horn himself. Once the saxophone had caught my attention, I noticed all sorts of uncommon references that seemed to confirm my hunch that Thomas Pynchon himself played the instrument: McClintic Sphere’s 4½ reed, the contra- bass sax of Against the Day, Gravity’s Rainbow’s Charlie Parker passage.
    [Show full text]
  • DVD Program Notes
    DVD Program Notes Part One: Thor Magnusson, Alex Click Nilson is a Swedish avant McLean, Nick Collins, Curators garde codisician and code-jockey. He has explored the live coding of human performers since such Curators’ Note early self-modifiying algorithmic text pieces as An Instructional Game [Editor’s note: The curators attempted for One to Many Musicians (1975). to write their Note in a collaborative, He is now actively involved with improvisatory fashion reminiscent Testing the Oxymoronic Potency of of live coding, and have left the Language Articulation Programmes document open for further interaction (TOPLAP), after being in the right from readers. See the following URL: bar (in Hamburg) at the right time (2 https://docs.google.com/document/d/ AM, 15 February 2004). He previously 1ESzQyd9vdBuKgzdukFNhfAAnGEg curated for Leonardo Music Journal LPgLlCe Mw8zf1Uw/edit?hl=en GB and the Swedish Journal of Berlin Hot &authkey=CM7zg90L&pli=1.] Drink Outlets. Alex McLean is a researcher in the area of programming languages for Figure 1. Sam Aaron. the arts, writing his PhD within the 1. Overtone—Sam Aaron Intelligent Sound and Music Systems more effectively and efficiently. He group at Goldsmiths College, and also In this video Sam gives a fast-paced has successfully applied these ideas working within the OAK group, Uni- introduction to a number of key and techniques in both industry versity of Sheffield. He is one-third of live-programming techniques such and academia. Currently, Sam the live-coding ambient-gabba-skiffle as triggering instruments, scheduling leads Improcess, a collaborative band Slub, who have been making future events, and synthesizer design.
    [Show full text]
  • Music Programming in Gibber
    ICMC 2015 – Sept. 25 - Oct. 1, 2015 – CEMI, University of North Texas Music Programming in Gibber Charles Roberts Matthew Wright JoAnn Kuchera-Morin [email protected] [email protected] [email protected] University of California at Santa Barbara Media Arts & Technology Program ABSTRACT We begin by discussing the synthesis possibilities of Gib- ber, which include a wide variety of both synthesizers and We document music programming in Gibber, a creative cod- effects. This is followed by a discussion of musical nota- ing environment for the browser. We describe affordances tion, including the use of symbols to represent concepts from for a sample-accurate and functional approach to schedul- the Western musical tradition. We discuss musical structure ing, pattern creation and manipulation, audio synthesis, us- in Gibber, beginning with the use of patterns and sequencers ing rhythm and harmony, and score definition and playback. and proceeding to higher-level heterarchical structures. We conclude with a discussion of our system in relation to other 1. INTRODUCTION music programming languages and a brief look at Gibber in use. First introduced as an environment for live coding perfor- mance in 2012 [1], Gibber has gradually expanded in scope to include musical instrument design [2], 2D and 3D graph- 2. SYNTHESIS AND SIGNAL PROCESSING ics, and improved affordances for both live coding and mu- Gibber provides a variety of options for audio synthesis, many sical composition. This paper codifies the compositional af- of which are wrappers around the unit generators and instru- fordances of Gibber, both from the perspective of real-time ments found in Gibberish.js, a lower-level DSP library for composition (also known as live coding [3, 4]) and more tra- JavaScript [5] written specifically to support Gibber.
    [Show full text]
  • A Supercollider Environment for Synthesis-Oriented Live Coding
    Colliding: a SuperCollider environment for synthesis-oriented live coding Gerard Roma CVSSP, University of Surrey Guildford, United Kingdom [email protected] Abstract. One of the motivations for live coding is the freedom and flexibility that a programming language puts in the hands of the performer. At the same time, systems with explicit constraints facilitate learning and often boost creativity in unexpected ways. Some simplified languages and environments for music live coding have been developed during the last few years, most often focusing on musical events, patterns and sequences. This paper describes a constrained environment aimed at exploring the creation and modification of sound synthesis and processing networks in real time, using a subset of the SuperCollider programming language. The system has been used in educational and concert settings, two common applications of live coding that benefit from the lower cognitive load. Keywords: Live coding, sound synthesis, live interfaces Introduction The world of specialized music creation programming languages has been generally dominated by the Music-N paradigm pioneered by Max Mathews (Mathews 1963). Programming languages like CSound or SuperCollider embrace the division of the music production task in two separate levels: a signal processing level, which is used to define instruments as networks of unit generators, and a compositional level that is used to assemble and control the instruments. An exception to this is Faust, which is exclusively concerned with signal processing. Max and Pure Data use a different type of connection for signals and events, although under a similar interaction paradigm. Similarly, Chuck has specific features for connecting unit generators and controlling them along time.
    [Show full text]
  • Kreativní Role Počítače V Kompozici Elektronické Hudby
    MASARYKOVA UNIVERZITA FILOZOFICKÁ FAKULTA ÚSTAV HUDEBNÍ VĚDY – TEORIE INTERAKTIVNÍCH MÉDIÍ Bc. JAN WINKLER Kreativní role počítače v kompozici elektronické hudby MAGISTERSKÁ DIPLOMOVÁ PRÁCE Vedoucí práce: PhDr. Martin Flašar, Ph.D. 2020 Prohlašuji, že jsem diplomovou práci vypracoval samostatně s využitím uvedených pramenů a literatury. ………………………………………………. Jan Winkler Na tomto místě bych chtěl poděkovat všem, kteří mi byli nápomocni s vypracováním této diplomové práce, zejména vedoucímu práce PhDr. Martinu Flašarovi, Ph.D. za jeho cenný čas a rady. Dále bych chtěl poděkovat své rodině za podporu během psaní i celého studia. Obsah 1 Úvod ........................................................................................................................... 1 2 Předchůdci počítačové hudby ..................................................................................... 3 3 Základní vývoj počítačové hudby ve 20. století ............................................................ 7 3.1 Hiller & Isaacson .................................................................................................. 7 3.2 Max Mathews, MUSIC N a GROOVE ................................................................... 9 3.3 Další vývoj ve 20. století ..................................................................................... 12 3.4 Miller Puckette – Patcher, Max/MSP, Pure Data ................................................ 15 4 Vývoj elektronické hudby v ČSR...............................................................................
    [Show full text]
  • Live Coding for Human-In- The-Loop Simulation
    Live coding for Human-in- the-Loop Simulation Ben Swift Research School of Computer Science Australian National University live coding the practice of writing & editing live programs Outline • Extempore: a software environment for live coding • Live demo: particle-in-Cell (PIC) simulation • Future directions: human-in-the-loop processing in simulation, modelling & decision support extempore • Open-source (MIT Licence) & available for OSX, Linux & Windows (http://github.com/digego/extempore) • Lisp-style syntax (Scheme-inspired) • High-performance compiled code (LLVM JIT) • Toll-free interop with C & Fortran • Hot-swappable at a function level programmer TCP extempore (local or remote) extempore Extempore code assembler & LLVM IR machine code any function can be redefined on-the-fly programmer extempore extempore extempore extempore extempore extempore extempore extempore extempore C/Fortran output main Extempore program C/Fortran output main extempore Extempore program changes main C/Fortran output init push solve extempore Extempore program changes main push C/Fortran output solve init extempore Extempore program changes main push C/Fortran output print init solve extempore Extempore program changes main push C/Fortran output print init solve extempore Extempore program changes main push C/Fortran output print init solve extempore Extempore program changes main push C/Fortran vis init solve extempore Extempore program changes main init push vis solve extempore The power of live programming • Change parameters on the fly, with feedback • Interactively add debug output (no loss of state) • Switch optimisers/solvers etc. on-the-fly (modularity in codebase & libraries helps) what does this have to do with DSI? Similarities • Numerical modelling (HPC-style problems) • High-dimensional, non-linear parameter spaces • Long-running jobs = long delays for feedback Opportunities • Joint simulation, experimentation and wargaming (e.g.
    [Show full text]
  • Alistair Riddell
    [email protected] [email protected] [email protected] http://www.alistairriddell.com au.linkedin.com/in/alistairriddell? https://www.researchgate.net https://independent.academia.edu/AlistairRiddell Alistair Riddell Brief Biography Over the past 40 years Melbourne born Alistair Riddell has been active as a musician, composer, performer, creative coder, installation artist, collaborator, educator, supervisor, writer and promoter of evolving digital creative practices. Beginning with a focus on music composition using technology in the 1980s, his interests have ranged widely over the digital domain where he developed particular interests in the processes of interaction between the creative mind and physical objects. He has spent considerable time experimenting with technology and ideas, and many of his completed works have been publicly presented in a diverse range of curated contexts. Alistair holds degrees in Music and Computer Science from La Trobe University and a PhD in music composition from Princeton University. He lectured in Sound Art and Physical Computing at the Australian National University after which he returned to Melbourne and has worked as a freelance artist/researcher collaborating on projects around Australia. 2 Education Princeton University (New Jersey, USA) Naumberg Fellowship 1993 PhD Thesis title: Composing the Interface 1991 Master of Fine Arts La Trobe University (Melbourne, Australia) 1989 Master of Arts Thesis title: A Perspective on the Acoustic Piano as a Performance Medium under Machine Control 1986 Post Graduate Diploma in Computer Science 1981 BA (Hons) Job History/Appointments/Projects (2000 onwards) Carillon Keyboard Project. National Capital Authority. Canberra. (October/November 2019) Collective Social Intelligence (@ foysarcade.com ) Research work (June 2017 – Nov 2019) Australian Catholic University.
    [Show full text]
  • Reflections on Learning Coding As a Musician V. 1
    REFLECTIONS ON LEARNING LIVE CODING AS A MUSICIAN May Cheung LiveCode.NYC [email protected] ABSTRACT Live-coding music has become a large trend in recent years as programmers and digital artists alike have taken an interest in creating algorithmic music in live setings. Interestingly, a growing number of musicians are becoming live coders and they are becoming more aware of its potential to create live electronic music using a variety of coding languages. As a musician who live codes music, it became apparent to me that my process in creating musical structure, harmonic ideas and melodic ideas were different than live coders who came from a programming background. Using the live code environment Sonic Pi (based on the programming language Ruby, created by Dr. Sam Aaron) as a reference, we argue the parallels and differences between the experience of live coding music versus the experience of performing and playing music. In rare occasions, the dichotomy of the two worlds converge as we present the work of Anne Veinberg, a renown classically-trained pianist who uses a MIDI keyboard as an interface to code through a program created by composer-performer Felipe Ignacio Noriega. 1. INTRODUCTION Afer spending many years as a musician from a jazz performance background, I was excited to try a new method of creating music. Introduced to a live coding program called Sonic Pi through friends in January 2018, I have had many opportunities to live code and present in front of audiences: from sizable nightclub crowds to atentive teenagers during their coding summer camp at NYU.
    [Show full text]