This reading reiterates various concepts that we have discussed in class over the past few weeks. Most of the ideas were touched upon in one way or another, and a point that I, as well as anyone else I assume, resonate with is that as we listen to music, “we wait for something more, for change, uncertainty, the unpredictable”. Once any of these are encountered, the song or music would become more interesting or less boring. The change could be anything from introducing new instruments, breaking a cycle, speeding up the sounds, or adding a beat drop, which we have also discussed in class as we are always anticipating anything of this sort. The unpredictability, aspect is often a hit or miss I feel. Considering live coding, for example, if we would have been put on the spot to perform using tidal cycles with no prior background in what different audios or samples sound like and go into an unpredictable track, there is a chance it might be too noisy. However, there is still always a chance that it could also lead to a happy accident.


The “noise” I am bringing up is not the same as what the author mentions when she suggests the introduction of noise to make it sound more interesting. She discusses it in the same way that uncertainty would result in more engaging sounds, maybe by incorporating random corruption. This is a point that Aaron has made several times in class, adding ‘?’ or ‘degradeBy’ to drop random notes. This adds some spice to the music that we’re creating, avoiding repetition and possible boredom for the listener. From making these changes live together in class and when I was testing out and experimenting for the live performance earlier this week, I would definitely agree that these small changes actual have a significant impact on the sound. However, this leads to the same question that the author poses, is it more musical?

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.