The Huni Kuin videogame caught me off guard, mainly because I wasn’t expecting any content about videogames. Shanken almost slips it in — Amazonian shamanic knowledge, ancestral stories, now a game. At first, it feels like flattening, like something sacred turned into interface. But I’m not sure it’s that simple.

Gamification gets dismissed quickly, and often for good reason. But that’s not the whole picture. What we do in live coding is somehow similar — building systems and patterns hat unfold in real time, responsive, unstable, alive. A game works like that too. It’s not static or purely consumable; it shifts with the player. Each experience is slightly different.

So it’s not just representing a culture. It’s something you enter.

The key difference here is authorship. The Huni Kuin weren’t just depicted — they helped shape the system. That changes it. It becomes less extraction, more construction. Like what Pauline Oliveros describes: using technology to open perception rather than fix it in place.

Shanken’s concern about gamification as colonization is valid. But the issue isn’t the medium — it’s control. Who builds the system, who sets the rules, who decides what’s possible.

Added a Youtube video link to the game if anyone is interested

When we begin to think of the laptop as a musical instrument, similar to a guitar or piano, live coding takes on a more traditional musical meaning. In my own practice as a CS major, especially in this class, I often rely on pre-written scripts, making only small adjustments or sometimes simply running code and still considering it “live.” However, the paper challenges this assumption by emphasizing that liveness is not defined by the presence of a performer, but by real-time decision-making and compositional activity. This places practices like Deadmau5’s performance—where much is pre-structured—on a different end of the spectrum from live coding. Instead, live coding aligns more closely with improvisational traditions, such as those represented by Derek Bailey, where creation happens in the moment.
Now that we are required to do live coding sessions as a group, it pushes me away from heavy pre-planning and forces me to engage more directly with the code in real time with my group members. This shift makes the process feel much more aligned with the paper’s idea of liveness, allowing us to respond to each other and build something on the fly rather than relying on pre-written structures.

I wanted to do something with gifs using p5 – but decided to stick to the basics for now.

In this session, I tried with gifs. This was pretty cool but I don’t know how the gif ended up leaving marks over the canvas even though that wasn’t the case with my other gifs

Group Session

The first thing you notice is that the document itself doesn’t look like a normal academic paper. It’s filled with visual noise, fragmented text, and off-margin layouts that act like a glitch. This non-traditional format perfectly sets up her argument that we shouldn’t just ignore the “black box” of our computers and other interesting comments about glitch in the paper.

Menkman describes the glitch as an “exoskeleton of progress,” saying these technical interruptions are actually “wonderful” experiences. When a computer fails, we move from a “negative feeling” to an “intimate, personal experience” where the system finally shows its “inner workings and flaws”. Usually, we use technology so fast that it feels transparent, but a glitch breaks that flow and forces us to be “shocked, lost and in awe” of what the machine is actually doing.

One of the most interesting points she makes is that a glitch is “ephemeral”. The second you “name” a glitch or understand how it was created, its “momentum” is gone. It stops being a mysterious rupture and just becomes a new set of conditions or a “domesticated” tool. For Menkman, the real value of computer noise isn’t in fixing it, but in that brief moment of “devastation” where a “spark of creative energy” shows us that the machine can be something more than what it was programmed to be.