“I consider randomness a relativistic phenomenon: any signal, no matter how internally consistent or meaningful it is within its own context, may be perceived as random noise relative to some other coherent signal.”

In this reading, the author delves into the topic of music composition and randomness, and makes us question whether musical composition even exists. The author argues that randomness is relative, and that any sound, if placed in a different context, can be considered random sound. I am not convinced by this argument. Firstly, I do not believe that random, unpredictable sounds make a ‘composition’ more musical. I believe that all music has meaning, and if a series of random sounds are arranged together, there is no meaning behind it and therefore it is not music.

Putting this in the context of live coding, I don’t know if I can call the sounds created by live coding ‘music’, mainly because live coding relies on unpredictability and randomness as an art form. Perhaps a live coding piece which has already been rehearsed, with each sound predetermined could be considered music, but I personally believe that live coding is only ‘live’ if the artist engages in some improvisation.

 

Throughout most of my life, I have understood music composition to be an arrangement of sounds in a specific manner and duration in order to convey a mood (message).
However, this reading aimed to question that, but it left me feeling confused. At first, it starts by explaining that a basic melody is not necessarily music. Music needs to have:

  • development
  • evolution
  • form
  • a sense of anticipation
  • I’m not sure if perhaps I did not understand the reading but I find that definition to be contradictory with the message of the paper. The author explains that a repeating melody lacks anticipation because the audience already knows what type of information to expect. However, modern songs are actually 1-3 minutes in length (not very long and with repeating melodies) and most people tend to listen to songs over and over again. Of course, after a certain amount of time, people get exhausted from listening to the same thing, but then, wouldn’t that mean that the length rather than the repetition is what is important in a composition?

    The reading touches on the topic of random generation vs random corruption, but in traditional music composition, things are rarely random. So perhaps this randomness is something that computer composition could add (which is still not 100% random because computers till now can not create 100% randomness). It seems to me that it could actually allow for a more dynamic listening experience as each version of a song could be slightly different to the next because there is randomness associate.

    Then, I’m also wondering if improvisaton can be thought as spontaneous composition, or basically creating a melody in the spot. Tying to this, the reading also concerned itself with what an original piece is and what it is not. There is a process to compose music, there are rules that can be bend to the author’s will and there is inspiration from existing music. So if most of the composition process is derived from previous songs/works and rules, then what makes a piece original?

    On a side note, it was interesting for me to read about how people process, perceive and listen to information differently because that was exactly what the Apple Launch said, using it to justify buying the new AirPods Pro.

    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.