Origins of live coding April 1, 2014
Origins of live coding
Nick Collins Durham University
1 Origins of live coding April 1, 2014
Live coding
2 Origins of live coding April 1, 2014 Live coding
¤ Art of re-programming; changing your mind about a process once established
¤ For artistic purposes, often live performance; possible aspects of theatre, meta-composition
¤ Venues including studios, concert halls, planetariums…
¤ Used to be a bit controversial, now institutionalised?
3 Origins of live coding April 1, 2014
Other terms…
¤ Live programming ¤ Interactive programming
¤ On-the-fly programming
¤ Performative programming
¤ ascii music…
4 Origins of live coding April 1, 2014
Or…
¤ Live coding is the realtime collection and coding of interview data, e.g. in qualitative medical research?
5 Origins of live coding April 1, 2014
Ancient live coding history
¤ Greek debates?
¤ Ancient algorithmic composition: Guido d’Arezzo c. 1026
¤ Fior vs Tartaglia, 1535
6 Origins of live coding April 1, 2014
Precedents: improvisation
¤ Music’s natural state?
¤ Generativity of language itself
7 Origins of live coding April 1, 2014
A literary precedent
¤ Hermann Hesse The Glass Bead Game (1943)
¤ ‘the players, mutually elaborating these processes, threw these abstract formulas at one another, displaying the sequences and possibilities of their science.’ (pp. 23-4, Vintage: London 2000 translated by Richard and Clara Winston.)
8 Origins of live coding April 1, 2014
Text pieces
¤ Primarily 1960s
¤ ‘verbal notations’ (Lely and Saunders 2012) ‘word events’ George Brecht
¤ An example of maximal freedom: LaMonte Young Composition 1960 #3 ‘Announce to the audience when the piece will begin and end if there is a limit on duration. It may be of any duration. Then announce that everyone may do whatever he wishes for the duration of the composition.’
9 Origins of live coding April 1, 2014
Text pieces 2: live coding?
¤ Are there any early self-rewriting text scores?
¤ Schooltime Special Cornelius Cardew 1968 contains possibility to extend itself via new questions
¤ Click Nilson’s precedents (1975, 2012)
¤ Honourable mention though a late arrival: https://twitter.com/textscoreaday 11 Dec 2012 “#60: Take an existing text score and profoundly alter its meaning by changing only one word.”
10 Origins of live coding April 1, 2014
Games
¤ Nomic, 1982, Peter Suber
¤ Fluxx, Calvinball etc…
11 Origins of live coding April 1, 2014
Computer science precedents
¤ LISP, c. 1962 implementation as first interpreted programming language
¤ Use in education via LOGO from 1968 to control virtual turtles
¤ Smalltalk 1980, FORTH
12 5. D.P. Anderson and R.J. Kuivila. “Con- Computer Music J . Vol. 8, No. 3. Fall References tinuous Abstractions for Discrete Event 1984, 32-50. Languages,” Computer MirsicJ., Vol. 13. No. 3. Fall 1989. pp. 11-23. 10. D.P. Anderson. “Synthesizer Manage- 1 . Musical Itistriinimt Digitnl Interface Spc+ ment Based on Note Priorities.” Proc. Int‘l Origins of live coding rficntiorz 1.0. Int’l MIDI Assoc.. North 6. D.P. Anderson and R.J. Kuivila, “A Sys-April 1,Computer 2014 Music Conf .. Computer Music Hollywood. Calif.. 1983. tem for Computer Music Performance,” Assoc., San Francisco. 1987, pp. 230-237. A C‘M Truns. Computer Systems. Vol. 8. 2. R.F. Erickson. “The Darms Project: A No. 1, Feb. 1990. pp. 56-82. 1 1, D.P. Anderson and J. Bilmes, “Concur- Status Report.” Computers and the Hrr- rent Real-Time Music in C++,” Proc. matiitiesVol.Y.No.6.June 1975.pp.291- 7. D. Collinge, “Moxie: A Language for Usenix C++ Workshop, Berkeley. Calif.. 1991, pp. 147-161. 298. Computer Music Performance,” Proc. Inr’l Compiirer Music Conf . Computer 3. L.C. Smith. “Score. A Musician’s Approach Music Assoc.. San Francisco, 1984. pp. to Computer Music,“ J. Audio Eng. Soc., 21 7-220. Vol. 20. No. 1. Jan./Feb. 1972. pp. 7-14. 8. B. Schottstaedt, “PLA: A Composer’s 4. D.P. Anderson and R.J. Kuivila. “For- Idea ofa Language,” Computer MrcsicJ.. Live coding history: 1980sVol. 7. No. 1. Winter 1983, pp. 11-20. mula Version 3.4 Reference Manual,” Tech. Report 911630. Computer Science Division. Univ. of California at Berke- 9 X Rodet and P Cointe. “Formes Com- ley. May 1991. position and Scheduling of Processes.”
David P. Anderson is an assistant professor in the Computer Science Division at the IJniversity of California at Berkeley. In ad- 32 time-advance dition to his work in computer music, he has done research in distributed operating sys- 33 base-pitch tems, software support for digital audio and 34 127 1 do video. distributed programming, computer ¤ 1980s Forth and HMSL. Computer musicians’ frantic graphics. and protocol specification. 35 i cycle-size 21 * 0 do Anderson received his BA in mathematics 36 inc + j mod base-pitch + 127 and dup $ from Wesleyan University, and his MA in preparations up to performance time (the audience mathematics and MS and PhD in computer 37 loop science. all from the University of Wiscon- wander around The Hub) 38 loop sin-Madison. 39 drop 40 maxend 41 ;ap ¤ Ron Kuivila, Water Surface42 (1985) :ap asynch-scale 43 :ap (tuf-stuf 44 ::gp ::ap 45 280 beats-per-minute 46 ::ap 50 to $location nasty-bass 0 18011 c 30 d 2 146 e 2 4211f g tuf ;;ap5$ 47 ::ap 20 to $location piano 1011 18011 50 4 73 4 8411 tuf ;;ap 48 ::ap 80 to $location piano ;;2511ap 5011 66 2 146 3 6411 tuf ;;ap Ron Kuivila teaches in the Music Depart- ment at Wesleyan University. He composes 49 ::ap 80 to $location piano 5011 18011 66 2 146 3 6411 tuf ;;ap music and designs sound installations to high- 50 ::ap 100 to $location;ap vibes 5011 18011 70 4 73 6 12811 tuf ;;ap light the unusual electronic instruments he designs. He pioneered the musical uses of 51 ::ap 0 to $location xylophone 5011 10011 76 2 146 6 12811 tuf ;;ap ultrasound. sound sampling in live perfor- 52 ::ap 0 to $location xylophone 10011 18011 76 2 146 3 12811 tuf ;;ap mance. speech synthesis, and high-voltage phenomena. He has performed and exhibit- 53 127 to $location electric-piano 10011 18011 69 3 18 9 25611 tuf ed throughout the IJS and Europe. 54 ;;gp Kuivila received a BA in music from Wes- leyan llniversity and an MFA from Mills 55 ;ap College. 56 57 :ap tuf-stuf 58 ::ap” tuf-stuf” 13 59 (tuf-stuf Readerscan write to Anderson at the Com- 60 ;;ap puter Science Division, Electrical Engineer- 61 ;ap ing and Computer Science Dept., University of California, Berkeley, CA 94720: or Kuivila at the Music Department, Wesleyan University, Middletown, CT 06457.
July 1991 21 Origins of live coding April 1, 2014
Live coding history: c2000
¤ 2000, slub start to play in London projecting their screens
¤ Julian Rohrhuber exploits SuperCollider 2 to allow hot- swapping code in performance
14 Origins of live coding April 1, 2014
The Tspawn trick (SuperCollider 2)
//run me first ({ a = TSpawn.ar({arg ts,ec,syn, func; func.value},2,inf, 0.0);
b = a.source;
a }.play;)
//now b.trigger({Pan2.ar(SinOsc.ar(exprand(220,440),0,0.1), 1.0.rand2)})
15 Origins of live coding April 1, 2014
(Selected) Chronology 1
¤ 2000: ICMC Berlin, networked code passing McCartney/ Rohrhuber
¤ 2002: First live coding albums (unreleased)
¤ 2003: ChucK
¤ 2004: TOPLAP
16 Origins of live coding April 1, 2014
TOPLAP
17 Origins of live coding April 1, 2014
TOPLAP
¤ Multiple interpretations
¤ Scene: Feb 15th, 2004, 2am, a smoky bar, Hamburg. An anagram competition
¤ Livecode mailing list now has 100s of enthusiasts
18 Origins of live coding April 1, 2014
(Selected) Chronology 2
¤ 2005 TOPLAP transmediale
¤ 2005: first live code battle
¤ 2005: fluxus
¤ 2006: aa cell practice
¤ 2007: LOSS live code festival
19 Origins of live coding April 1, 2014
Sorry Ge
20 Origins of live coding April 1, 2014
Fights
¤ The boxing analogy rears for the World Programming Federation Fingerweight Belt
¤ Ghent 2005: Coding Bull: McLean vs Collins (match rigging allegations)
¤ Barcelona 2005: Raging Code: Wang vs Collins (disaster!)
21 Origins of live coding April 1, 2014
Challenges continue
¤ Nic vs Nick (2-1, New York/London/Mexico City) and The Ultimate Weapon
¤ Max/MSP in Belgium
¤ Mexican live coding
22 Origins of live coding April 1, 2014
Practice
¤ The importance of ten years
¤ Practice pacts
¤ No guarantee of effective transference (e.g. ordinary coding to live coding)
¤ Danger of misplaced practice with new techniques
23 Origins of live coding April 1, 2014
Selected Chronology (3)
¤ 2009: BBC documentary on pub code
¤ 2012: Live Notation AHRC: live arts and live coding
¤ 2013: Live Coding festival in Karlsruhe
¤ 1::year => now
24 Origins of live coding April 1, 2014
Documentations
¤ 2007 A pre-history of live coding
¤ 2012 CMJ DVD
¤ 2014 Computer Music Journal special issue
25 Origins of live coding April 1, 2014
Continuing live coding developments
¤ Live coding without computers, including choreography
¤ Live coding orchestras and ensembles
¤ New live coding environments, especially browser and mobile based
¤ Live coding in computer science education and HCI
26 Origins of live coding April 1, 2014
Live coding collaborations
¤ Live coding solo is very stressful
¤ Experimentalism is easier with a community support group
¤ But you may need more data projectors
27 Origins of live coding April 1, 2014
A historical example: Wrongheaded (2009-2013)
28 Origins of live coding Chalk April 1, 2014 explode Wrongheaded (with Matthew Yee-King) ¤ Algorithmic choreography ¤ Laptopists caught between programming work and external human action
¤ Our lowest moment: Leonardo 44(3) cover stars
!"#$$%&'()$$'!$$)(*)$$*%'+,&$$-#)./$$0"+"$ ,"1213)$$4)!.3(+$$,&.#$$*'01)4$$31*'01)4$ '1+$$*&"#+$$("10$$5".+$$4"3-()$$)136$$31'"1$
H$I$J$K$L$MM$NO$PQ$RS$T$U$V$W$XX$YY$Z$Y$[$\$[[$\\$]!$ Zombie 7$8$9$:$;$<$=$>$?$@$$ mode Ouija .$-$,$4$)$!$0$&$'$A$/$($6$1$"$B$C$#$*$+$3$D$%$E$F$G$ code ^)(("$ +#3)$ _"#(4$ !.(*)$
29 Origins of live coding April 1, 2014
Warning!
¤ Look away if you’re squeamish before the next slide
30 Origins of live coding April 1, 2014
An anatomy theatre
31 Live coding April 1, 2014
The Gospel According to Wrongheaded
32 Origins of live coding April 1, 2014 iPhone live coding
33 ’IF’ Code Snippet Responses 4. RESULTS 1 In this section we present results that have led us to con- Control 0.9 LiveCoding clude that live-coding is an effective way to teach an intro- ductory programming course. Due to limited space, we only 0.8 present results from our key findings. Furthermore, there 0.7 were no statistical differences between the VARK prefer- 0.6 ences both between and within experimental groups (T-test, 0.5 p < 0.05). In other words, the relative number of visual, auditory, read/write, and kinesthetic learners were statisti- 0.4 cally similar across all sections of experimental groups and Correct Responses (%) 0.3 instructors. 0.2 4.1 Grades 0.1 0 For starters, the assignments, exams, and overall grades Pre−Course Post−Course from both groups were virtually identical, with the live- coding group actually performing better on the final project Figure 2: The percentage of students (based on experimen- (e.g., see Figure 1). More specifically, the live-coding group performed statistically better than the control group on the tal group) who correctly answered the assignment vs. equiv- Origins of live coding April 1, 2014 final project (T-test, p < 0.05). All other grades were not alence code snippet questions on the pre and post-course statistically different between groups. surveys. When tested using the same official performance met- rics, live-codings students performed equal if not better than their control counterparts. Thus, it is safe to say that live- structor tests the code and the bug becomes apparent (e.g., coding is as good as, if not better than, teaching with static the value doesn’t persist), the instructor will go back to code. Moreover,Live our programming results suggest that live-coding may effectiveness ac- the code and ask for student help to track down the bug cout tually help students prepare and complete the final project. (e.g., using to output variable values). Then, when the bug is found, the instructor will make the necessary cor- rections (e.g., pass by reference) and recompile / rerun the Final Grades 1 code. As the semester progresses, students become more and more adept at locating these on purpose bugs as the in- structor types. This attentiveness helps students with their Marc J. Rubinown code,(2012) since they most likely develop a keen awareness The Effectivenessof locating of bugs Live-Coding as they type. 0.9 In the control (static code) version, the instructor presents to Teach Introductorythree totally di ffProgramming.erent files: one with a bug, one with debug- SIGCSE’13,ging March statements, 6–9, 2012, and finally the correct solution. Although Average Grade Denver, Coloradothe instructor would take ample time asking for student in- put, testing for the bug, and explaining the mistake, stu- 0.8 dents do not seem to grasp the information as well. This
Control is evident in the results from Figure 2, where the control LiveCoding group did not perform as well on the assignment vs. logical Assignments Exams Project Overall equivalence question. One can speculate that live-coding is simply a better way to hold student attention while showing code examples. Figure 1: Final grades computed for both groups. The live- coding group performed statistically better than the control 4.3 Live-Coding and Lecture Preferences on the final project (T-test, p < 0.05). As indicated in Figures 3 and 4,34 students in the live-coding group preferred the code examples more than the control 4.2 Live-Coding to Teach Common Bugs group. In particular, 90% of the live-coding group agreed that code examples were more educational than the Power- As indicated in Figure 2, live-coding appears to be an ef- point slides (as opposed to 67% in the control group). This fective way to teach and correct common introductory pro- is most likely because the code examples in the live-coding gramming mistakes such as assignment (=) versus equiva- group were more dynamic and interesting for students to lence (==). This is because live-coding offers instructors pay attention to. Despite the instructors’ best efforts, pre- the flexibility to purposefully write buggy code and make senting static code examples simply does not draw the same corrections live in front of students. Watching an instructor level of attention from students. This is evident from the debug code is very helpful to students because it: 1) shows types of comments we received on the live-coding survey. the process of debugging code and 2) shows common pitfalls when developing software. For example, when instructors write code that is concep- 5. CONCLUSION tually new to students (e.g., pass by reference vs. value) In this article we shared our research design and results to the instructor may purposefully incorporate a bug in the assess the effectiveness of live-coding as a teaching method. code (e.g., trying to permanently modify a variable that Our carefully constructed research design helps insure that was passed by value) without telling students. When the in- our results are admissible, given that all of the course ma- Origins of live coding April 1, 2014
Consequences
35 Origins of live coding April 1, 2014
Conclusions
¤ Rewriting the rule book of rule-based art?
¤ So whatever I said, change it
36 Origins of live coding April 1, 2014
Think you for lastening
37