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.

“Not knowing is not only to be overcome, but sought, explored and savored; where failure, boredom, frustration and getting lost are constructively deployed.”

I feel Like this quote is something I one tries to understand on a deeper level to be able to live code. The idea of knowing for science and not knowing for art is sometimes bigger than just a know-how and a no-how, like a balance between both is also at some level required. The author talked in the reading about the idea of knowing how something works is not exactly required for creating in a live coding environment; that is is more about the exploration, the errors, the questions raised and the answers (or possibly answers?) found. It is about feeling the music in some way, feeling the visuals and trying to find a common ground for which you can go forward.

However, as the authors explained,

“Both ancient weaving and live coding involve a live, embodied process of decision-making and knowledge activation that operates in excess of or between the lines of conventional notational systems.”

the know how is also always in a way required. The idea that some sort of knowledge is required, but experienced level knowledge is not. That by live coding you need to keep the next part of the carpet unknown to keep going, yet you base what is to come on what was, and what is to come is what bases layers and layers of code to reach the end of the carpet. That the knowledge of how to code, how to weave, at a basic level, needs to be acquired before live coding, that some idea of color and music needs to be there. But that is the idea, that knowledge of some is all that is needed for one to have the ability to live code. It is more a talent of how to build layers over one another, the unpredictability and the block of advanced scientific knowledge that is needed.

Forcing yourself out side the box of science and thinking else where. That is what live coding needs, that is what comes from pushing yourself, exploring something new and seeing the things you know from the things you do not know to find an area where art shines.