origins of live codingcomposerprogrammer.com/research/originsoflivecoding.pdf · livecoding figure...

Origins of live coding

April 1, 2014 Origins of live coding

1

Nick Collins Durham University

Live coding

<INSERT DEFINITION HERE>


2

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?

April 1, 2014

3


Other terms…

¤ Live programming

¤  Interactive programming

¤ On-the-fly programming

¤ Performative programming

¤ ascii music…


4

Or…

¤  Live coding is the realtime collection and coding of interview data, e.g. in qualitative medical research?


5

Ancient live coding history

¤  Greek debates?

¤  Ancient algorithmic composition: Guido d’Arezzo c. 1026

¤  Fior vs Tartaglia, 1535


6

Precedents: improvisation

¤  Music’s natural state?

¤  Generativity of language itself


7

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

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

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

Games

¤  Nomic, 1982, Peter Suber

¤  Fluxx, Calvinball etc…


11

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

Live coding history: 1980s

¤  1980s Forth and HMSL. Computer musicians’ frantic preparations up to performance time (the audience wander around The Hub)

¤  Ron Kuivila, Water Surface (1985)


13

:ap asynch-scale ::ap c d e f g 5$ ;;ap

;ap

References

1 . Musical Itistriinimt Digitnl Interface Spc+ rficntiorz 1.0. Int’l MIDI Assoc.. North Hollywood. Calif.. 1983.

2. R.F. Erickson. “The Darms Project: A Status Report.” Computers and the Hrr- matiitiesVol.Y.No.6.June 1975.pp.291- 298.

3. L.C. Smith. “Score. A Musician’s Approach to Computer Music,“ J . Audio Eng. Soc., Vol. 20. No. 1. Jan./Feb. 1972. pp. 7-14.

4. D.P. Anderson and R.J. Kuivila. “For- mula Version 3.4 Reference Manual,” Tech. Report 911630. Computer Science Division. Univ. of California at Berke- ley. May 1991.

5 . D.P. Anderson and R.J. Kuivila. “Con- tinuous Abstractions for Discrete Event Languages,” Computer MirsicJ., Vol. 13. No. 3. Fall 1989. pp. 11-23.

6. D.P. Anderson and R.J. Kuivila, “A Sys- tem for Computer Music Performance,” A C‘M Truns. Computer Systems. Vol. 8. No. 1 , Feb. 1990. pp. 56-82.

7. D. Collinge, “Moxie: A Language for Computer Music Performance,” Proc. Inr’l Compiirer Music Conf . Computer Music Assoc.. San Francisco, 1984. pp. 21 7-220.

Computer Music J . Vol. 8, No. 3. Fall 1984, 32-50.

10. D.P. Anderson. “Synthesizer Manage- ment Based on Note Priorities.” Proc. Int‘l Computer Music Conf .. Computer Music Assoc., San Francisco. 1987, pp. 230-237.

1 1, D.P. Anderson and J . Bilmes, “Concur- rent Real-Time Music in C++,” Proc. Usenix C++ Workshop, Berkeley. Calif.. 1991, pp. 147-161.

8. B. Schottstaedt, “PLA: A Composer’s Idea ofa Language,” Computer MrcsicJ.. Vol. 7. No. 1. Winter 1983, pp. 11-20.

9 X Rodet and P Cointe. “Formes Com- position and Scheduling of Processes.”

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61

time-advance base-pitch 127 1 do

i cycle-size 21 * 0 do inc + j mod base-pitch + 127 and dup $

loop loop drop

maxend ;ap

:ap (tuf-stuf ::gp

280 beats-per-minute ::ap 50 to $location nasty-bass 0 18011 30 2 146 2 4211 tuf ;;ap ::ap 20 to $location piano 1011 18011 50 4 73 4 8411 tuf ;;ap ::ap 80 to $location piano 2511 5011 66 2 146 3 6411 tuf ;;ap ::ap 80 to $location piano 5011 18011 66 2 146 3 6411 tuf ;;ap ::ap 100 to $location vibes 5011 18011 70 4 73 6 12811 tuf ;;ap ::ap 0 to $location xylophone 5011 10011 76 2 146 6 12811 tuf ;;ap ::ap 0 to $location xylophone 10011 18011 76 2 146 3 12811 tuf ;;ap 127 to $location electric-piano 10011 18011 69 3 18 9 25611 tuf

;;gp ;ap

:ap tuf-stuf ::ap” tuf-stuf”

(tuf-stuf ;;ap

;ap

David P. Anderson is an assistant professor in the Computer Science Division at the IJniversity of California at Berkeley. In ad- dition to his work in computer music, he has done research in distributed operating systems, software support for digital audio and video. distributed programming, computer graphics. and protocol specification.

Anderson received his BA in mathematics from Wesleyan University, and his MA in mathematics and MS and PhD in computer science. all from the University of Wiscon- sin-Madison.

Ron Kuivila teaches in the Music Depart- ment at Wesleyan University. He composes music and designs sound installations to high- light the unusual electronic instruments he designs. He pioneered the musical uses of ultrasound. sound sampling in live performance. speech synthesis, and high-voltage phenomena. He has performed and exhibit- ed throughout the IJS and Europe.

Kuivila received a BA in music from Wes- leyan llniversity and an MFA from Mills College.

Readerscan write to Anderson at the Com- puter Science Division, Electrical Engineer- ing and Computer Science Dept., University of California, Berkeley, C A 94720: or Kuivila at the Music Department, Wesleyan University, Middletown, CT 06457.

July 1991 21

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

The Tspawn trick (SuperCollider 2)


15

//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)})

(Selected) Chronology 1

¤  2000: ICMC Berlin, networked code passing McCartney/Rohrhuber

¤  2002: First live coding albums (unreleased)

¤  2003: ChucK

¤  2004: TOPLAP


16

TOPLAP

April 1, 2014

17


TOPLAP

¤  Multiple interpretations

¤  Scene: Feb 15th, 2004, 2am, a smoky bar, Hamburg. An anagram competition

¤  Livecode mailing list now has 100s of enthusiasts


18

(Selected) Chronology 2

¤  2005 TOPLAP transmediale

¤  2005: first live code battle

¤  2005: fluxus

¤  2006: aa cell practice

¤  2007: LOSS live code festival


19

Sorry Ge


20

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!)

April 1, 2014

21


Challenges continue

¤  Nic vs Nick (2-1, New York/London/Mexico City) and The Ultimate Weapon

¤  Max/MSP in Belgium

¤  Mexican live coding


22

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

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

Documentations

¤  2007 A pre-history of live coding

¤  2012 CMJ DVD

¤  2014 Computer Music Journal special issue


25

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

Live coding collaborations

¤  Live coding solo is very stressful

¤  Experimentalism is easier with a community support group

¤  But you may need more data projectors

April 1, 2014

27


A historical example: Wrongheaded (2009-2013)

April 1, 2014

28


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$

7$8$9$:$;$<$=$>$?$@$$

.$-$,$4$)$!$0$&$'$A$/$($6$1$"$B$C$#$*$+$3$D$%$E$F$G$

H$I$J$K$L$MM$NO$PQ$RS$T$U$V$W$XX$YY$Z$Y$[$\$[[$\\$]!$

+#3)$ !.(*)$^)(("$_"#(4$

Ouija code

Zombie mode

Chalk explode

April 1, 2014

29


Warning!

¤  Look away if you’re squeamish before the next slide

April 1, 2014

30


An anatomy theatre

April 1, 2014

31


The Gospel According to Wrongheaded

April 1, 2014 Live coding

32

iPhone live coding


33

Live programming effectiveness


34

4. RESULTSIn this section we present results that have led us to con-

clude that live-coding is an effective way to teach an intro-ductory programming course. Due to limited space, we onlypresent results from our key findings. Furthermore, therewere no statistical differences between the VARK prefer-ences both between and within experimental groups (T-test,p < 0.05). In other words, the relative number of visual,auditory, read/write, and kinesthetic learners were statisti-cally similar across all sections of experimental groups andinstructors.

4.1 GradesFor starters, the assignments, exams, and overall grades

from both groups were virtually identical, with the live-coding group actually performing better on the final project(e.g., see Figure 1). More specifically, the live-coding groupperformed statistically better than the control group on thefinal project (T-test, p < 0.05). All other grades were notstatistically different between groups.

When tested using the same official performance met-rics, live-codings students performed equal if not better thantheir control counterparts. Thus, it is safe to say that live-coding is as good as, if not better than, teaching with staticcode. Moreover, our results suggest that live-coding may ac-tually help students prepare and complete the final project.

Assignments Exams Project Overall

0.8

0.9

1

Aver

age

Gra

de

Final Grades

ControlLiveCoding

Figure 1: Final grades computed for both groups. The live-coding group performed statistically better than the controlon the final project (T-test, p < 0.05).

4.2 Live-Coding to Teach Common BugsAs indicated in Figure 2, live-coding appears to be an ef-

fective way to teach and correct common introductory pro-gramming mistakes such as assignment (=) versus equiva-lence (==). This is because live-coding offers instructorsthe flexibility to purposefully write buggy code and makecorrections live in front of students. Watching an instructordebug code is very helpful to students because it: 1) showsthe process of debugging code and 2) shows common pitfallswhen developing software.

For example, when instructors write code that is concep-tually new to students (e.g., pass by reference vs. value)the instructor may purposefully incorporate a bug in thecode (e.g., trying to permanently modify a variable thatwas passed by value) without telling students. When the in-

Pre−Course Post−Course0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Corre

ct R

espo

nses

(%)

’IF’ Code Snippet Responses

ControlLiveCoding

Figure 2: The percentage of students (based on experimen-tal group) who correctly answered the assignment vs. equiv-alence code snippet questions on the pre and post-coursesurveys.

structor tests the code and the bug becomes apparent (e.g.,the value doesn’t persist), the instructor will go back tothe code and ask for student help to track down the bug(e.g., using cout to output variable values). Then, when thebug is found, the instructor will make the necessary cor-rections (e.g., pass by reference) and recompile / rerun thecode. As the semester progresses, students become moreand more adept at locating these on purpose bugs as the in-structor types. This attentiveness helps students with theirown code, since they most likely develop a keen awarenessof locating bugs as they type.

In the control (static code) version, the instructor presentsthree totally different files: one with a bug, one with debug-ging statements, and finally the correct solution. Althoughthe instructor would take ample time asking for student in-put, testing for the bug, and explaining the mistake, stu-dents do not seem to grasp the information as well. Thisis evident in the results from Figure 2, where the controlgroup did not perform as well on the assignment vs. logicalequivalence question. One can speculate that live-coding issimply a better way to hold student attention while showingcode examples.

4.3 Live-Coding and Lecture PreferencesAs indicated in Figures 3 and 4, students in the live-coding

group preferred the code examples more than the controlgroup. In particular, 90% of the live-coding group agreedthat code examples were more educational than the Power-point slides (as opposed to 67% in the control group). Thisis most likely because the code examples in the live-codinggroup were more dynamic and interesting for students topay attention to. Despite the instructors’ best efforts, pre-senting static code examples simply does not draw the samelevel of attention from students. This is evident from thetypes of comments we received on the live-coding survey.

5. CONCLUSIONIn this article we shared our research design and results to

assess the effectiveness of live-coding as a teaching method.Our carefully constructed research design helps insure thatour results are admissible, given that all of the course ma-

Marc J. Rubin (2012) The Effectiveness of Live-Coding to Teach Introductory Programming. SIGCSE’13, March 6–9, 2012, Denver, Colorado

Consequences


35

Conclusions

¤  Rewriting the rule book of rule-based art?

¤  So whatever I said, change it


36

Think you for lastening


37

origins of live codingcomposerprogrammer.com/research/originsoflivecoding.pdf · livecoding figure...

Documents