Author: Yihan Zhang

This reading made me realize how normal it actually is to move between different mediums, even though it sometimes feels like you’re supposed to “pick one thing.” The idea of the artist-musician isn’t new, instead it goes all the way back to people like Leonardo da Vinci. but what changes is how each era makes that crossing easier or harder.

What I found interesting is how a lot of these shifts come from both artistic and practical reasons. Sometimes people moved between art and music because of curiosity or experimentation, but sometimes it was also just about survival like which field could actually make money at the time. That made it feel less romantic and more real. Being interdisciplinary isn’t always a pure artistic choice; it’s also shaped by context.

The part about abstraction and how visual artists borrowed concepts from music (like composition, rhythm, improvisation) also stood out to me. It made me think about how we naturally use one medium to understand another. Like when I’m working visually, I often think in terms of timing or layering, which feels very musical even if I’m not consciously trying to “make music.” Livecoding already blurs the line between musician and artist: you’re writing code (which feels technical), but the output can be sound, visuals, or both at the same time. It’s not clearly one discipline. And similar to what the reading describes with movements like Fluxus or experimental music, livecoding also includes performance, unpredictability, and sometimes even failure as part of the work.

I also liked the idea that in scenes like punk or early electronic music, intensity and experimentation mattered more than technical perfection. That feels really close to livecoding culture too. You don’t have to be a “perfect” programmer or musician—the point is more about what you do with the system in the moment.

The section about the computer as a “universal machine” also felt especially relevant. Now one device can handle sound, visuals, performance, and distribution all at once. That’s basically what livecoding relies on—you’re using the same tool to generate and manipulate everything in real time. It makes the idea of being just a “musician” or just a “visual artist” feel kind of outdated.

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