What if a musicology of live coding were to develop, where researchers deconstruct the code behind live coding improvisations as part of their work?

This was the most exciting line of the reading for me. To clarify, prior to reading the line for a second time, I was thinking of “musicology” as a study of past music cultures. For the past two weeks, I’ve been coming to class and feeling completely engrossed in how new what we’re learning feels. I would think to myself that we’re part of this rising movement of live coders, or that we’re gaining the skills to join some kind of exclusive club of artists that can have this awe-inducing effect on audiences. Since my brain has been so occupied with the novelty of it all, I forgot that like everything else, live coding will become this historical thing that students study for some background context in the classrooms of the future. The possibility of that excites me! I want to see where the practice emerged, and where it flourished. I would love to see some anthropologist’s ethnographic research of an algorave, or someone’s political analysis of live coding circles. Maybe I’m getting ahead of myself, but I do feel that sometimes creative coders and new media artists need to think of more than just the modern and technical aspects of their (our?) work. Perhaps this is why documentation, discussion sessions, and critical analyses of creative coding are so important!

I believe that in order to be a live coder, a certain sense of experimentation and creativity needs to be involved, and I found that this reading brought up a lot of points that reinforced this concept. One topic in particular has to do with ownership, and it made me reflect back on some discussions that we had in class. The uniqueness of live coding, and something that had originally drawn me to the course, is the ability to see the coders making real changes in real time. Prior to this class, I had not realized the importance of such a display. By putting the coder’s work at the forefront of both the visual and auditory elements, we are bringing up a very important topic of ownership and inclusion.

“Live coding allows a change in code to be heard or seen immediately in the output, with no forced break between action and reception.”

There is something so powerful about the concept above. We are bringing in the audience into an experience that would otherwise be a private one. The process of creating something, whether a game or a website, is something that is not one that involves others in every step. With live coding, the audience is able to go on that journey with the creator. Even though it is a performance, there still is a sense of inclusion. It is such a unique experience, and reading this paper only helped me further understand that.

“Improvisation, instant, high-risk yet immersive”, is my initial impression of live coding after reading “Live Coding Towards Computational Creativity”. 

I think live coding is definitely for those “adventurers who enjoy the adrenaline rush brought by the unknown results”. This is to say, based on the content of the artist’s programming, the content presented by live coding may show strong randomness, which just as the following quote from the article demonstrates,

“When I work on writing a piece … I can perfect each sound to beprecisely as I intend it to be, whereas [when] live coding I have to be more generalised as to my intentions.“

it makes both the artist and the audience unable to accurately predict the specific output of the programming. 

When doing live coding, artists also need to take many risks, some of which we have already experienced in Tuesday’s class, such as syntax errors in programming that cause output to fail. In addition, as the following quote indicates,

“Live Coding is riskier, and one has to live with [unfifit decisions]. You can’t just go one step back unless you do it with a nice pirouette.“

Many times we make a complete work with multiple sub-contents through live coding, if one of them is not suitable and we show it, it may destroy the coherence and effect of the whole work. Therefore, I would question whether live coding is completely improvised art and whether it is completely free from the influence of traditional art. Based on my observation in Tuesday’s class, I would presume that live coding artists might have already prepared a rough outline of what they’re going to program before they do the performance so that there is both coherence and consistency in the whole work and randomness in the specifics. In my opinion, consistency and coherence are the characteristics of traditional art. For example, when we live coding music, we still tend to stick to the rhythm and rhythm of common music.

So in my opinion, what really makes live coding different from traditional artistic expression is its performance process, as Aaron said during class, “the process of people programming is as exciting as the output they get from programming”. In traditional forms of artistic expression, works often only focus on one sense. For example, music corresponds to hearing, and paintings correspond to vision. In comparison, live coding allows the audience to enjoy both visual and auditory media, and there are real people editing the production process in real-time, which makes the entire presentation process very immersive.

 

 

If you ask me to define computational creativity, I can only offer general description like “creative behavior or production done by/with the computer,” because it’s just so broad. Therefore, live coding towards computational creativity seemed a bit intangible for me initially. Yet, this article revealed some patterns on my canvas that I can grab for this branch of knowledge, by discussing “whether human live coders can be replaced by software creative agents” (1).

 

Analogy of generative art comes abruptly for me, but I see it as to help clarify what the problem is regarding authorship and creativity. Whether coded behind or coded live, there are people doing creative work iterations. It is time-based and thoughts-based. 

 

What I found fascinating about live coding is that the behavior of “coding” and the code are integrated in the art and performance as a whole. As a result, programming was put on the stage for being thought on and even appreciated. Yet, the code itself is not a production. In the article, this sentence set me into some philosophical thinking: “Their code is not their work, but a high level description of how to make their work” (2). If “how to make their work” can show one’s style, is it somehow also a type of work? In addition, I still kept thinking: in a hyper-digital world, should the programs and principles that lie behind also have equal value with the work they execute? 

 

My biggest takeaway is about live coding’s novelty in production. Somehow, all the quotes indicate keywords like improvisation, abstraction, and spontaneity. The immediacy of coding results highlights spontaneous thoughts, which is different from software development experiences that are slow and arduous. It accepts imperfection and highlights time/present. It is by this that live coding shows value in art and creativity. However, these words sound like alarm bells for me. I’m a person who is used to preparing in advance. I experience work such as Arduino and 3D modeling as “slow and arduous”. Sometimes I also seek perfection and over-think… However, I don’t see them as discouragement for me in live coding. They are just different ways of doing things, and I want to try new things. At least, as one quote says, the “skills and confidence acquired” would last. I really expect to see how my view on imperfection and improvisation would change after this class.

Hello! I didn’t have time to show everything today. I really wanted to show this code but I ran out of time 🙈, so I’m attaching a video here:

This is the code:

shape(2).color(1,1,0.5).rotate(({time})=>(time%360)/2)
.modulate(osc(25,0.1,0.5)
.kaleid(50)
.scale(({time})=>Math.sin(time*1)*0.5+1)
.modulate(noise(0.6,0.5)),0.5)

The points that resonated most with me in this article were AI and creativity. 

First, compared to generative art, live coding can have better connections with audiences. Audiences can see how the code changes with how the graphics or music changes. In this way, audiences can also realize that the live coders are doing something to the codes. The codes are under the control of the live coders, so the coders create and hold the authorship of these codes. 

In fact, there is no difference of authorship between live coded and generative art.

This is what I don’t agree with to some extent in this passage of 2010. Nowadays, “generative art” is bonded with AI or machine learning. These days, some AI image generators become hot topics. By machine learning, the users (now “creators” are absent, except the creators of the tool)only need to input keywords, then the image can be output. Though images generated by programs are hard to define as Art, many people have difficulty separating human paintings from the works of AI. 

This is an image generated by Stable Diffusion.

How to define generative art is not what I want to do now. Whatever, live coding is a performance form combining coding, which is usually put backstage, and improvisation, a representation of creativity. Such a combination makes live coding a unique performance form as the passage goes: make tools (programming) as a creative performance. 

I still wonder what the point of live coding is.The authors seem thrilled by the concept because it resolves an issue of ‘authorship’. In other words, live coding puts the human in a position where it is obvious that they, and not the software. are the artist. I’m not sure if the authors really care about authorship as much as recognition though. Most artists wouldn’t mind a little pat on the back for all the tedious work that led to the final result. But the whole point of art to me is to make the audience wonder about the journey that led to the final outwork. We stand in front of art and think: what does this mean, how was this drawn? And that thinking process, this series of questions, is what we artists provide our audiences. I’m not sure if it’s worth giving that up just so that the audience understands how hard it is to create our art pieces or realize that it’s us and not the software that’s drawing stuff.

 

The article also frames live coding as a novel way of self-expression because of the different notion of time. But I believe these same creative incentives can be reproduced in live performance without the need for risk-taking or literal coding–which I find optimistic at best and elitist at worst considering most people wouldn’t understand the code anyway.