Initially, my thoughts regarding live coding was largely limited to seeing it as a performance where the main “output” of the performance was the music/ visuals resulting from editing the code live.
The reading for this week touches upon certain aspects of live coding that I hadn’t really accounted for. One facet that I found intriguing was related to the style of code that live coders use. Especially since the live demos from last class, I have been noticing stylistic differences in the way people approach live coding – whether it’s the way they have arranged the code, whether they do it from scratch or modify (even within modifications – do they change numbers or function), and comments. This adds a lot to the storytelling aspect of the piece as well, since the live coders build up to a story with modifications and comments – with the code itself and the way it’s written playing a huge part in the performance. This was not something I thought of when I was initially approaching live coding and I largely attributed the performance to just the visuals and the music.
Moreover, looking at live coding in contrast to other performances is also an interesting feature to examine. When looking at live coding, you cannot really perfect every aspect of the performance and there’s some form of abstraction you have to create – where you could perhaps decide on the general “theme” and flow of the code. Whereas with music or dance, you can still achieve some level of precision since improvisation is not really essential. Adding on that, there’s also the general pace of the performance which would be usually higher, and when taking into account both these factors: improvisation and high pace – it adds onto a degree of randomness and spontaneity to the performance, making it very experimental.
Finally, on the subject of comparing coding to live coding – the former works around a lot of established concepts and there’s general practices on how to make the final product more efficient – whether it’s the run time or memory usage. With live coding, since the outcome is more immediate – this aspect is removed and this brings about ideas that are more out-of-the-box and as the reading mentioned, it discourages “overthinking”.
After this reading, I am a little confused about what Live Coding is. It is definitely coding live in front of the audience – but my question is more about the approach regarding that. Do you practice your code thoroughly, memorize what each step is, remember what to do next, account for possible mishaps – just like one prepares for music, dance, or theatre performance? Practice and practice until you you can’t get it wrong? Or you practice different code combinations, try out your hands at different things, but then live code all of that improv? No set sequence, no idea of what you’ll do next but improvise based on the audience’s reactions.
The latter is more risk-taking and the former is risk-aversing. In the former approach, you practice and perfect everything and leave minimal things for chance. In this, the live-coding idea is a performance in front of an audience where you code ‘live’ (in real-time) and show them whatever you are coding. However, it is a rehearsed performance. In the second approach, you think about ideas there and then, make a sequence at the moment, you are unsure of the output and also have to think about how to reverse it if it doesn’t look as good. It is like a theatre improv performance.
The former approach was my interpretation of live coding and mostly what I presented for my first assignment. But, this reading makes me wonder otherwise. In multiple instances, I get a feeling that artists love to engage in live coding because they see spontaneity as a result of improvisation as a challenge. One of the subjects said that “[Live coding] allows for improvisation and spontaneity and discourages over-thinking.” And another one said, “The higher pace of live coding leads to more impulsive choices which keep things more interesting to create.” So is live coding supposed to be a spontaneous challenge, an improv? Can it not be a rehearsed performance? Does that take away from the creativity of the artist performing live?
In the article, the author uses this spontaneity and impulsiveness in live coding as a reason to justify how it allows creative minds to express their music. The author says, “Such riskier ways of making music are more likely to produce aberrant output, providing the opportunity to adjust your style through transformational creativity.” But my question is, is improvising live the only way to define creativity? Creativity is a broader topic. Sampling sequences of audio/music or video in a way to a tell story is also creativity. This creative piece can then be rehearsed and perfected to perform live in front of the audience. That does not make it less creative.
I then believe that both approaches are correct, or say, neither of them are incorrect. It depends on where you are at and how comfortable you are with live coding. If you are just starting out, you may want to rehearse everything beforehand, and that is absolutely alright. If you are experienced, you may want to improvise live and that challenge could be your performance. Whatever your approach may be, one should not be defined as more creative than the other or justified in that way.
Language is often seen as an environment to create work in. I Rather see computer language sued for live coding as a petri dish full of programmer’s creativity, a fostering environment for people to discover their potential than the creative agent itself. The extent to which it is fostering also depends on programmers’ own adaptations and personalizations. The fact that the language is highly capable of coping indicates its flexibility in no doubt.
The more fundamental the change, we are opened to more possibilities in terms of creating art. Thus, with technological development in the future, we would want to believe that computer agents will have the ability to complete live coding performances in real-time, on top of the programmer’s real-time updated code. This new combination is expected to trigger more inspiration and thus new forms of creativity.
It is their work but at the same time it comes with an instruction as to how to reproduce their work from scratch. Even with generic coding pieces, each programmer have their own style. Distinctiveness in coding style is so important that it is one of the metrics when people evaluate a piece of code. On the other hand, the most satisfying artwork of an artist is always the best at reflecting their personal style. These coinciding idea suggest that coding and art are already interconnected and live coding is doing us a favor by combining the two in a harmonious and effortless way.
“What is the difference between live coding a piece of music and composing it in the sequencer (live coding an animation and drawing one)? In other words, how does live coding affect the way you produce your work, and how does it affect the end result?”
While showing my friends some of the examples from class, I was asked this question and wondered to myself “what makes coding it live so special?” I think that after reading the results of this survey, I realized that, to the live coder, what makes live coding unique is the risk that comes with it. It heavily relies on improvisation (despite the practice that goes into a performance), the live coder could have a new idea while performing and decide to try it out, giving a completely unexpected outcome. But does this risk hinder the live coder’s creativity because of the notion that this performance has to be perfect?
The risk factor associated with live coding is also why I don’t think that live coding can become fully computer generated. It will take out the factor of human error, making it appear the same as any other composition, with the only difference being that the audience can view the code. Moreover, it was mentioned that the code written during a performance is a representation of the live coder’s style. If live coding becomes computer generated, I think that it would lose this “style” that makes each live coding performance unique.
As I’m doing a double major in Computer Science and Interactive Media, “live coding” to me is associated with two things. The first being live coding interviews for CS where it’s usually 1 or 2 specialized interviewers observing everything you type, assessing how you’re thinking, and evaluating the final result. The other one is, as defined in the reading, “improvising music or video animation through live edits of source code”. While both, in a sense, are similar in terms of doing live updates in running code, the mindset and output, I believe, are drastically different.
The author discusses how live coding is riskier, and this definitely applies to both cases, but in the case of creativity and making art, it’s easier to shift the performance to another direction after a mistake is done. Yes, the end result would not be “as clean as an “offline-composition””, but the artist/performer/coder can probably still make it work by taking an alternate track that they wouldn’t have taken otherwise. This is also an incentive to keep exploring even if it’s live, because at the end of the day you have significant room for improvisation. On the other hand, in live coding interviews, every tiny mistake makes a difference, you could easily lose a job opportunity by messing up one line of code or not writing the most efficient code from the first try; there is not much room for experimentation.
On another note, the author raised a question that I found to be very interesting. They were asking about the extent to which live coders adapt their computer languages and personalize their environments to aid creativity. I believe that there is no specific response to this question and an easy example to consider is our first live performance in class. Everyone came prepared to show their work, but there was a broad range of initially setup/written out code. Some people wrote everything on the spot, whether improvising or from memory, some people had comments on their screens or commented out code, others had it written down somewhere else, others had functions prepared, and others had a large percentage of the code but made changes directly to it. All of these are examples that show how the “extent” could not be clearly defined.
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.