This is a second attempt at an abstract. Pastagang is an emergent jamming group that accidentally emerged in late 2024. In this paper, various participants and onlookers record and reflect on their experience of the phenomenon. In the spirit of the jam, no individual author is responsible for what you are about to read. Instead, it is the natural result of many people editing the same document with no oversight, plan, organisation or discussion. As you read through the following scattered contributions, you may notice glimpses of / fragments of / I dunno… (pls help)
pastagang is a phenomenon where various live coders use a single collaborative environment as their live coding tool of choice.
whether they’re practising at home, performing at an algorave, facilitating a workshop, or jamming at a meetup, a live coder might decide to do it in a shared space.
I heard about pastagang for the first time after clicking on a Strudel URL shared on the Fediverse. This opened a web page containing a bit of source code and a play button to render the audio directly in my browser. I was vaguely familiar with Tidalcycles, but I had never used it since I was not particularly enjoying it on my own.
Even though I could make my own variations, and reading the Strudel’s documentation helped me understand a bit what was going on, I still couldn’t do much with it. This quickly changed after visiting another link shared by a pastagang member: a URL for an interface called Flok. Like Strudel, it is a web page that contains a text editor, but it is multiplayer with the other participants’ cursors moving in real time.
Seeing the code being developed collaboratively was a transformative experience. Soon, I felt like I could add my own patterns, and with the help of the pastagang, I quickly learned how to make it sound the way I liked. Suffice it to say I was hooked, and out of nowhere, I spent a few hours here and there reading and writing live code with the pastagang.
All of that to say that I came for the sound, and I stayed for the experience. Pastagang is powered by the most user-friendly system I can think of; you just need a web browser and some free time.
As someone who is new to the whole live coding performance thing, it is very intimidating to see with how much finess and focus people can perform in these live events. Because of the sharing nature of the online jam, not only can you look over the shoulder of someone else doing it but you also get access to the code in real time, seeing how they change it and what effects it has. You can copy out code, and understand how it works. Try out some changes and bring them back into the jam. This allowed me to get the confidence needed to just jam with the others.
Yes, when I switched from strudel to flok, I thought I would learn slower because I wouldn’t have the inline docs or autocomplete. But the surprising thing for me was how my learning rapidly sped up, just by looking and seeing other people code.
I remember thinking things like “ply
? what does that do?” and then I fiddle with the number, explore it, and try it out myself.
My discovery of different language features was greatly improved by being around other people (in a virtual space). Not just discovery of the existence of these features, but also their varying uses / the moments they can good in.
When you only see cursors jumping on the screen it can seem like they know exactly what they are doing. It takes courage to jump in and change a number. Learning that this is ok, and actually encouraged, is a process. But because you see it happen, it makes doing it a bit easier every time.
The natural highs and lows of activity in the shared room create opportunity for people, to be inspired by others jamming, as well as try out their feet, when no one else (or less cursors) are around. The transition from “real performance” and just goofying around for oneself gets blurry, and before you know it, you lose an hour to a jam with a bun ch of people.
As someone who has trouble visualizing most writen or spoken pictures (aphantasia [citation needed], a bit, not diagnosed and sometimes I can.), coding visuals gave me a new avenue to access artistic expressions that with traditional tools are always hard ta archive.
Being able to understand how code interacts and quickly toy around with it, makes giving life to the abstract ideas in my head somewhat easier. Because the abstraction in hydra is very similar to what my brain does itself.
Pastagang has been one of the most … of my life. …
For me, jamming means high levels of trust, listening and making space for others. I hope to take these skills into other areas of my life…
The thing that I’ve noticed happens a lot in the collaborative space vs the solo space, and it’s sparks of unexpected inspiration. You kind of know, more or less, what’s coming when you’re livecoding solo. But the moment you get a group dynamic you tend to react to the unexpected coming at you - it’s generally a fairly slow burn because you get the new sound, it sparks the inspiration, the inspiration gets turned into code and then you add your piece (and usually tweak it)… then you try to enjoy it for a while.
These sparks of inspiration can lead to learning how to use new functions, or old functions in new ways, or discover new samples, interesting patterns etc
When I’m among familiar players, I like providing that unexpected dynamic on occasion just to see what reactions/changes that causes, and where that can lead to
Sometimes, I run out of ideas/inspiration and don’t know what to do with my code. My go to in this scenario is to remove my code altogether and make space (on the screen, and in the density of audio) for someone else to do something (which can reignite the spark in me again). When I’m solo I need to try and keep a constant stream of new ideas going which I often find difficult.
With certain people I very much feel that sense of inspiration far more strongly, it reminds me of the concept of a muse but it’s usually a two-way muse relationship, ie inspiring for both players.
I suspect this is all old news to most accomplished musicians, particularly jazz/improvisational based players - I wonder, does this serve to help validate livecoding as an instrument? Does it even need validation?
My perspective on jam-oriented programming is shaped by an acute sense of my own lack of formal background in music or programming. Partially because of this, I have mostly pursued these activities non-collaboratively. When I was younger, I did find myself attending conventional jam sessions on two occasions. Everyone brought their specialist instrument but I had never learned how to play one and felt completely blocked both times. There was also a kind of secret jam language that was incomprehensible to me. The guitarist nodded at the drummer and the sound changed. A vocalist shouted “G”, glanced, and said “just like last time…”. I didn’t really know how to participate, so I didn’t. As the years went by I experimented more with music (and coding) but always as solo endeavours. I have never felt sufficiently prepared for collaboration in either domain, especially in a live context.
In Flok, the nods and glances were largely textual and readable. There was time to acknowledge and interpret them without needing to immediately act. I could make an adjustment to a sound, then sit back and reflect on its effect before acting again. I had access to a bank of samples and instruments, so I could find something that felt right for the moment and swap it out at will. There were certainly people who knew the environment better, but it never felt like a group of specialists with secret knowledge.
In my first jam, I was admittedly hesitant. I avoided contributing any melodies or rhythms, instead opting for barely-audible textures. After a while, I thought the textures sounded good, so I increased the gain and added more variation. Then I got really confident and added a guitar sound. “Oh no!” — it sound terrible! Immediately, some friendly cursors floated over to my pane and helped me make it better. Someone can hand me an instrument, shout “G” and I will freeze. In Flok, someone said “E Dorian”, I could see where it should be typed and then I could listen passively to the results of their wise suggestion.
Since then I contributed drums to another jam. There was one moment where I felt like some changes that I was making caused a shift in the sounds that someone else was making. I had never had that experience before when making music!
talk about nudel and how contributions are approached like a jam as well. everybody can become “maintainer” immediately, being able to change the site without asking. in a jam, communication and decision making happens mostly through the music, less through talking about it. talking is a detour. trust the process. the jam is a SUBSTRATE. similarly, in JOP, people don’t need to ask before making a change (they still can if they want to have feedback etc). the software is not part of a critical infrastructure, so breaking it has no severe consequences. similar to how it happens that someone makes a mistake in a jam, it can happen that the thing breaks. it’s fine. we even have a backup plan (flok.cc). focusing on a low barrier to entry also means the code should be as easy to understand as possible, so avoiding too many complexities is a good idea. perfection is not the goal. it’s better to make a bad contribution than to make no contribution at all.
Before contributing to nudel, I had minimal understanding of open source collaboration. Despite coding extensively in my free time, I never felt comfortable contributing to other’s repositories, fearing that my work might not be up to the repository maintainers’ standards. However, nudel’s community and collaboration practices completely changed that perspective. It fosters a very welcoming environment where even small contributions and changes are encouraged and valued. Whether the code is optimized or well-structured is secondary. What matters is pushing something functional and receiving constructive and actionable feedback. Watching my changes go live on the website gave me a lot of confidence and created a desire to improve and learn new things.
Nudel’s low barrier to entry and Jam-like approach allows everyone to be a “maintainer” immediately, encouraging contribution without the fear of failure. Breaking something isn’t catastrophic but rather a part of the process, with backups in place to mitigate issues. This freedom creates space for direct learning from more experienced contributors, while being part of a diverse, supportive community that shares the same goals. With an easy-to-understand codebase, starting a new contribution is seamless. It’s this mix of collaboration, creativity, and trust that makes contributing deeply rewarding.
I love performing to an audience. I find it very exhilarating. But it can sometimes feel self-indulgent. With jamming, this isn’t a problem. It’s more collaborative or something blah blah blah…
Link to that audiences paper1
Everything we make gets attributed to “pastagang” rather than any individual(s).
This is partly due to convenience. for any one piece of music or visual, there may have been countless contributors, some anonymous, over a long scattered period. hunting them all down would be a nightmare.
and even if you do hunt down everyone who wrote those individual lines of code, what about those who came before?
those lines of code didn’t come out of nowhere: they grew from what was there previously.
the jam is continuous. it has no start and end. so every product of the pastagang is a product of everyone who has ever set foot inside it.
even a motionless cursor can influence the sounds and sights it makes. your presence or lack of presence steers the jam.
For some people, it may seem like a shame to not get individually credited. but in many ways, it is liberating.
if something sounds bad, it’s not your fault. it’s pastagang’s fault. so your reputation isn’t on the line. in this way, the jam serves as a tool that removes emotional blockers, in the same way that my arroost tool aimed to be2.
Pastagang’s approach to responsibility differs to the typical mindset of algorave. Here’s a quote from the algorave website:
Algorave musicians don’t pretend their software is being creative, they take responsibility for the music they make, shaping it using whatever means they have.
In algorave, musicians take responsibility, but in pastagang, musicians relinquish responsibility — the jam claims your outputs as its own.
todo
todo
todo
Analogous to the pulsing live body within other forms of performance, the flashing cursor marks the point of decision-making – of consciousness perhaps – within the live programming of code; the movement of the coder’s thinking as its oscillates between sense-making through the discontinuous, abstract notational form of code and the ‘continuous’ – even sensuous – experience of coding as a lived experience. 3
(Thoughts about the experience of being cursors on a screen go here)
During the jamming sessions, seeing multiple cursors move across the screen making art creates a unique form of unspoken collaboration. Each cursor’s movement represents someone’s creativity and intentions, making you part of a larger collective experience. While working in Hydra, watching more experienced coders take your initial concepts in a new direction creates a feeling that solo coding cannot match. The nature of adapting your plans to work with others’ contributions mirrors the dynamics of an in-person jamming session. Without communicating, these cursors interact with one another and enable a constantly flowing exchange of ideas, leading to unexpected creative directions and fostering a sense of collective creation.
(Insert screenshots of cursors doing things in cursorland, etc)
McLean, A., Rohrhuber, J., & Wieser, R. (2023). The Meaning of Live: From Art Without Audience to Programs Without Users. International Conference on Live Coding (ICLC2023), Utrecht, Netherlands. https://doi.org/10.5281/zenodo.7843567 ↩
Wilson, L. (2024). Arroost: Unblocking creation with friends. https://todepond.com/report/arroost ↩
Cocker, E. (2016). Performing thinking in action: the meletē of live coding. International Journal of Performance Arts and Digital Media, 12(2), 102–116. https://doi.org/10.1080/14794713.2016.1227597 ↩