I think the Deadmau5 vs Bailey comparison is a really clever way to frame what live coding is. He is being honest about something that a lot of performers pretend is not happening, and I think there is something refreshing about that. For me the whole point of live coding is that something could go wrong, and that tension is what makes it feel alive. A perfectly pre planned show with synced lights and video is impressive in its own way but it does not give me that feeling.

The Bailey section hit different because I actually feel like that philosophy is closer to how I think about using Hydra and TidalCycles. I do not always know what a pattern is going to sound like or what a modulation value is going to do to a visual until I try it, and I think that exploratory quality is what makes it feel like playing an instrument rather than just operating software. I have had some of my best moments in live coding sessions when the code did something I did not expect and I just leaned into it instead of fixing it.

Below is my live coding practice for this week.

Demo 1 

// feedback
src(s0).mult(osc(10,0,1)).out()
osc(2,0.,1).scale(0.5).modulate(noise(3,0.01),1).out(o1)
src(o2).modulate(src(o1).add(solid(1,1),-0.5),.005).blend(src(o0).add(o0).add(o0).add(o0),0.25).out(o2)
render(o2)

let p5 = new P5()

s0.init({src: p5.canvas})
p5.hide()

let hearts = []
let colors = ["#edbba8", "#e66f3c", "#c6b6d5", "#f1d147", "#a4cd98", "#95accb"]

class Heart {
  constructor(p) {
    this.p = p 
    this.x = p.random(p.width)
    this.y = -20
    this.r = p.random(0.5, 1.2)
    this.dy = p.random(1, 3)
    this.c = p.random(colors)
  }

  display() {
    this.p.push()
    this.p.translate(this.x, this.y)
    this.p.fill(this.c)
    this.p.noStroke()
    this.p.beginShape()
    for (let i = 0; i < this.p.TWO_PI; i += 0.1) {
      let x = 16 * Math.pow(Math.sin(i), 3) * this.r
      let y = (13 * Math.cos(i) - 5 * Math.cos(2 * i) - 2 * Math.cos(3 * i) - Math.cos(4 * i)) * -this.r
      this.p.vertex(x, y)
    }
    this.p.endShape(this.p.CLOSE)
    this.p.pop()
  }

  fall() {
    this.y += this.dy
  }
}

p5.draw = () => {
  p5.clear() 
  if (p5.frameCount % 10 == 0) {
    hearts.push(new Heart(p5))
  }

  for (let i = hearts.length - 1; i >= 0; i--) {
    hearts[i].display()
    hearts[i].fall()

    if (hearts[i].y > p5.height + 20) {
      hearts.splice(i, 1)
    }
  }
}

src(s0)
  .modulate(noise(3), 0.1)
  .out()

Demo 2

Before reading Rosa Menkman’s Glitch Studies Manifesto, I mostly saw glitches as problems that good programming should prevent. In coding, we are usually trained to build systems that handle failures so smoothly that users never notice them. Because of that, I had always thought of noise as something unwanted. Menkman’s discussion changed that perspective by showing that noise and glitches can do more than interrupt a system — they can expose the hidden structures behind technology and question the idea that digital media must always be clean and flawless.

Even though I still understand why people prefer smooth and reliable devices, the reading made me value noise in a different way. I can see this reflected in today’s renewed interest in vintage cameras and older technologies, where imperfections are often appreciated rather than avoided. Glitch art does something similar: it turns error into expression and gives artists a way to challenge both technological standards and larger social or political systems. What stands out to me most is that meaning depends on perspective. The artist may see intention and structure in the glitch, while the viewer may still experience it as disruption. That made me realize that our idea of a “perfect” program or technology is not fixed, but shaped by how we choose to interpret it.