Live Coding Blog

Idea

The main idea behind my composition project was a combination of my previous TidalCycles audio and Hydra visuals demo for Week 2 and Week 3. I really liked the aesthetic of the sunset-beach vibe I had in my Hydra visuals, so I knew I wanted my audio to accompany this feeling of a relaxing, laid-back vibe.

Audio:

My previous TidalCycles demo was me trying to recreate Oh Honey by The Delegations, and I expanded on this idea by mashing it up with Groovin’ by The Young Rascals. The two songs I chose to mashup were songs from the 1960-1970s, and they were R&B/Blues/Soul songs which fit the aesthetic that I wanted to go for.

To mash up the songs, I listened to both songs and picked out elements I liked from both of them. I liked the main theme of Oh Honey more, so I took the bassline, guitars and chords from it. I liked the beat of Groovin’ more, so I took the maracas and clave beat pattern from it, and also included the melody line. Combining the two melodies did not work as well as I expected, as the two songs were in different keys. I attempted to transpose Groovin’s melody into Oh Honey’s G major key, but for some reason it didn’t sound good after the transposing so I kept Groovin’ in it’s original key even though it was off-key as I thought it sounded better. Combining the non-melody beats were much easier as they were non-key specific — drums, maracas, claves.

Visuals:

My previous Hydra demo was similar with a theme of a sunset/ocean view, but I expanded on the visuals from the previous demo by using a modified oscillator shader that starts off with larger bands that becomes smaller towards the end, adding sea reflections, and adding a sky to the background.

The visuals were controlled by three MIDI patterns from TidalCycles. The sun would groove to the melody, the sea to the drum pattern, and the sea reflections were affected by the chord patterns. I left the sky untouched, as I felt that moving too many elements at once might be too chaotic and difficult to discern the beats of the song. In the final version, I think it was easy to identify which element corresponded with which element in the music which I was pretty proud of.

Overall

Overall, I was really proud of my buildup and fadeout of the song, as the beat patterns worked really well when you introduce them one by one or fade them out one by one. I was a little disappointed with the drop, as I couldn’t find a way to make it sound more energetic without making it too muddy and messy, so I left it as it is.

Tidal Composition

In terms of my musical composition, I’ve developed six distinct sound layers that blend nicely together. To organize the composition, I initially introduced these sounds sequentially, building towards a climactic moment. Halfway through the performance, I muted the first three tracks, creating a jazz-y shift in the musicality. Later, I reintroduced the three muted sounds one by one, gradually building up their presence before delicately fading them out towards the end of the composition. This gradual decrescendo provided a satisfying sense of closure. I think this structure effectively showcased the diverse range of notes and layers present in the composition.

d1 $ qtrigger $ filterWhen (>=0) $ stack[
    fast "<0.5 2>" $ s "lt:3 lt lt ~" # gain 0.8,
    s "909!4" # gain 1,
    ccv "2 4 1 1" # ccn 0 # s "midi"
  ]


d2 $ qtrigger $ filterWhen (>=0) $ stack [
   s "hh*2 hh*2 hh*2 <hh*6 [hh*2]!3>" # gain 0.8,
    ccv "45 90 270 360" # ccn 1 # s "midi"
  ]


d3 $ qtrigger $ filterWhen (>=0) $ stack [every 3 (hurry 2) $ sound "bd sd [~ bd] [cp bd*2]",
  sound "kurt:4(3,8)" # shape "0 0.98" # gain "0.5" # speed 1.04,
  struct "t" $ ccv (irand 15) # ccn 2 # s "midi"
]

d4 $ qtrigger $ filterWhen (>=0) $ stack[
    fast "<0.5 2>" $ s "lt:3 lt lt ~" # gain 0.5,
    s "909!4" # slow 2 ("<1.5 1>") # gain 1.2,
    s "hh*2 hh*2 hh*2 <hh*6 [hh*2]!3>" # gain 0.7,
    sound "sax(3,8) sax(5,8)" # legato 1 # n 3 # note "<[9 7] 5 [9 12]>" # sz 0.8 # room 0.4 # gain 0.8,
    struct "t" $ ccv (irand 127) # ccn 3 # s "midi"
  ]

d5 $ qtrigger $ filterWhen (>=0) $ stack[
  s "bd*4" # gain 1.4 # krush 10,
  struct "t t t t" $ ccv (irand 4) # ccn 4 # s "midi",
  ccv "2 4 1 1" # ccn 6 # s "midi"
]

d6 $ qtrigger $ filterWhen (>=0) $ stack [
  sound "sax(3,8) sax(5,8)" # legato 1 # n 3 # note "<[9 7] 5 [9 12]>" # sz 0.8 # room 0.4 # gain 0.8,
  struct "t" $ ccv (irand 6) # ccn 5 # s "midi"
]

Hydra visuals

Each layer of sound is assigned a distinct CC number, which sends MIDI data to Hydra. This allowed me to introduce variations to the original rectangle shape depending on the sound being played. It was particularly satisfying because silencing specific sounds would also disable particular visual distortions since the corresponding CC number wouldn’t be transmitted.

To add variety throughout the performance, I would comment out some lines to create the effect of visuals gradually building towards a climax. During the jazz-y drop, I disabled the pixelate line to allow for subtle changes in the oscillating visuals. Similar to the music, I wanted a gradual buildup and fading of the sounds, so it was essential for me to begin and end my visual composition with just one line.

For the next performance, I’m eager to expand on the scope of visuals. I’m intrigued by how many visuals I was able to generate with just 14 lines of code.

update = () => {
  let n = ccActual[2]+1
  let k = ccActual[4]
  shape(2, ()=>ccActual[6]*0.1) //()=>ccActual[6]*0.1
    .modulate(osc(1)) //*0.2
    .pixelate(()=>ccActual[0])
    .rotate(()=>ccActual[1])
    .scrollX(1/n)
    .scrollY(1/k)
    .mult(shape(()=>ccActual[5],()=>ccActual[5]*0.2))
    .modulate(noise(()=>cc[3]*5,0,1))
    .scale(1, ()=>window.innerHeight/window.innerWidth,1)
    .out()
  }

“Creative Know-How and No-How” presents live coding as a vibrant tapestry of thought, where the act of coding transcends its technical underpinnings to become a medium of artistic expression. It challenges us to embrace the uncertainties of the creative process, to find value in the act of exploration itself, and to reconsider the ways in which we understand and engage with technology.

One of the most compelling aspects discussed is the concept of “play” within live coding. This notion, borrowed from Roger Caillois, characterizes live coding as an inherently uncertain activity, a form of artistic experimentation that defies the conventional purpose and function. It’s a self-regulating activity that exists for its own sake, devoid of the pursuit of material gain, which is a radical departure from traditional views on productivity and creativity. This perspective invites us to reconsider the value we have for creative acts, urging us to see beyond the tangible outcomes and appreciate the beauty of creation itself.

The parallels drawn between live coding and preindustrial loom weaving are particularly evocative. Both practices require a heightened awareness and a dynamic response to the evolving conditions of the creative process. This analogy not only highlights the deep-rooted connection between coding and weaving as forms of thinking-in-motion but also challenges the historical narrative that prioritizes the Jacquard loom’s role in conceptualizing computational logic. By doing so, it invites a reevaluation of ancient crafts as precursors to modern computational practices, suggesting a continuity in thought that transcends technological advancements.

Moreover, the reading delves into the philosophical underpinnings of live coding, drawing upon concepts like kairotic and mêtic intelligence, which emphasize the importance of timing in the creative process. These ideas underscore the adaptability and situational awareness crucial to live coding, where the coder navigates through a landscape of possibilities, guided by a sense of what could be rather than what is.

For me, the intension of Live Coding can be divided into “knowing what want to show and not knowing what want to show”. When I come up with a concept first, but constrained by the lack of knowledge, I often fall into self-doubt: “What did I learn in Live Coding ? At this time, there is no concept, and I am surprised and happy with whatever I make at random. After a month of learning, I often reflect on whether the things I make are just “to comfort myself”. However, after reading this article, one of the important features of Live Coding is “experiment”：Although many live coders acknowledge some formal training in computing, music, or artistic methods, the knowledge of the process required for live coding emerges often through experimentation, through the accumulation of trial and error, and through innumerable versions and iterations, tests, and attempts（261）. For IM, a lot of software requires enough acknowledge to be able to produce. So I’m still not very comfortable with the learning process of Live Coding. Learning these skills is not about the anxiety of seeing someone else using the same skills and saying “they are doing it better than me”, it’s about the enjoyment of acquiring a skill at the same time. As the author says “Within live coding, the challenge seems less one of responding with learned behavior or an already rehearsed script than of how to harness the potential unique to every contingent situation”.

It’s been eye-opening for me to read about the multimodal epistemological model in live coding. It’s improved my comprehension of the various types of expertise and ability that go into becoming proficient in live coding. For me, this idea has been immensely comforting because I often feel inadequate because of my perceived lack of technical skill. I even feel incompetent at times. However, this concept has enabled me to see that my formal programming language expertise and my ability to write perfect code are not the only factors that determine my value as a live coder. Rather, it highlights the significance of embodied knowledge, reflective practice, and experience learning.

I identify personally with the notion that acquiring information entails combining many forms of understanding. It confirms my conviction that the experiences and learnings I get from practicing live coding—even when it means making mistakes—are important contributions to my development as a coder. It gives me the confidence to accept my learning and growth path and the knowledge that mistakes are to be expected along my journey.

It has also been immensely liberating for me to realize the playfulness and autotelic nature of live coding. The pressure to perform flawlessly in front of an audience during live coding sessions has often been unbearable for me as a performer who is used to being on stage. But my attitude has changed when I realized that the fun of live coding comes from the process itself, not from reaching perfection. It has aided in my realization that accepting experimentation, ambiguity, and even failure as necessary components of the creative process is acceptable. I can now approach live coding with interest and playfulness instead of fear and worry – although it will be hard to get rid of these habits.

This reading about live coding has also prompted me to explore different ways of thinking. It has forced me to see coding as a kind of creative expression and problem-solving as well as a technical ability. I can now think more creatively and innovatively when I code thanks to this mentality change. I now view live coding as a chance to participate in a dynamic conversation between creativity and technology, where experimentation and improvisation are valued, as opposed to concentrating only on creating flawless code.

In “Creative Know-How and No How” the author discusses the practice of live coding through the lens of artistic research and epistemology. The reader is quickly thrown questions like ‘what does live coding know?’ or ‘what does live coding think?’ From this analysis, there are a couple of points which grabbed my attention. For one, this chapter presents an interesting characterization of live coding. It quotes Brian Massumi in explaining that, instead of a predefined artwork, live coding presents “a movement precise with training but still open to regeneration.” Furthermore, it reinforces that the performance of live code makes visible a language deeply embedded into our day-to-day but one “in which still few are so fluent.” In doing so, it highlights how live coding sits at the crossroads of many disciplines. That is to say, it provides visibility to code (CS) through the production of music and visuals (Art), and gives insight into the human behind the screen writing this code. 

“Live coders appropriate and redirect (hack) a specific form of technical knowledge and language which is then played with.”

The author also characterizes live coding as a play experience through Robert Calloi’s framework of Play. In particular, mentioning the autotelic nature of live coding (as play) stood out to me. If live coding, like play, is autotelic (inherently without function or purpose beyond itself), how can we then address the know-how and think-how of live coding. 

Finally, through this excerpt I keep being brought back to our class on composition, when Professor Sherwood kept telling us “just try random things until it sounds decent”. It is also through trial and error only with which I’ve made any progress on my composition project. In response to this reading, I understand how this artistic experimentation, art as the process, applies to our class and my own journey of live coding. I’ve been really enjoying exploring a field not as constrained as others, and would love to see how it will keep impacting the study of knowledge.

I love how the author explains that in live coding, each of the programmer and the program becomes “mutually part of an open-ended and contingent process of both problem generation and problem solving.” Until now, although I had the understanding that live coding is all about showing the process, there was some pressure that the approach that will be shown ‘has to make sense’ and ‘build up’ towards something. The author’s word created a shift in my perspective that the beauty of live coding performances lies in that the process is not just about problem solving and making things better, but also about creating or running into problems and showing how the programmer deals with them through trials and errors.

Expanding on my initial thought that live coding performance still has to ‘build up’ to create something fancy, I think I limited myself to thinking that there has to be an ultimate product I should be aiming for. After reading the philosopher Paolo Virno’s saying “what characterizes the work of performing artist is that their actions have no extrinsic goal” and that “the purpose of their activity coincides entirely with its own execution.” My understanding is that yes, the performance should show progress in some way, but the focus is not necessarily about the end goal and more about making the best (or interesting) moves for that instance and seeing where the performer can go with that.