Author: Ruiqi Liu

Hydra Code

let p5 = new P5()
s0.init({src: p5.canvas})
src(s0).out()
let x = 0;
let y = 5;
let gridSize = 1000;
let r = 255;
p5.hide();
p5.strokeWeight(1);
p5.stroke(0);
p5.noFill();
p5.frameRate(20);
p5.draw = ()=>{
  p5.background(20);
    for ( x = 0; x < p5.width; x += (gridSize*(0.7+cc[0]/2))){
      for ( y = 0; y < p5.height; y += (gridSize*(0.7+cc[0]/2))){
        p5.fill(p5.map(255,0,127,0,255));
        let rand = p5.random(-5,5);
        p5.rect(x,y,gridSize+rand,gridSize+rand);
    }
  }
}

src(o0)
  .invert(()=>ccActual[1])
  .modulateScale(osc(20,[0.1,0.6]))
  .mask(shape(30,()=>cc[0]*1.5).scale(1,window.innerHeight/window.innerWidth,1))
  .modulatePixelate(noise(20,10),400)
  .mult(solid(1,()=>ccActual[1],()=>ccActual[1],1))
  .out(o1)
render(o1)

Tidal Code


d1 $ slow 2 $ s "superhammond*8" # note (scale "lydian" ("[a3*2] ~ a3 a3 c4 [e4 g4]")) # gain 1.2 # lpf 1000


d2 
$ fast 1
$ chop 64
$ "moog(5,8)"
   # gain 1.2
# up "-1"
  #legato 4
#crush (slow 2(range 1.2 1.8 sine))

d3 
$ fast 1
$ chop 32
$ "moog(5,8)"
# speed "3 2"
   # gain 0.8
# up 4
  #legato 4

d4 $ fast 0.5 $ chop 32 $ "ade:6" #speed "4 3" #room 1

p "ccMaskSize" $ ccv "127 30 60 5" # ccn "0" # s "midi"

p "ccColor" $ ccv "<1 0>" # ccn "1" # s "midi"
        

d5 $ slow 2 $ s "blip:8(3,8)" # gain 1.2 # up "<-1 1>"


d6 $ slow 2 $ jux rev $ s "hh*8 sn*4" # crush 8 # gain 0.8 # legato 1

Ruiqi Liu:

In this performance, I am in charge of the visual. I sticked to my preferred minimalistic and geometrical style. I wrote the basic shape using for loop using p5 instances, and then added effects using hydra on top of that. I also tried with lines, circles, ellipse, and squares, and found out that grids look best.

Rebecca & Mike:
We had three main iterations on our tidal script when experimenting with long samples from different genres as we wanted to play with the chop and striate functions. In the early iterations of in-group jams, we developed our drum circle from acid and ambient samples respectively as these two genres have a strong contrast. The acid samples feature a strong energy and a psychedelic feeling, while the ambient samples create a peaceful and calm atmosphere of the audio. These practices helped us open up our mind and had a better idea of how to arrange patterns according to the various textures from and potential emotions brought by the samples. In the final version, we decided to use built-in samples and synth, and utilize effects like legato, and chop to create our own sounds instead of directly using ambient samples. We also wanted to include a transition and an ending to make our project more complete, so we added a strong crush effect to let the synth sound raw and distorted, while adding a strong color transition for the pattern. For the ending, we gradually minimized the pattern and the audio at the same time, and eventually kept the ambient synth on going.

Reading about “the instrumental impulse” in this paper reminded me of the psychological concept of Perceptual Narrowing—a cognitive phenomenon where, for efficiency, humans develop schemas that help make fast decisions, but in doing so, lose access to a broader range of possibilities. When I was studying about surrealism, surrealists believed one way to return to authenticity was through Automatism—letting the mind wander freely, uncensored. This mirrors the spirit of improvisation, where intuition precedes logic and the unknown is welcomed. I believe this can be applied to live-coding, or, in broader concept, improvisation becomes a tool not just for performance, but for rediscovering what expression and creativity can mean beyond established norms.

I was especially moved by the author’s framing of the computer as a romantic, expressive instrument—not just a cold rational machine. Just like traditional instruments, laptops in live coding are personalized by each performer’s unique techniques and approaches. In this way, every computer becomes a partner, emotionally bonded with the artist. This echoes how traditional musicians develop intimate relationships with their instruments, shaping their identity over time.

Lastly, I found the contrast between live coding and tools like Ableton or Radial insightful. While those tools prioritize accessibility and user-friendly design, live coding embraces the rawness of syntax and structural logic. From my perspective, neither is better or worse—just different in intention. Live coding reflects the artists’ passion for exploring the pure beauty of machine, representing a more experimental, deeply embodied relationship with technology—one that reimagines both the machine and the human in the act of creation.

I started this project with the music first and then creating and matching with the visuals.

At first, I followed Aaron’s instructions and just wrote some random blocks of compositions. Some of them are bright, some of them are creepy (is this the right word?) and they sounds irrelevant to each other. (Then I need to give credit to my amazing roommate that I got inspired from what she told me that it sounds like an agent lurking)

Then I basically applied three steps: I first adjust the samples to be the similar instruments, and then try to adjust the scale from major to minor, or other scales that I experiment to make them have similar styles. Lastly I fine-tuned some notes to make them more like a coherent whole. I also read through the documentation of the music structure and learned a bit of the power of silence between the build up and the drop so I kept it, but then to add relevance to the theme I added the female voice of “Warning”. Since this is like a story telling project to me, I added also a little bit of narrative samples and an opening ending to the structure.

For the visual part, I am always a fan of simple, red and black stuff, so I kept doing that. I have decided at a very early point to stick to one main visual and evolve different form over time. This cone-like visual gives me a sense of a tunnel/terminal where the agent is lurking around. Part of the visual evolution is due to how the sound sounds like, but an even bigger part of the visual is actually determined by the story in my mind (Agent enter the terminal -> terminal is like a maze with multiple entrance -> agent found the terminal and got in -> agent pull out the gun and break into the secret place -> the fight begin -> open ending) I made the visuals follow the basic plot and create them based on my imagination. Lastly, I tried to match them with the midi communication between Tidal and Hydra.

My Tidal Code

setcps(135/60/4)

hush

-- reset everything
do
  d11 $ ccv 0 # ccn 1 # s "midi"
  d12 $ ccv 1 # ccn 2 # s "midi"
  d13 $ ccv 0 # ccn 3 # s "midi"
  d14 $ ccv 0 # ccn 4 # s "midi"

do
  d1
    $ qtrigger $ filterWhen(>=0)
    $ struct "<[[t@3 t] t t@2]>" $ s "808hc"
    # cut 1
    # room 0.4
    # speed "<0.8 1 0.8 0.5>"
  d11 $ ccv 0 # ccn 1 # s "midi"

do
  d2
    $ qtrigger $ filterWhen(>=0)
    $ s "<hh(3,8,1) hh(5,8)>"
  d3 $ qtrigger $ filterWhen (>=0) $ s "~ 808hc*2 ~!2" # note (scale "minor" "<15 21 15 3>") # room 0.6
  d11 $ qtrigger $ ccv "<20 1>" # ccn 1 # s "midi"
  d12 $ ccv "1" # ccn 2 # s "midi"



do
  d4
    $ qtrigger $ filterWhen (>=0)
    $ struct "t!6 f [t t@2 f]"
    $ whenmod 4 3 ((# note (scale "minor" "[0,2,4]!4 [0,2,6] [0,2,4]!3"-12)))
    $ s "808hc"
    # note ((scale "minor" "<[<<22 20> 15> 7 3 1]>")-12)
    # legato 0.6
    # gain (range 0.7 1.3 sine)
    # room 0.6
  d11 $ qtrigger $ filterWhen (>=0) $ ccv "<<40 60> <40 60>>" # ccn 1 # s "midi"
  d12 $ ccv "<1 <2 3>>" # ccn 2 # s "midi"

hush

do
  d5 $ stack [
    s "bass3*8" # speed ("<1.2 1>") # room 0.4,
    slow 2 $ s "glitch:3(3,8) glitch:2"
    ]
  d6 $ s "hh*8"
  d12
    $ qtrigger $ filterWhen (>=0)
    $ ccv "<127 20 60 [[50 35] [20 10] [40 10] 10]>" # ccn 1 # s "midi"


do
  d1 silence
  d6 silence
  d8 $ s "bass3(12,16)" # speed ("<1.2 1>") # room 0.4
  d5 $ qtrigger $ filterWhen (>=0) $ seqP [
    (0,8, s "sharp:2*4"
      # lpfbus 1 (segment 1000 (slow 8 (range 100 7000 saw)))
      # lpq 0.3
      # gain  (slow 8 (range 0.4 2 saw))
      -- # speed (range 0.3 4 saw),
      # room 0.3)
    ]
  d9 $ stack [
    slow 2 (s "~ glitch:3"),
    struct "t!2 [f t] [t f]" $ s "[909 sd]!2"  # room 0.6,
    qtrigger $ filterWhen (>=0) $ slow 4 $ s "hh*<4 8 16 32>"
    ]
  d6 $ s "~!3 <sharp:6 ~>" # room 0.3 # gain (slow 2 "<1 1.5>") # (slow 2 (lpf "<1000 10000>"))
  d11 $ qtrigger $ filterWhen (>=0) $ ccv (slow 8 (segment 8 (range 10 127 saw))) # ccn 1 # s "midi"
  d12 $ qtrigger $ filterWhen (>=0) $ ccv "<1 2 4 8 12 18 23 100>" # ccn 2 # s "midi"
  d13 $ qtrigger $ filterWhen (>=0) $ ccv "<0.1 1>" # ccn 3 # s "midi"


hush

do
  d2 silence
  d3 silence
  d9 silence
  d8 silence
  d7
    $ qtrigger $ filterWhen (>=0) $ seqP [
    (1,25, every 2 (fast 2) $ s "bass3(5,8)" # note ("1..2") # room 0.3),
    (25,30, every 2 (fast 2) $ s "bass3(5,8)" # note ("1..2") # room 0.3 # gain (slow 12 (range 1 0.1 saw)))
    ]
  d6
    $ qtrigger $ filterWhen (>=0) $ seqP [
    (0,1, s "sharp:3" # gain 1.5 # room 1 # krush 5),
    (1,25, s "sharp:2*2" # speed "0.7" # gain (slow 25 (range 1.3 0.8 saw))),
    (1,17, slow 2 $ s "hardkick:5" # gain "<<2 1.3> 1.3 1.5 1.3>" # room 0.8 # lpf ("<10000 10000 800 10000>")),
    (1,20, s "909*4" # room 0.3 # gain 1.3),
    (1,25, s "hh*16" # gain (range 1 1.2 perlin)),
    (25,30, s "sharp:2*2" # speed "0.7" # gain (slow 8 (range 0.8 0 saw))),
    (31,33, s "<sharp:7 [~!3 sharp:9]>" # room "<1 1.5>" # gain "<1 1.2>")
    ] # room 0.5
  d4
    $ qtrigger $ filterWhen (>=0) $ seqP [
    (0,30, slow 2 $ chop "<32 16>" $ "ade:6"
    # speed ("<2 3>")
    # room 0.2 # gain (range 1 1.8 saw))
    ]
  d11 $ qtrigger $ filterWhen (>=0) $ seqP [
    (0,25, ccv (segment 16 (range 100 1 saw))),
    (25,30, slow 5 $ ccv (segment 5 (range 100 0 saw))),
    (30,33, ccv "0")
    ] # ccn 1 # s "midi"
  d12
    $ qtrigger $ filterWhen (>=0) $ seqP [
    (0,1, ccv "1 0!64"),
    (1,10, ccv "<1 4 10 20>"),
    (25,30, ccv "1"),
    (30,33, ccv "1")
    ] # room 0.5 # ccn 2 # s "midi"
  d14
    $ qtrigger $ filterWhen (>=0) $ seqP [
    (0,1, ccv "1"),
    (1,2, ccv "0"),
    (3,17, slow 2 $ ccv "1 0!12")
    -- (25,33, ccv "1")
    ] # ccn 4 # s "midi"

hush

My Hydra Code

hush()

// intro
shape(30,()=>cc[1]*1.3)
.scale(1,()=>window.innerHeight/window.innerWidth,1)
.colorama(1)
.scrollY(0.1,0.1)
.diff(src(o1).scale(0.9),0.5)
// comment out for the 4th part
// .luma(0.12)
// .repeat(()=>ccActual[2],()=>ccActual[2])
.out(o1)
render(o1)

// build up
src(o1)
.repeat(()=>ccActual[2],()=>ccActual[2])
.modulate(noise(()=>ccActual[2]/3,()=>cc[2]*5))
.colorama(()=>ccActual[3])
.invert(()=>ccActual[4])
.out(o2)
render(o2)

//drop
src(o1)
.repeat(()=>ccActual[2],()=>ccActual[2])
.modulate(noise(()=>ccActual[2]/3,()=>cc[2]*5))
.hue(()=>cc[1]*50)
.colorama(()=>ccActual[3])
.modulateScale(noise(3,()=>cc[1]))
.invert(()=>ccActual[4])
.out(o2)



// final
shape(4,100).out(o0)
render(o0)



hush()

Synesthesia allows artists to experience one sensory input while automatically perceiving it through multiple senses. While Ryoichi Kurokawa is not a clinical synesthete—nor am I—I find myself intrigued by how his artistic process unfolds. In true synesthesia, the brain acts as a bridge between senses, but Kurokawa seems to approach it differently. He envisions the brain not just as a connector but as a target, an audience, or even a collaborator. As he puts it, “I want to stimulate the brain with sound and video at the same time.”

Exploring his portfolio, I noticed a strong sense that his works are created using TouchDesigner (and turns out it’s not). As a new media student constantly exposed to different tools, my instinct was to research his technical choices. But then I came across his statement: “I don’t have nostalgia for old media like records or CDs, and I’m equally indifferent toward new technology.” This struck me. As an artist, he moves fluidly, guided not by tools but by his vision, much like the way he deconstructs nature’s inherent disorder only to reconstruct it in his own way. It’s not the medium that matters—it’s the transformation.

Watching Octfalls, I could already imagine the experience of standing within the installation, anticipating each moment, immersed in the sudden and precise synchronization of sound and visuals. As I explored more of his works, I noticed how they differ from what I have seen in many audiovisual performances, where sound usually takes precedence while visuals are more of a support role. In Kurokawa’s pieces, sound and visuals are equal partners, forming a unified whole. This made me reconsider my own approach—perhaps, instead of prioritizing one element over the other, a truly cooperative relationship between sound and visuals could be even more compelling.

Mercury is a beginner-friendly, minimalist, and highly readable language designed specifically for live-coding music performances. It was first developed in 2018 by Timo Hoogland, a faculty member at HKU University of the Arts Utrecht.

Mercury is structured similar to Javascript and ruby, being written highly abstracted. The audio engine and openGL visual engine is built based on Cycling ’74 Max 8, utilizing Max/MSP for real-time audio synthesis, while Jitter and Node4Max handle live visuals. Additionally, a web-based version of Mercury leverages WebAudio and Tone.js, making it more accessible.

How Mercury Work

The mercury language roots in Serialism, which is a musical composition style where all parameters such as pitch, rhythm and dynamics are expressed in a series of values (called list in Mercury), used to adjust the instruments stage over time.

In Mercury, the code is executed sequentially from top to bottom, and variables must be declared before being used in an instrument instantiation, if the instrument relies on them. The functionalities are divided into three categories. To define a list of values, the list command is used. To generate sound, an instrument—such as a sampler or synthesizer—can be instantiated using the new command.

Mercury in the Context of Live Coding

What makes Mercury outstanding is the following highlights:

  1. The minimal, readable and highly abstract language: It fosters greater clarity and transparency between performers and audiences. By breaking down barriers in live coding, it enhances the immediacy of artistic expression. True to its name, Mercury embodies fluidity and quick thinking, enabling artists to translate their mental processes into sound and visuals effortlessly.
  2. Code Length Limit and Creativity: In the early version of Mercury, there is a code length limit up to 30 lines for the performer, which encourage the innovation and constant dynamics by pushing the iteration of the existing code rather than writing another long list of code.

Demo

Below is the performance demo of me playing around in the Mercury Web Editor Playground:

Slides