Author: Yihan Zhang

This reading honestly made me rethink what I even consider “technology”. I usually think of it as something digital: code, software, devices, but here shamanism is described as a kind of technology too, just one that works through the body, ritual, and consciousness. That shift made me see technology as less about tools and more about methods of accessing and shaping experience.

One idea that really stuck with me is this idea of being in between states – what the reading calls a kind of dual consciousness. When you’re livecoding, you’re writing code in real time, but you’re also reacting to what the system outputs. You’re not fully in control because the code can behave unexpectedly, but you’re also not just observing. You’re in this feedback loop where you’re thinking, feeling, and responding all at once.

That’s where the connection to technoshamanism felt really strong to me. The reading talks about artists becoming a kind of “channel”, especially in the example of Pauline Oliveros, where music flows through her rather than being completely controlled. Livecoding can feel like that too – sometimes you’re not just writing code, you’re kind of listening to it, adjusting to it, almost collaborating with the machine. It becomes less about executing a plan and more about staying present in the moment.

I also think livecoding has a similar performative and even ritual-like aspect. There’s an audience, there’s real-time creation, and there’s always the possibility of failure. But instead of hiding errors, you incorporate them, which feels very similar to the idea of entering altered or expanded states where unpredictability is part of the process. It’s not exactly spiritual in the same way, but there’s definitely a shared emphasis on experience, presence, and transformation. At the same time, the reading made me a bit more aware of the risks of borrowing ideas from shamanism. It’s easy to take concepts like “ritual” or “expanded consciousness” and apply them to digital art in a superficial way. So I think the challenge is how to engage with these ideas meaningfully, without just turning them into aesthetics or metaphors.

The tension between “liveness” and “showmanship” is at the heart of Parkinson and Bell’s exploration of the laptop as a musical instrument. The authors provide a framework for evaluating what actually constitutes a live performance by comparing Deadmau5’s “playback” philosophy and Derek Bailey’s “instant composition” idea. My experience in NIME classes suggests that there is often a desperate scramble to justify the laptop’s presence on stage by layering it with external sensors, elaborate costumes, and “performative” gestures that frequently have a tenuous relationship with the actual sound generation. This creates a “narrative flow” that feels artificial – a costume draped over a simple sensor to distract the audience from the fact that the performer is just interacting with a computer. Live coding, however, suggests that this physical theater is unnecessary. By following the TOPLAP manifesto to “show us your screens”, the live coder moves the visible intricacy from the performer’s body to the performer’s mind, rendered in real-time as logic and syntax.

This shift toward the laptop as a minimum medium aligns with Bailey’s concept of the “instrumental impulse”. Live coding embraces the computer’s inherent, unadulterated affordances: the keyboard, the mouse, and the code. Parkinson and Bell argue that the “natural resources” of the laptop are not found in how it can be made to mimic a guitar’s physicality, but in its capacity for algorithmic complexity and generative uncertainty. In this light, the laptop is a like sophisticated adding machine that becomes an instrument through the elegance of the code written in the moment. The “liveness” is found in the risk of the syntax error and the transparency of the thought process, rather than the sweat of a choreographed movement.

Ultimately, this reading suggests that live coding offers a more honest path for electronic music than the “spectacle” of EDM or the “gestural narrative” of some NIME practices. If, as Francisco Lopez suggests, electronic music doesn’t inherently need the “concert hall tradition” of physical gesture, then live coding creates a new kind of stage presence that is purely functional. It replaces the performer-as-figurehead with the performer-as-architect. This raises a critical question for our practice: if we strip away the costumes and the sensors to focus on the “minimum medium” of the screen, does the audience’s lack of “code literacy” turn our logic back into a mere visual spectacle? If the audience cannot read the “instrument” we are playing, are we simply trading one type of misunderstood narrative for another?

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

What struck me immediately even before fully reading was the visual experience of the PDF itself. The text isn’t clean or stable; it’s fragmented, stretched, interrupted by blocks of symbols and noise. It feels like the document is actively “glitching” as you read it. The manifesto sort of performs the glitch theory rather than just describing it. The layout forces me to slow down, to become aware of reading as a mediated process. It almost resists being consumed in a normal, linear way.

This made me realize that the glitch here is highly embodied in the medium. The scattered typography, the visual noise, and the interruptions act like breaks in a signal, constantly pulling me out of passive reading. In a way, I felt like I was navigating a system that was slightly broken but also strangely expressive. That tension between frustration and curiosity felt intentional.

In livecoding, the process is visible and unstable: errors, unexpected outputs, or crashes become part of the performance rather than something to hide. Similar to Menkman’s idea, the “glitch” is nothing like a failure but a moment where the system reveals itself. When code behaves unpredictably during a live set, it creates a kind of raw, real-time interaction between the artist, the machine and the audience.

I think both glitch aesthetics and livecoding challenge this idea that digital media should be smooth and optimized. Instead they expose the underlying structure: the code, the errors, the limits. They make the medium feel alive. I was browsing albert and ran into one class on named “Experiments in the Future of Producing/Performing” which, according to the description, encourages students to hack the music/visual software and conduct software abuse in order to challenge conventional recorded music/visual products. It says, “Sound (and other kinds of art) is an unstable art form.” Reading this manifesto made me more aware of how much I usually expect technology to “just work,” and how much potential there is when it doesn’t.

It also makes me question my own creative practice: am I just using tools as intended, or am I willing to push them to the point where they break and become something else?