First of all, I found some interpretations of Live Coding interesting. “Live Coding is shaped by different genealogies of ideas and practices, both philosophical and technological”, so one needs to have a very deep understanding of liveness. At the same time, the article mentions that liveness refers both to nonhuman “machine liveness”, which I think is one reason why people need to have a deep understanding of liveness, since they need to have a deep understanding of “nonhuman”.

Secondly, the author states that Live Coding is not about writing code in advance. However, at the current level, it is almost impossible to be completely on the spot. I remember during the first group performance, our group had a lot of coding came up on the stage. That was a big challenge for me. In performing, like the article mentions, you can’t just focus on one note, instead, you have to generate from a higher-order process. In the groups, I learned a lot that Bato would write notes very casually, followed by more at random. What surprised me was that just by putting them together, even without much manipulation, they could sound great. So I don’t think the statement in the article that “technique doesn’t matter” fits that much for Live Coding with music. I learned Live Coding because I saw a lot of Live Coding performances in New York, and both the art form and the logic behind it appealed to me. I was attracted to the art and, to be honest, the limitations and technology, but was very much drawn to the art form of Live Coding. I’m what the article refers to as “composed improvisation or improvisation with a composed structure.” Live Coding’s liveness is what sets it apart from other forms of code, and it’s what’s most attractive. The liveness of Live Coding is what sets it apart from other forms of code, and what makes it most attractive.

This chapter delves into the interesting idea of the liveness of live coding. I find it very interesting that it is a hotly debated topic, but it is mostly up to one’s own interpretation. Can a live coding set truly be live with pregramming? If there isn’t code there to begin with, is it fine to still make music beforehand, and use those elements in your performance? Is that truly live coding? I find this a really interesting topic because. going into this class, I sort of assumed that in live coding performances were always completely improv, where people work off one another on the fly. However, the more I thought about it, the more I realized that’s probably not the case always. From my own experience trying to live code, a lot of times there is pregrammed stuff, and if not, stuff that people probably messed around with before a performance. This is what I do, anyway. It takes a lot of skill to know all the sounds and workings of code and coordination to be able to just make something out of nothing on the spot. When I would do improv solos on the saxophone, it’s not like I would be playing stuff on the fly always. A lot of times I would be playing along to the track beforehand, analyzing the chord progressions, the key, listening to other sax solos, and workshopping random stuff until I found things that I thought sounded nice or fit with the sound of the song. That way, when I am doing my actual performance, I can incorporate these small pieces I played into my actual solo. For me, the same applies to live coding. I think almost everyone has to, you are drawing from your own musical influence when you are doing a improv performance no matter what it is, because I’m pretty sure there is not a single person who does improv performances and doesn’t listen to music. So, I believe that there is no issue in pregramming or having pieces of music that are incorporated into a live set. But, if you can do it off the dome like that, kudos to you.

I found the reading interesting in how it shows how the “live” component of live coding is gradually evolving. I think there are many unexplored avenues in which live coding can be intersected with other forms of media, and I’m excited to explore these ideas throughout the rest of the semester as part of the final project. Through this form of self-expression, I think we can also continue to blur the boundary between person and machine and perform as a singular entity, and see how computing can give way to a wider variety of art forms.

The given reading looks into how the ‘live’ part of live coding is defined and executed. It was particularly interesting to see such spectrum of liveliness as it was something we also talked about in class.

I remember in class we talked about how much of the code should be prepared or not, in order to balance making sure that the audience is constaly entertained and that not too much of the performance is preplanned. The reading mentions both styles of live coding, implying it depends on the style and the performer and the performance, and what definition of liveliness they wish to hold.

For such decision, I think it’s important to remember that “within live coding, the performer consciously adopts a medial position, actively maintaining the conditions that will keep the action dynamic.”

This chapter explores the idea of “liveliness” in live coding from a methodological perspective and how we should “live” code. I think the balance between having a pre-written code and starting from an absolute zero is a practical question that has also risen throughout our live coding practices in class. It was interesting to think about liveliness not only in terms of human performers but for computers since, as the writing suggests, its immediacy is closely related to the nature of liveliness in live coding. How the author highlights the timely nature of liveliness gives me the impression that it is also similar to mixing, or DJing, different music. The author states that “principles of knowing how and knowing when are as privileged as knowing what” in live coding performances. In DJing, the human operator also typically has the pre-organized set and timestamps in mind, though they can be improvised depending on the audience and atmosphere during the performance. I think there is a challenging yet interesting balance in live performances where you want to say what you want to say but also want to communicate and vibe with your audience.

‘Live’ to me has always been associated with news and TV, because two of my cousins are reporters and I’ve spent a lot of time with them – going to their sets quite a lot as well. And the way I understood being ‘live’ then was being confident about what you’re doing in front of a camera and following what the script says perfectly, by adding a little bit of your own personality and flavor. This understanding has evolved a lot after that. I’ve learnt about rehearsed performances and spontaneous happenings. However, I feel like the core ideas of ‘liveness’ and going live in front of an audience have remained constant – performing your craft the best you can for the intended viewers. I find it fascinating how the insights offered in the except about Live Coding challenge and expand on these beliefs about live performance, whether rigorously rehearsed or spontaneously improvised. The concept of “liveness” in Live Coding seems to add a whole new layer to the dichotomy of rehearsed perfection and improvised happenings.

On the one hand, the section emphasizes Live Coding’s improvisatory nature, in which performers think and act in real time, always adjusting and responding to the evolving code. This reflects the unpredictability and spontaneity of an event, in which every moment becomes part of the performance, formed by circumstances that could not have been predicted beforehand. The idea that Live Coding performances might incorporate this level of spontaneity and dynamic interaction with technology calls into question my previous perception of live performance as either rigorously prepared or utterly improvised.

Moreover, the interdisciplinary nature of Live Coding, intersecting with fields like performance studies and choreography, expands the conceptual ground of liveness beyond traditional definitions. It redefines liveness as a dynamic and evolving concept shaped by processes of experiencing, making, and audiencing, challenging the notion that live performance must fit into predefined categories of rehearsed perfection or spontaneous improvisation.

So, I feel like the definition of being live itself is evolving as these newer forms of art and media are coming along. The multifaceted nature of liveness in Live Coding has opened up new possibilities for creative expression, human-machine collaboration, and interdisciplinary exploration, inviting me to embrace the dynamic and fluid nature of live performance in all its complexities. However, as many complexities and definitions ‘liveness’ may go on to possess, I still believe that the core idea behind it will be the same that I’ve understood – performing your craft the best you can for the intended viewers.

I am quite interested in the way in which the author of this chapter breaks down the different types of liveness of Live Coding. For instance, (a) the liveness of machines and technology to provide real time feedback to the performer’s  input or (b)  the liveness of the performer as they engage with the code and produce new iterations of pregrammed ideas. This chapter, and lessons from this course, have corrected a misconception I had about live coding in the beginning. I believed live coding was only the moments where code was produced completely from scratch. In particular, this reading explains pregramming and juxtaposes it to the existing algorithms within the software that we use to perform. Beyond the performer building functions, there are already algorithms in place to run Tidal Cycles and Hydra, and I imagine, algorithms in place to be able to read these algorithms. Perhaps this is more visible for Mercury, the live coding software I researched for my first project. This coding space was constructed in Max, making the different levels of notation and liveness within them easier to grasp for me.  Then, even if Live Coding looks like calling functions or do blocks, it is still very much Live Coding. What interests me here is how this element of liveness is also a creative decision. That is to say, as live coders, we do not only write music and visuals, we decide how our piece and performance will engage with liveness. Perhaps the liveness lies in Nick’s Rap performance, or in Jun’s incredibly fast typing… at the end of the day, it is also in the hands of the artist. Furthermore, the author brings up horizons of these liveneses. Predictive coding or composed improvisation amongst the used terms. I look forward to seeing the future of creative coding! Especially now that we are (undoubtedly) part of this amazing community <3