Category: Spring 24

The reading presents live coding as a dynamic interplay between problem generation and problem-solving, where practitioners continuously test the boundaries of possibility. This unpredictable and experimental nature resonates with my own experience in preparing for class demonstrations, where the journey often involves navigating uncharted territory and embracing the unknown. Most of my class demo preparation so far involves trying different things, testing, adding new things, and experimenting without knowing the answers until I end up somewhere. It’s like driving without a destination, exploring the possibilities, and ending up wherever my curiosity takes me.

The concept of embodied knowledge and “knowing-in-action” reminded me of the quote “Knowledge is a rumor until it lives in the body” from a Sci-fi TV series The OA. While the practice of live coding itself requires a preconceived knowledge, I appreciated how the text pointed out that a risk and uncertainty are innate parts of the practice. It explains how Live coding performances actively disclose to an audience their moments of not knowing, of trial and error, and of testing something out. Therefore, embracing failure and trying to figure out how to make it work is part of the live coding process. However, This is easier said than done since one can sometimes panic and mess up even more when they are presenting in front of an audience.

In this text, the author discusses the cognitive process of Live Coding and how it encompasses different ways of thinking. For example, the author states that live coding “pressures the if-then thinking of computational logic toward the what-if of speculative experimentation.” It is interesting to view live coding as an experimental way of computing where open experimentation is actively encouraged compared to the standard way of programming. In some way, I felt the same way because, in live coding, you first try something, modify it, and expand on it until you like the outcome, while in the standard way of computing, you want to have logic in mind before you start typing. However, I think both are similar when you start improvising the code. In both scenarios, you want to understand what you wrote and improve – to make the codes perform what you imagined and to make them cleaner. For example, in live coding, you might want to group multiple sound layers into a structure or assign them to a variable after you find something you like. Similarly, when writing codes for software, you want to remove unnecessary lines or structure them in a more consistent way after you implement the functionality. Therefore, I think there are some areas in the process where live coding and other ways of computing overlap and differ.

I found the reading made me critically consider how complex live coding is, especially in relation to software engineering. Having a SWE background myself, I primarily saw programming as a way to fulfill requirements and the trial and error involved were always roadblocks to the end goal of creating a program that meets certain specifications. However, working in Hydra and TidalCycles, I found myself agreeing with the idea that the process of trial and error leads to roadblocks but also innovation. I may have a certain sound I’m trying to create, but in trying to do so, I may create a completely different sound I enjoy and incorporate into my final piece. The idea of no-how adds to this, with uncertainty of how something might look or sound comes new innovation and avenues of artistic expression.

This excerpt from Live Coding: A User’s Manual describes live coding as a unique hybrid art form that questions traditional assumptions regarding knowledge and challenges the categorical divisions of epistemology. Indeed, live coding is a multidisciplinary practice that draws on various modes of knowledge and the expression of said knowledge. If one is to envision knowledge as a spectrum ranging from the tacit and unconscious to the structured and explicitly taught, live coding is a practice that wills the practitioner to utilize both ends of the spectrum. And in doing so, live coding “demonstrates the coexistence, cooperation, and even complementarity between seemingly divergent knowledge paradigms” (219).

I have always felt that much of the appeal of live coding lies in its highly experimental nature. The philosophy of live coding encourages experimentation and contingency—in fact, it is very much defined by this acceptance of indeterminacy. Though the practice may demand some form of background competence (in computing and art, for example), the knowledge required most by live coding is that which enables one to interact with uncertainty. Live coding is thus an art form that is fueled by no-how rather than know-how; there is no set methodology or script that it abides by. It was fascinating to engage with the thought that the very existence of live coding, in embracing indeterminacy as a core tenet, prompts conversation regarding the subsequent need for alternative ways of and terms for understanding knowledge at large.

The epistemological survey of live coding through the guise of it being artistic research was a particularly eye-opening exploration of this medium for me. I appreciate these readings, as they help us place live coding – a relatively new practice – in broader contexts and conversations regarding media, art, technology, music, and culture. Live coding existing as a paradigm and a way of thinking at the intersection of all these goes to highlight the novel experimentalism of this language the author highlights. The discussions regarding improvisation, “making mistakes” and play during live coding as forms of experimentation, help me start seeing how we might approach this practice as a live band improv jam/open jam rather than a carefully rehearsed orchestra performance (a mindset I had been approaching this with).

The author explores the intersection of life coding with artistic research, delving into its fusion of technical expertise and intuitive, craft-based approaches. This blend fosters a dynamic interplay between problem-solving and the generation of obstacles. Viewing life coding as a discipline of trial and error, akin to “feeling one’s way,” highlights its reliance on technical computational knowledge while embracing a more intuitive process. In the realm of creative coding, the author often employs a technique of constant questioning, applying logic to resolve challenges in a perpetual cycle of doing and undoing, ultimately culminating in something beautiful. Yet, akin to art, determining the endpoint of this process proves elusive, as completion remains subjective.

Live coding, performed within a defined timeframe, prompts reflection on the nature of performance art—whether it is an ongoing process or a singular event. The author draws inspiration from Paolo Virno’s assertion that performing artists’ actions lack extrinsic goals, existing solely for their own occurrence. This concept reminds me of the Chafa Ghaddar’s fresco currently exhibited at the NYUAD Art Gallery. The fresco’s creation was partly performative, completed within the span of just a week, and the temporal constraints faced prompt contemplation regarding its ultimate completion. Ghaddar’s acceptance of presenting an unfinished piece reflects the essence of life coding, embracing real-time creation over finality.

Contemplating the eventual loss of Ghaddar’s fresco underscores the notion of permanence. The act of producing and subsequently losing artwork prompts deeper reflection on the essence of art itself, its ability to provoke thought, and its intrinsic value beyond material existence.

gibber is a live coding environment for audiovisual performance, which combines music synthesis and sequencing with ray-marching 3d graphics. Gibber was created by Charlie Roberts, who is a researcher and artist interested in live coding, computer music, and interactive systems. Gibber allows users to use JavaScript. To start with Gibber, there’s no need to install anything; you can begin coding directly in your web browser.There are lots of amazing live coding systems out there, a few things that make Gibber different include:

• Novel annotations and visualizations within the code editing environment.
• Unified semantics for sequencing audio and visuals.
• Support for coding with external audiovisual libraries, such as p5.js and hydra.
• Support for networked ensemble performances.

One of the strengths of Gibber is its intuitive interface and approach to visualizing and managing sequences for each channel.

It can also intigrate with visual.Gibber allows for the integration of visuals that can be manipulated in real-time alongside sound, offering a cohesive performance of audiovisual art. Visuals can react to the music, providing a more immersive and engaging experience for both the performer and the audience.

To sum up, Gibber provides an intuitive platform for users to explore musical concepts, programming, and audiovisual integration through immediate feedback and visual representation of sequences (even you don’t know music theory!)