Category: Spring 26

I researched P5LIVE, a collaborative live coding platform for p5.js that runs in the browser. Live coding is an art practice where the process is the performance. You write and change code in real time, and the visuals update immediately, often with the code visible too. P5LIVE was created by Ted Davis, a media artist and educator in Basel, originally for a Processing Community Day event where people wanted to live code visuals during a DJ party.

What I like about P5LIVE is that it treats live coding as a social activity. It lowers friction by running in the browser, and it makes collaboration feel natural through links and shared rooms. It is not just an editor. It is a space where teaching, performance, and experimentation overlap. Instead of coding being private and finished, P5LIVE encourages coding as something collective and ongoing.

P5LIVE’s key feature is COCODING, which works like Google Docs for code. You create a room link, others join, and everyone edits the same sketch together in real time while the visuals run locally for each person. It also includes classroom and performance features like lockdown mode, chat, and SyncData, which lets people share live inputs like MIDI or mouse data with the group. In my demo, I will show the instant feedback loop and a basic COCODING session.

Overview

Punctual is a live coding platform that runs in your browser and handles both audio and visuals. The creator says it was inspired by a way of using SuperCollider called JITLib, but uses a newer and more economical notation. Because it is browser-based, you do not need to install anything, which makes it much more accessible to start experimenting and learning. David Ogborn, the creator, also provides tutorials and guides on YouTube, which make it easier to understand and explore the platform.

Wider Context

Punctual is really accessible because it runs straight in a web browser, so you don’t have to deal with complicated setups like installing SuperCollider or Hydra. The documentation is actually a great starting point; you can take the example code, run it, and see how every parameter affects both the sound and the visuals. This makes it easier to understand what each function does before you start making your own pieces. That’s important because tools that require lots of setup can feel intimidating, but with Punctual, the barrier is lower, which makes live coding feel more approachable and encourages experimentation.

How it Works (+ My Observations)

One thing to note is that there’s no scrolling feature; you have to move the cursor with the arrow keys if your code gets long. Unlike Hydra, where Shift+Enter runs just the current line, in Punctual, Shift+Enter seems to reevaluate all the code in the editor, which is convenient but can feel a bit limiting for live coding because you can’t isolate just one line. Still, the documentation and tutorials are super helpful, you can paste a line, run it, then add another line and run again, and you get a sense of how each parameter affects the audio and visuals as the code is reprocessed.

My Code

osc 440 * lftri 3 * 0.7 >>audio;
[unipolar (1 - sqrt(fx*fx + fy*fy)/0.5) * 0.7, 0, 0]>> add;

saw 33 * 0.25 >> audio;
[unipolar (0.05 / (sqrt(fx*fx + fy*fy) + 0.01)), 0, 0] >>add;

osc [220, 261, 311] * 1.1 >>audio;
[unipolar (lftri 5 * (sin(fx*10)sin(fy*10))), 0, 0] >> add;

osc [330, 440, 523] * lftri 5 * 0.6 >>audio;
[unipolar (lftri 5 * fx * 5), 0, unipolar (lftri 5 * fy * 5)] >> add;

lpf 120 1 (saw 55) * lftri 0.15 >>audio;
[unipolar (0.5 - abs(sqrt(fx*fx + fy*fy) - 0.3)), 0, 0]>> add;

osc [196, 220, 233] * 1.05 >>audio;
[unipolar (lftri 4 * lftri 3 * 0.35), 0, 0]>> add;

osc 110 * lftri 1.5 * 0.5 >>audio;
[unipolar (lftri 1.5 * 0.5), 0, unipolar (lftri 0.7 * 0.3)] >>add;

osc 87 * 0.3 >> audio;
[unipolar (0.6 - sqrt(fx*fx + fy*fy)), 0, 0]>>add;

Video Demo:

https://drive.google.com/file/d/1RrrvHwDGgeVrWRvA2tjVaBR-KlmWS0Cg/view?usp=drive_link

Sonic Pi was created by Sam Aaron, a programmer and live coding artist that developed it as his post-doc research at the University of Cambridge. He created the platform in hopes of making programming more accessible to children. It was developed in junction with the Raspberry Pi Foundation, as a easy to run program that could run on weaker computers, such as the Raspberry Pi.

It began as just an educational tool but evolved into a platform that is utilized both for learning, and for performing. This design is one of the things that I thought was different about Sonic Pi, it was developed for a range of users, meaning its features must be simple enough for children to operate, but also technical enough for live coding artists.

The program is easy to run, as the only software needed to download is the Sonic Pi software itself. The above mentioned philosophy for its feature set is also why there are built in tutorials within the software.

The Program runs similarly to how Tidal-Cycles does, where you type code and evaluate it. However, one core difference between Sonic Pi and Tidal-Cycles, is, instead of evaluating line by line, each time you run the code, you run the whole code on the current document. Similarly to Tidal-Cycles though, it doesn’t generate any sound itself, but it utilizes SuperCollider for sound generation, albeit, having it built into the program when you download it.

Strudel represents a significant evolution in accessible music live coding, porting the sophisticated pattern language of TidalCycles from Haskell to JavaScript for entirely browser-based performance.

Origins and Development

The project emerged in early 2022 when Alex McLean (creator of TidalCycles) began porting Tidal’s pattern representation to JavaScript. Developer Felix Roos discovered this early work and built a complete browser system around it. After intensive collaborative development, Strudel was formally presented at the 2023 International Conference on Live Coding in Utrecht, establishing it within the “Uzulangs” family of Tidal-inspired environments.

Key Differences from TidalCycles

While Strudel faithfully preserves Tidal’s cyclic time model and pattern operations, several distinctions matter:

No installation required. Unlike TidalCycles, which demands Haskell, SuperCollider, and SuperDirt setup, Strudel runs immediately in any modern browser. This dramatically lowers the entry barrier for newcomers and educational contexts.

JavaScript, not Haskell. The syntax feels familiar to web developers, though the underlying pattern concepts remain consistent with Tidal’s approach.

Flexible output routing. Strudel includes WebAudio synthesis directly, but can also drive MIDI hardware, send OSC to SuperCollider/SuperDirt, connect via WebSerial, or route to CSound, making it adaptable to various workflows.

How It Works

Strudel’s REPL transpiles code into Pattern objects using Acorn and Escodegen parsers. A scheduler queries these patterns at regular intervals, generating musical events (called “Haps”) while maintaining Tidal’s characteristic approach: events compress into fixed cycle lengths, enabling dense polymetric structures without tempo changes.

The result is a practical tool for algorave performance, classroom teaching, and studio sequencing that preserves TidalCycles’ creative philosophy while embracing web accessibility.

Explore at strudel.cc.

_{Short Demo}

I overall appreciated how the reading emphasized music’s inextricability from the body. Because we grew up ensconced in Western philosophies (pointing fingers at you Plato & Descartes & Kant), I believe we, albeit subconsciously, mistakenly divide the mind and the body. The lofty Mozart-esque realm of music seems more associated with “the mind” while dance belongs to the realm of the body, but if we look within, I believe we all intuitively understand that the gap was never there. But the historical assumption of that gap is why this reading exists in the first place, which it outright acknowledges: “I am arguing that a significant component of such a process occurs along a musical dimension that is non-notatable in Western terms – namely, what I have been calling microtiming.” That’s why I had to laugh when I read: “Though these arguments are quite speculative, it is plausible that there is an important relationship between the backbeat and the body, informed by the African-American cultural model of the ring shout.” Modern academia – always the cautious skeptic, for better and worse. Also always the exclusionary imperialist. Like, oh you finally caught up! (Not speaking to the reader, just speaking in general.) The idea of the drum set as an extension of the body makes complete sense. The bass drum at the feet, stable and steady. The snare at the hands, which, with their greater dexterity, can more readily linger or attack, flavoring the music, giving it “that feel.” Literally our feel.

There were some phrases I really liked that particularly spoke to this: “It is a miniscule adjustment at the level of the tactus, rather than the substantial fractional shift of rhythmic subdivisions in swing.” I also loved this quote: “It seems plausible that the optimum snare-drum offset that we call the “pocket” is that precise rhythmic position that maximizes the accentual effect of a delay without upsetting the ongoing sense of pulse. This involves the balance of two opposing forces: the force of regularity that resists delay, and the backbeat accentuation that demands delay.” I also love how everything “seems plausible” hahaha. I also really loved this phrase: “bears the micro-rhythmic traces of embodiment…”

I was thinking of a couple things. One, what is the source of the pulse? Our breathing, our heartbeat, walking, running, how rocks feel on a hot day. Two, the main point of the reading, how to reconcile computers with the music of our bodies. The reading goes into several methods people have used to do this, the best of which, to me, was when it went over how DJs sampled songs by scratching records, and how the music is the material manifestation of the movements of the hands themselves. See here: “…bears a direct sonic resemblance to the physical motion involved” and “causing it to refer instead to the physical materiality of the vinyl-record medium, and more importantly to the embodiment, dexterity and skill of its manipulator.” These are just really great observations.

So when it comes to computers? Where to start? I had a conversation with dad I still remember a year ago. He said our phones are stupidly made because they’re made for our eyes, to please the Kantian aesthetes in us hahah. If they were really made for our hands, they would be designed like small conch shells. Look at the antiquated wall phone, how slenderly it wrapped itself inside your palm. I’m trying to say that the devices we use today were not built for us. (The divorce we made between the body and the mind is hurting us.) The computer is inherently disembodied, and we all know this. This is why I really like hyper pop, because its very sound contains the shifting disembodiment of a generation, yet, our inviolable presence throughout. It is us dancing through the divorce hahah. None of this is bad, it all just tells the story. So yeah, I’ll employ the tips and tricks the reading offered. Mostly, I will focus on the computer’s liaison with my hands.

Hey There!!

I’ll be working with traditional Indian tabla drum sounds but treating them in completely new ways through code.