Laurie Spiegel’s exploration of “An Information Theory Based Compositional Model” presents a riveting intersection between the mathematical realm of information theory and the creative domain of music composition. This model, detailed in the Leonardo Music Journal, ingeniously applies concepts of signal optimization and noise management to craft musical compositions that challenge our traditional understanding of harmony and predictability.

Spiegel’s approach suggests that ‘noise’—often deemed undesirable in clear signal transmission—can be an essential element in creating a dynamic musical experience. This concept not only pushes the boundaries of compositional techniques but also prompts a deeper introspection on the nature of creativity and communication. It poses a compelling question: What defines ‘noise’ versus ‘signal’ in our perception, especially when these distinctions are inherently subjective?

Moreover, Spiegel’s contemplation on the essence of composition—whether it’s a genuine act of creation or a transformation of existing materials—invites us to reconsider the notion of originality in art. This perspective resonates with the postmodern view that creativity is a process of recombining and reinterpreting the ‘noise’ of our cultural and personal landscapes into coherent expressions. In essence, Spiegel’s model transcends its mathematical origins, offering a metaphor for the human condition. It reflects our own cognitive processes, where the ‘noise’ of competing memories and thoughts shapes our creative output and perception. Through this lens, Spiegel not only expands the possibilities of musical expression but also encourages us to find meaning and beauty amidst the chaos of our surroundings, harmonizing the dissonance of modern existence with the melody of human creativity.

The way the authors talk about live coding as – they don’t explicitly say that – a way of breaking free from algorithmic routines resonates with me more than I thought it would. Something about coding is you always write a program to get it to do the output we expect. We always want it to reach the “perfect” point where it exactly does what we tell it to do; even with AI, we train models to do what we want to a limit we are scared of not being able to estimate the output results. with live coding, “When we write code live, we adapt it to our needs, and it adapts us in return.” they said everything is an average software engineer’s natural fear. “Then we do not use computers; they use us” as they also said, what every coder naturally fears.

I do love coding, programming, trying to get the program to work, trying to reach a specific goal. Hence the idea of letting the code, the output lead your process scares me. It is scary to not be able to expect the output. It is scary to write words not knowing what they will do. To combine lines not knowing what the perfect next line looks like. But in a way, it feels relieving. It is relieving the pressure of perfection, and diving into the beauty of an uncertain result. It will take effort to break free from the routine. “Turning the laptop into a kind of universal instrument whose own capabilities and boundaries can in turn be redefined.” is a sentence that any computer scientist with a goal will not understand.

As a newcomer to live coding, I find the text to be a captivating journey into a realm that transcends the boundaries of conventional programming. Given my little experience with python, c++ and p5.js, the idea of writing code in real time, modifying programs on the fly, and projecting the entire coding process to an audience is both exciting and terrifying. The concept of making software “live” goes beyond my first impression of coding as a static process. The reciprocal relationship between the coder and the code, in which both adapt to one other in real time, provides a refreshing perspective. It challenges the idea of code as a static set of instructions by introducing a dynamic, changing entity that responds to the coder’s requirements.

The text’s analogy of live coding to an improvising composer in the context of music provides a relatable comparison. As a singer and songwriter myself,it’s like envisioning my computer as the instrument, much like my trusty guitar, and the lines of code as the chords forming the foundation for my digital melody. Embracing this paradigm allows me to approach live coding from a musician’s perspective. My laptop evolves into a diverse instrument, and the code serves as my musical language. Live coding creates a digital stage on which I can dynamically compose, improvise, and perform, transforming my code into a song that I may sing and share with the world. 

Thus, for someone new to live coding, this text provides an introduction to a dynamic and evolving field. It inspires me to explore coding’s creative possibilities, emphasizing improvisation, transparency, and the transformative power of live coding. It defies established beliefs about code’s rigidity, portraying it as a living, breathing entity that grows in real time, and invites me to embark on an intriguing journey that promises to be experimental and fun throughout.

This opening excerpt from Live Coding: A User’s Manual offers a compelling definition (or rather, a set of definitions) for the practice, art, and philosophy of “Live Coding.” I was immediately intrigued by how the author(s) addresses the strange nature of writing a book about live coding, much less one that seeks to be a manual (“there is something perverse in writing a book about live doing”). Posed with this question, I was then convinced by the claim that the very constraints of written text—the same ones that lend to this “perverse” disjunction—may also serve to be ample grounds for creative and critical thought. Within this very first portion of the book I saw what I thought to be the riveting soul of live coding: a performance practice that both works within and challenges the limitations of the media used (whether it be the computer used to code or even the book used as a manual).

Another idea that stood out to me was the identity and presence of the “user.” Much of the definition of live coding hinges the presentation of this live conversation held between the user and the machine. I was particularly struck by the part of the text in which the artist Olia Lialina was invoked to discuss the disappearance of the user. The mention of “smart” products and how “Big Tech wants computers to be invisible so our experience of using them becomes seemingly natural” thus goes in tandem (or rather, at odds with) how live coding may be seen as an ideologically potent practice that directly fights against this (corporate) trend to bring the user—and the computer—back into the visible foreground (or even existence) It then does not seem to be merely coincidental that the very title of the book describes itself as “A User‘s Manual.”

The reading touches upon some of professor’s explanation of ‘live coding’ in the first class. It’s something without a set definition or form, and it’s also the attempt to break the normalities of coding and software engineering.

As a computer science student, I’ve always felt like programming is more on the structured and restricting side, rather than the free and formless side. There’s a lot of style and format that has to be met, and there seems to be an answer to solving problems ‘effeciently.’ Hence, programming to me seems like a quiet war that I had to have within myself, trying to figure out what the best way of approach or thinking would be.

I think live coding will be liberating in that it’s not such a lonely fight. Live coders can share their approach and thinking on the spot with the audience. It may or may not be the best way, but regardless that thought process may be what makes the performance interesting.

Sarah Groff Hennign-Palermo’s expression that live coding is about “thinking otherwise about coding- what it can be, rather than what it is” makes me excited to try this new form of programming and coding.

I was quickly entrenched in reading Love Coding’s user manual. Alan F. Blackwell – the author – quickly grabbed my attention when he outright challenged the notion of a user. This chapter immediately brings up multiple dynamics that come into play when one is using a computer, a piece of software, code. I found it fascinating how Blackwell juxtaposes Big Tech’s aim to make computers invisible for a good user experience, and Live Coding’s emphasis on the code. Furthermore, other characteristics of live coding mentioned make me very curious about the field. For example, I had never considered the temporality of software. I wonder if being “constrained” within the present tense when coding live will alter my perspective of regular software. I am also very interested in the materiality of software. The idea presented by the author that live coding brings out the materiality of a computer and hardware is interesting to say the least.

The practice of live coding as per Blackwell’s introduction makes me recall the live poets that I saw on the streets of New Orleans. These people write poems for people on the spot on a typewriter. The magic of these experiences lies not on the poem, but on the temporality and visibility of the whole process. I am eager to explore live coding and recreate this sensation that the poets brought out! Perhaps exploring the elements that Blackwell points out through this comparison will be a useful experience!!

The answer to this question was somewhat unclear to me before I took this class. I had watched an IM showcase performance from this course before, but apart from finding it very cool I wasn’t sure what the ideas behind it were. The book Live Coding: A User’s Manual quotes live coder David Ogborn on why live coding should not have a fixed definition:

“To define something is to stake a claim to its future, to make a claim about what it should be or become. This makes me hesitate to define live coding.”


As mentioned in the text, Computer Science textbooks and other sources where static code is printed often become outdated pretty quickly due to the ever-changing nature of coding practices. This holds even more true for live coding, which is improvisatory and involves thinking on the fly, writing and rewriting all in a public performance.

I liked the reflectiveness this reading incited, especially when it came to questions such as what it means to be live. I had not been aware of the etymology of programming (“writing in public”). Given the isolationist nature of programming today, we could say that we have strayed a lot from these ancient origins, further highlighting the need for live coding. Opening up this usually private activity to the public provides a liberating creative aspect which is also helpful in building community.

Finally, I want to touch upon the analogy to musicians they made for live coding in a creative context. This was particularly the most exciting part for me. I have watched live jazz performances and been floored by the open jam sessions where random people would come together with their instruments and jam on the spot, not having met or practised together before. I do not know much about music theory, so I just learned that what they usually do is choose notes from a particular chord sheet. Live coding gives even more freedom to the performers and basically makes them the on-the-spot composers, which is daunting but exhilarating to imagine. Overall, this reading made me look forward to learning more about live coding and actually practising it myself.