Pure Data (Pd) is an open-source visual programming environment primarily used for real-time audio synthesis, signal processing, and interactive media. Programs in Pd are built by connecting graphical objects (known as patches) that pass messages and audio signals between one another. Unlike text-based programming languages, Pd emphasizes signal flow and real-time interaction, allowing users to modify systems while they are running.
Pd belongs to the family of visual patching languages derived from Max, originally developed by Miller Puckette at IRCAM. While Max/MSP later became a commercial platform, Pure Data remained open source and community-driven. This has led to its widespread use in experimental music, academic research, DIY electronics, and new musical interface (NIME) projects.
One of Pd’s major strengths is its portability. It can run not only on personal computers, but also on embedded systems such as Raspberry Pi, and even on mobile devices through frameworks like libpd. This makes Pd especially attractive for artists and researchers interested in standalone instruments, installations and hardware-based performances.
Personal Reflection
I find Pure Data to be a really engaging platform. It feels similar to Max/MSP, which I have worked with before, but with a simpler, more playful interface. The ability to freely arrange objects and even draw directly on the canvas makes the patch feel less rigid and more sketch-like, almost like thinking through sound visually.
Another aspect I really appreciate is Pd’s compatibility with microcontrollers and embedded systems. Since it can be deployed on devices like Raspberry Pi (haven’t tried it out though), it allows sound systems to exist independently from a laptop. This makes Pd especially suitable for experimental instruments and NIME-style projects.
Demo Overview: What This Patch Does
For my demo, I built a generative audio system that combines rhythmic sequencing, pitch selection, envelope shaping, and filtering. The patch produces evolving tones that are structured but not entirely predictable, demonstrating how Pd supports algorithmic and real-time sound design.
1. Timing and Control Logic
The backbone of the patch is the metro object, which acts as a clock. I use tempo $1 permin to define the speed in beats per minute, allowing the patch to behave musically rather than in raw milliseconds.
Each metro tick increments a counter using a combination of f and + 1. The counter is wrapped using the % 4 object, creating a repeating four-step cycle. This cycle is then routed through select 0 1 2 3, which triggers different events depending on the current step.
This structure functions like a step sequencer, where each step can activate different pitches or behaviors. It demonstrates how Pd handles discrete musical logic using message-rate objects rather than traditional code.
2. Pitch Selection and Control
For pitch generation, I use MIDI note numbers that are converted into frequencies using mtof. Each step in the sequence corresponds to a different MIDI value, allowing the patch to cycle through a small pitch set.
By separating pitch logic from synthesis, the patch becomes modular: changing the melodic structure only requires adjusting the number boxes feeding into mtof, without touching the rest of the system. This reflects Pd’s strength in modular thinking, where musical structure emerges from the routing of simple components.
3. Sound Synthesis and Shaping
The core sound source is osc~, which generates a sine wave based on the frequency received from mtof. To avoid abrupt changes and clicks, pitch transitions are smoothed using line~, which interpolates values over time.
I further shape the sound using:
expr~ $v1 * -1 and cos~ to transform the waveform
lop~ 500 as a low-pass filter to soften high frequencies
vcf~ for resonant filtering driven by slowly changing control values
Amplitude is controlled using *~, allowing the signal to be shaped before being sent to dac~. This ensures the sound remains controlled and listenable, even as parameters change dynamically.
Randomness and Variation
To prevent the output from becoming too repetitive, I introduced controlled randomness using random. The random values are offset and scaled before being sent to the filter and envelope controls, creating subtle variations in timbre and movement over time.
This balance between structure (metro, counters, select) and unpredictability (random modulation) is central to generative music, and Pd makes this relationship very explicit through visual connections.
Conclusion
Overall, Pure Data feels less like a traditional programming environment and more like a living instrument, where composition, performance and system design happen simultaneously. This makes it especially relevant for experimental music, live performance and research-based creative practice.
(Somehow I can’t do recording with internal device audio… I’ll try recording it using my phone sometime)
Alda is a text-based, open-source programming language designed for musicians to compose music in a text editor without needing complex graphical user interface (GUI) software.
The Alda music programming language was created by Dave Yarwood in 2012. Interestingly, he was a classically trained musician long before he was a competent programmer
Why Alda?
In contrast to working with complex GUI applications available at the time, Dave Yarwood found that programming pieces of music in a text editor is a pleasantly distraction-free experience.
How it Works
The process is beautifully simple:
Write the notes in a text file using Alda’s syntax
Run the file through the Alda interpreter
Hear the music come to life
Key Features
Alda uses the General MIDI sound set — giving you access to over 100 instruments.
Basic Syntax
Pitch: The letter represents the pitch. c is C, d is D, e is E, and so on.
Duration: The number indicates how long it lasts in beats. In Alda, smaller numbers mean longer notes—it’s backwards from how we normally think!
Octave: The octave number tells Alda how high or low to play. c4 is middle C, c5 is one octave higher, c3 is one octave lower.
Handy Shortcuts
> moves you up one octave
< moves you down one octave
Chords and Rests
The forward slash / is your chord maker. It tells Alda to play notes at the exact same time.
Rests use r instead of a note name. The same duration rules apply.
Visual Aid
The vertical bar | does absolutely nothing to the sound. It’s just there to help you read the music more easily.
Alda represents a beautiful intersection between programming and musicianship—proof that sometimes the simplest tools can inspire the most creative work.
This project explores Glicol, a graph oriented live coding language that runs directly in the browser. Unlike traditional music software, Glicol allows users to build sound by connecting small units called nodes. Each node performs a simple function such as generating a wave, shaping volume, filtering sound, or adding effects. By chaining these nodes together, complex sound structures can be created in real time.
In my live demo, I demonstrated oscillators, sequencing patterns, envelope shaping, frequency modulation, filtering, and delay effects. I also showed how small code changes immediately affect the output, which makes Glicol powerful for experimentation and performance.
What makes Glicol interesting for interactive media is its accessibility. It requires no installation and combines code, sound, and creativity in a very direct way. This makes it suitable for beginners while still allowing advanced exploration.
Max, also known as Max/MSP/Jitter, is a visual programming language for music and multimedia developed and maintained by software company Cycling ’74. Over its more than thirty-year history, it has been used by composers, performers, software designers, researchers, and artists to create recordings, performances, and installations. It offers a realtime multimedia programming environment where you build programs by connecting objects into a running graph, so time, signal flow, and interaction are visible in the structure of the patch. Miller Puckette began work on Max in 1985 to provide composers with a graphical interface for creating interactive computer music. Cycling ’74’s first Max release, in 1997, was derived partly from Puckette’s work on Pure Data. Called Max/MSP (“Max Signal Processing” or the initials Miller Smith Puckette), it remains the most notable of Max’s many extensions and incarnations: it made Max capable of manipulating real-time digital audio signals without dedicated DSP hardware. This meant that composers could now create their own complex synthesizers and effects processors using only a general-purpose computer like the Macintosh.
The basic language of Max is that of a data-flow system: Max programs (named patches) are made by arranging and connecting building-blocks of objects within a patcher, or visual canvas. These objects act as self-contained programs (in reality, they are dynamically linked libraries), each of which may receive input (through one or more visual inlets), generate output (through visual outlets), or both. Objects pass messages from their outlets to the inlets of connected objects. Max is typically learned through acquiring a vocabulary of objects and how they function within a patcher; for example, the metroobject functions as a simple metronome, and the random object generates random integers. Most objects are non-graphical, consisting only of an object’s name and several arguments-attributes (in essence class properties) typed into an object box. Other objects are graphical, including sliders, number boxes, dials, table editors, pull-down menus, buttons, and other objects for running the program interactively. Max/MSP/Jitter comes with about 600 of these objects as the standard package; extensions to the program can be written by third-party developers as Max patchers (e.g. by encapsulating some of the functionality of a patcher into a sub-program that is itself a Max patch), or as objects written in C, C++, Java, or JavaScript.
Max is a live performance environment whose real power comes from combining fast timing, real time audio processing, and easy connections to the outside world like MIDI, OSC, sensors, and hardware. Max is modular, with many routines implemented as shared libraries, and it includes an API that lets third party developers create new capabilities as external objects and packages. That extensibility is exactly what produced a large community: people can invent tools, share them, and build and remix each other’s work, so the software keeps expanding beyond what the core program ships with. In practice, Max can function as an instrument, an effects processor, a controller brain, an installation engine, or a full audiovisual system, and it is often described as a common language for interactive music performance software.
Cycling ’74 formalized video as a core part of Max when they released Jitter alongside Max 4 in 2003, adding real time video, OpenGL based graphics, and matrix style processing so artists could treat images like signals and build custom audiovisual effects. Later, Max4Live pushed this ecosystem into a much larger music community by embedding Max/MSP directly inside Ableton Live Suite, so producers could design their own instruments and effects, automate and modulate parameters, and even integrate hardware control, all while working inside a mainstream performance and production workflow.
Max/MSP and Max/Jitter helped normalize the idea that you can build and modify a performance instrument while it is running, not just “play” a finished instrument. This is the ethos of live coding – to “show us your screens” and treat computers and programs as mutable instruments.
Live Coding + Cultural Context
With the increased integration of laptop computers into live music performance (in electronic music and elsewhere), Max/MSP and Max/Jitter received attention as a development environment available to those serious about laptop music/video performance. Max is now commonly used for real-time audio and video synthesis and processing, whether that means customizing MIDI controls, creating new synths or sampler devices (especially with Max4Live), or just creating entire generative performances within Max/MSP itself. Live reports and interviews repeatedly framed their shows and laptops running Max MSP, which helped cement the idea that algorithmic structure and realtime patch behavior can be the performance. In short, the laptop became a serious techno performance instrument. In order to document the evolution of Max/MSP/Jitter in popular culture, I compiled a series of notable live performances and projects where Max was a central part of the setup, inspiring their fans to use Max for their own music-making performances and practices. Max because a central programming language between artists who performed on the stage and in the basement, uniting an entire community around live computer music.
“This is a live recording, captured at Ego club in Duesseldorf, June 5 1999. The music has been created with a self written step sequencer, the PX-18, controlling a basic sample player and effects engine, all done in Max MSP, running on a Powerbook G3. The step sequencer had some unique features, e.g. the ability to switch patterns independently in each track, which later became an important part of a certain music software” from RobertHenke.com.
“Flint’s was premiered San Francisco Electronic Music Festival 2000. Created and performed on a Mac SE-30 using Max/MSP with samples prepped in Sound Designer II software. A somewhat different version of the piece appeared on the 2007 release Al-Noor on the Intone label” from “Unseen Worlds.”
He used Max to create live music from Nike shoes, and generally talked about how he likes using Max MSP and Jitter to map real time physical oscillations (like grooves and needles – or the bending of shoes) into live audiovisual outcomes.
MaxMSP allows for a collective performance format, such as laptop orchestras and networked ensembles. Princeton Laptop Orchestra lists MaxMSP among the core environments used to build the meta instruments played in ensemble, turning patching into a social musical practice, not just an individual studio practice.
By highlighting MaxMSP/Jitter’s centrality within a wider canon of musicians and subcultures, and linking examples of its development through time, I hope I have demonstrated how Max has contributed to community building around live computer music. Both MaxMSP and Live Coding express the same underlying artistic proposition that the program is the performance, but it lowers the barrier for people who think in systems and signal flow rather than syntax, and it scales all the way from DIY one person rigs to commercial mixed music productions to mass user communities.
My Experience
Computers are very intimidating animals to me. Because of this, I especially appreciated Max/MSP for a couple reasons: One, because it’s so prolific within the live coding/music community, like Arduino, there is an inexhaustible well of resources to draw from to get started. For every problem or idea you have, there is a Youtube tutorial or a reddit/Cycling ’74/Facebook forum to help you out. The extensive community support and engagement makes Max extremely accessible and approachable, and promotes outreach between both beginners and serious artists. Two, Max gives immediate feedback that easily hooks and engages you.
I liked using Jitter, because visuals are just so fun. This is max patch I made some time ago, where I would feel old camcorder videos into various filters and automatically get colorful, glitchy videos.
But for the purposes of this demonstration, I wanted to create a patch where visuals and sound were reacting to each other somehow. I searched up cool Max jitter patches and found a particle system box on Github, linked here: https://github.com/FedFod/Max-MSP-Jitter/blob/master/Particles_box.maxpat. Then, I searched up how I could make a basic sound that affects the size of particles, making them react to the noise realtime. I created the input object or sound (cycle), connected it to the volume (the wave cycles between those parameters, in this case -0.2 and +0.2) and the output object is the speaker, so we can hear it. In order to link this sound to the jitter patch, metro tells the transition objects to read the signal. I connected the sound signal to abs, snapshot and scale to remap it into measurements/numbers that can be read by “point-size” and visualized in jitter. Toggling the metro off stops “point size” from reading the measurements from the audio signal, severing the connection between the sound and the particles, as I demonstrate in my video. The result is, the louder the sound, the bigger the particles and vice versa. I liked using Max because it was extremely helpful to make the “physical” connections and see how an effect is created by visually seeing the signal flow, and more easily understanding how audio can be translated to visual signals in real time.
Mercury. A browser-based live coding environment created by Timo Hoogland. It is designed specifically to make algorithmic music performance human-readable and accessible to beginners. Unlike traditional programming languages that require complex syntax, Mercury uses a simplified, English-like structure (e.g., “new sample beat”), allowing the code to be understood by the audience as written.
Mercury operates as a high-level abstraction over the Web Audio API, running entirely in the browser without requiring external software or heavy audio engines. A key feature of the platform is its integrated audiovisual engine. It seamlessly connects audio generation with visual synthesis, often powered by Hydra, allowing performers to generate sound and 3D graphics simultaneously within a single interface. This design transforms the act of coding into a live, improvisational performance art, blurring the line between technical scripting and musical expression.
I chose Sardine because I am more comfortable with Python, and I thought it would be interesting to use it for live coding. Since it is relatively new and especially because it is an open-source project, it caught my attention. I like open-source projects because, as a developer, they allow us to build communities and collaborate on ideas. I also wanted to be part of that community while trying it out.
Sardine was created by Raphaël Maurice Forment, a musician and self-taught programmer based in Lyon and Paris. It was developed in 2022 (or around I am not too sure) for his PhD dissertation in musicology at the University of Saint-Étienne.
So, what can we create with Sardine? You can create music, beats, and almost anything related to sound and musical performance. By default, Sardine utilizes the SuperDirt audio engine. Sardine sends OSC messages to SuperDirt to trigger samples and synths, allowing for audio manipulation.
And Sardine works with Python 3.10 or above versions.
How does it work?
Sardine follows a Player and Sender structure.
Pa is a player and it acts on a pattern.
d() is the sender and provides the pattern.
* is the operator that assigns the pattern to the player.
Syntax Example:
Isn’t the syntax simple? I found it rather straightforward to work with. Especially after working with SuperDirt, it looks similar and even easier to understand.
There are two ways to generate patterns with Sardine:
Player a shorthand syntax built on top of it
@swim functions
Players can also generate complex patterns, but you quickly lose readability as things become more complicated.
The @swim decorator allows multiple senders, whereas Players can only play one pattern at a time.
My Experience with Sardine
What I enjoyed most about working with Sardine is how easy it is to set up and start creating. I did not need a separate text editor because I can directly interact with it from the terminal. There is also Sardine Web, where I can write and evaluate code easily.
Very well-written documentation, even though there are not many tutorials online
Easy to synchronize with visuals by installing Claude (Claude is another open-source tool for synchronizing visuals with audio in a live-coding context. It has a Sardine extension and allows you to control an OpenGL shader directly from Sardine.)
Gibber is a browser-based live coding environment developed by Charlie Roberts and JoAnn Kuchera-Morin, who worked together with their UCSB team to create an accessible platform for live music and audiovisual programming. The existing live coding tools create obstacles for most learners because of their need to be installed and the requirement to learn specialized programming languages and complete intricate setup procedures. Gibber addresses these challenges by running entirely in the web browser and using pure JavaScript, which enables users to start coding immediately without any installation requirements. The system provides users with brief development tools that create Web Audio API functions enabling them to build oscillators, FM synthesis, granular synthesis, audio effects and musical patterns through minimal coding efforts. The timing system of the system provides two types of timing functions, which enable users to schedule audio at sample level and use musical time values. The platform provides sample-accurate time functions together with Seq and Score tools, which enable users to create both freeform musical patterns and organized musical compositions. The platform combines visual rendering capabilities with real-time code collaboration, which enables performers to edit code together while the system uses CRDTs to ensure performance consistency throughout the collaboration.
Gibber’s design provides multiple benefits which transform it into an effective educational instrument and performance tool. The system allows users to create music through its simplified syntax which enables beginners to achieve musical results yet permits advanced users to conduct complex testing. The application runs in web browsers which provides all users access to its features which makes it suitable for use in educational settings and training programs and online group performances. The integrated graphics system of Gibber enables artists to create audio-responsive visual content which works together with interactive drawings and multimedia shows through a unified coding platform. The software provides users with pattern sequencers and modulation tools and synthesis options which enable them to create music across multiple styles that include rhythmic beat-making and experimental sound design. The collaborative features further distinguish Gibber which enables multiple performers to code together in real time while they share musical ideas through their common code instead of using audio stream synchronization. The software enables users to create music through its flexible design which serves as a learning platform for users to practice and create together with others in the field of electronic art.
