Written by Amy B. Woodman; Edited by Patt Vira and Xin Xin

Fellowship Project: Call / Code / Response

• Artists: Ana C., Jiwon Ham, & Payton Croskey
• Links: collage tool, student collage repo, performance repo

“The most radical thing about this project,” Processing Foundation Co-Executive Director Xin Xin says, “is that we are letting young people lead with their vision, and every adult involved is following their cues.” This approach is captured in the defining philosophy of the collaboration as Processing Foundation Fellow Jiwon Ham reflects, the project was ultimately about “different disciplines, one purpose: amplifying a story led by youth.”

LIVE FROM LA is a youth-led production that emerged from the Hip Hop Theatre Program founded by Street Poets, Inc., who also served as the play’s lead producer. The production was created by Street Poets, Inc., Unusual Suspects Theatre Company, and the Processing Foundation, with Versa-Style Street Dance Company and No Easy Props joining as creative partners. Together, each organization contributed skill-building workshops across disciplines including theatre, dance, poetry, music, and creative technology. At the heart of the collaboration were 12 committed young people, ages 13–19, who wrote and performed a play drawn from their own lived experiences.

This project stemmed from the 2025 Processing Foundation Fellowship, an exploratory cohort model in which Fellows were paired directly with a community partner to co-develop software tailored to that partner’s specific needs. The creative technologists awarded this Fellowship were Ana C., Jiwon Ham, and Payton Croskey, who built the technical and artistic architecture for the coded projections that displayed across the stage during the performance.

For Jiwon, whose practice evolved from presenting motion graphics on public LED screens in Seoul to building immersive, interactive systems, LIVE

FROM LA was an opportunity to root her work in the city she now calls home. Jiwon often begins her projects through conversations and memory-gathering. “I’m consistently drawn to how people form emotional relationships with place,” Jiwon explains. In this production, that approach translated into a projection system built to help students curate and layer meaningful images about their own histories, families, and beliefs.

“I felt very connected to this story,” Ana reflects. “My life and the story have been intertwined throughout this process.” Ana came to creative technology through illustration. Raised in a family of artists and engineers, she grew up finding the connections between analog and digital art making. Over time, her practice moved beyond aesthetics and into research-driven work that focuses on the interplay of technology and identity. Inspired by artists like Doris Salcedo, whose public interventions engage memory and political history, Ana began exploring augmented reality and creative coding as ways to enter into dialogue with place. In LIVE FROM LA, that sensibility shaped her approach to using coding as a medium for empowerment, helping students see technology as something they could use to author and amplify their stories.

Payton approaches creative technology as both a designer and a theorist. Her early experiments revealed how computation could make objects feel alive, raising questions about futurity, artificiality, and power. Now a PhD researcher at UC Santa Barbara’s Expressive Computation Lab, her work inspects the crossroads of AI, AR, and Afrofuturism, where she develops community-centered methods for ethically modeling and preserving Black cultural data. “Meaningful innovation happens when process matters as much as product,” says Payton. In LIVE FROM LA, Payton brought a liberatory design framework into the theatre space, prioritizing accessibility, dialogue, and shared ownership so that the students’ stories were protected and shaped on their own terms.

The team analyzed the student-written script scene-by-scene to determine where projections could best serve the story without disrupting the emotional flow. They chose a collage-style aesthetic to mirror the “raw energy” of youth protest. To make the vision a reality, the fellows co-created a custom digital collage-making tool using p5.js, TypeScript, and React.

The technical labor was shared with intentionality. Ana built the software and the control interface, ensuring the code was clean and triggerable in real-time. Jiwon managed the hardware and used 3D scanning and Blender to simulate how projections would interact with the building facades of the outdoor Hollywood studio lot. And Payton focused on the cultural narratives and developed the lesson plans to introduce students to creative coding.

The project’s philosophy was rooted in call-and-response as a constant dialogue between the technologists and the performers. One of the most powerful connections was formed with a student named Jorge, who played a “nerdy tech guy,” as he puts it. Though Jorge had never coded before, the team designed a custom curriculum for him. Ana recalls the beauty of teaching him in her native language: “I would just put [the variables] in Spanish because that way it’s clear what the variables are … I really admired the voice that they had and all the agency they saw [with making their protest collages].”

The students’ input directly shaped the visuals. When an actor named Natalia performed a poem about resilience, the team created an animation of flowers “blooming” from the crevices of the buildings. Another student actor playing Luna was moved to tears seeing the faces of her own family and friends projected behind her while she spoke. Ana describes the atmosphere as one of “mutual admiration,” where the fellows often found themselves speechless by the wisdom and courage of the youth.

The collaboration culminated in a climactic scene where the students staged on the Radford Studio backlot in front of more than 200 audience members. The students performed across a set of building facades transformed by immersive projections generated from their own digital collages. While students performed their spoken-word poetry, the Fellows carefully cued and orchestrated the dynamic projections onto the buildings. As the story reached its peak, the actors staged a protest against city plans to gentrify their neighborhood. Sirens pierced the air. The crowd fled. The stage emptied.

But the projections did not disappear. The students’ collages remained lit, flickering defiantly across the facades long after the performers had exited. In that charged silence, the images of resistance and hope held their ground, a reminder that we’re still here.

The Processing Foundation Fellowship supports artists and creative technologists developing open-source creative tools and practices that expand access to creative technology. Through financial support, mentorship, and community partnerships, fellows create tools, artistic works, and research that contribute to a more open and accessible creative coding ecosystem.

• Learn more about the Fellowship → here
• Support programs like this → here

Written by Amy B. Woodman; Edited by Patt Vira and Xin Xin

Fellowship Project: The Future Protest

• Artists: Maryam Kazeem and Jubril Olambiwonnu
• Links: Project Website

“I’m really interested in prompting the public as a way of making meaning,” Maryam Kazeem says, reflecting on the shift from working with small artistic cohorts to creating a project that is open to “anyone and anybody participating.” She views these collective gestures of recordings as a “dream space” where the act of protest functions as a generative “glitch” that creates an opening in the world as we know it.

In their shared narrative, participants offered a startlingly intimate inventory for their imagined futures: they brought musical instruments, love, sandwiches, their kids, and “the end of war and violence.” They envisioned marching alongside ancestors and the next generation, declaring that the protest would only be over “when the seeds bloom and we are free from pain.” For Maryam and Jubril Olambiwonnu, the technical lead on the project, these contributions represent a form of radical publishing where archival words finally touch the water, transforming a digital exercise into a living site of collective research.

The concept of The Future Protest emerged from a central, unsettling question: how can a body of water that has been systematically erased, sand-filled, and polluted become a site for speculative recovery? The project, a collaboration between Maryam, a writer and researcher based in Lagos, and Jubril, a software engineer and creative coder in London, responds to the ongoing ecological and socio-political displacement along the Lagos Lagoon, Nigeria. Their vision was not to merely document loss, but to create a sonic archive; a digital and eventually physical space where the act of imagining a protest creates a “glitch” in the dominant narrative of urban degradation.

In interpreting this year’s Processing Foundation Fellowship theme “Data Storytelling,” the project explores the friction between data, often seen as a rigid tool of state surveillance or outsider documentation, and storytelling, which in the context of Lagos is expansive, messy, and deeply relational. The Future Protest seeks to hold these together, treating the sound of a voice as a living energy capable of doing something in the water.

The history of the Lagoon is one of forced transformation. Before British colonization, the area was a lush network of wetlands and mangrove forests that protected the land and provided a sanctuary for both wildlife and human communities. Under the guise of malaria mitigation, the colonial administration initiated a campaign of land reclamation, eradicating the mangroves and fundamentally altering the city’s relationship with its water. Today, that legacy persists in the form of untreated industrial waste and the displacement of waterfront communities.

This reckoning takes a startlingly literal form in the project’s technology. When a participant records a “future protest,” a poethic algorithm developed by Jubril analyzes the recording. Crucially, the algorithm does not only listen to the words, but also the pauses and gaps where the speaker catches their breath or searches for a thought. These moments of silence generate 3D animations of speculative mangrove trees. However, these are not the lush green trees of the pre-colonial era; they are constructed from digital renderings of the plastic bottles and trash that currently choke the Lagoon.

“I got so excited when we first came up with this idea of thinking about silence as data,” Maryam recalls. “To take someone speaking and, from a poetic point of view, derive meaning from when they are not speaking felt incredibly impactful.” For Maryam, a writer who describes herself as formerly “technology-averse,” the fellowship transformed her understanding of data from something clinical into something poetic.

The project’s ethos mirrors the distinct talents of its creators. Jubril brought the technical rigor of a software engineer to a creative experiment, while Maryam provided the conceptual framework of speculative research and radical publishing. This April, Maryam will launch “The Library on the Lagoon”, an immersive installation where passenger responses are transcribed by a typewriter that powers a trash collection wheel in the water.

Through the medium of speculative sonics, The Future Protest suggests that the simple act of saying “no” to the current state of the world can create a pathway for navigating the future. It treats the Lagoon as a site where words can touch the water and do something in the water, turning the act of archival documentation into a living exercise in discovering alternative futures. It is an invitation to look at the waste, the silence, and the water, and see a space where the “glitch” of protest might finally let the ecosystem hear itself again.

The Processing Foundation Fellowship supports artists and creative technologists developing open-source creative tools and practices that expand access to creative technology. Through financial support, mentorship, and community partnerships, fellows create tools, artistic works, and research that contribute to a more open and accessible creative coding ecosystem.

• Learn more about the Fellowship → here
• Support programs like this → here

Written by Amy B. Woodman; Edited by Patt Vira and Xin Xin

Fellowship Project: p5.score

• Artists: Kate Sicchio
• Links: Project website

“I’m interested in this idea of a set of instructions, guidelines, or tasks for a starting point for improv or for generating movement,” says Kate Sicchio, the media artist and choreographer behind p5.score. “It’s about how the score can become this contract or negotiation point between movement, a performer, and a creator.” Developed during her 2025 Processing Foundation Fellowship, p5.score is a JavaScript library that harmonizes the physical world of dance with the digital logic of p5.js. By translating creative technology into a choreographic language, Kate has built a framework where visual patterns on a screen serve as a catalyst for physical improvisation, positioning the code as a new partner on the stage.

The core mission of p5.score is to provide choreographers an entryway into creative coding. For many dancers, traditional programming can feel like a technical hurdle; Kate bridges this gap by integrating terminology from both dance and computing. Kate states that “simple things lead to complex things” when using p5.score, and the library’s API is intentionally paired down to remain accessible while also allowing for sophisticated structures as the dance evolves. The project draws inspiration from historical scores by choreographers like Trisha Brown who used systems and annotations rather than rigid notation to indicate movement.

The library’s “magic sauce” is the `Dancer class`, which represents a performer within the digital score. To bring the dancer to life, users employ a specific constructor that defines the performer’s initial state:

• new Dancer(x, y, durations, positions, color, shape): This allows the creator to set the starting coordinates, a list of positions for the dancer to loop through, and the duration (in milliseconds) for each moment.
• Movement Qualities: By changing the shape (radius size) or color, choreographers can represent different movement dynamics or qualities, such as a large shape indicating a lumbering flow or a small dot representing fast, sharp movements.

The movement is then animated using two primary methods: moves(), which initializes the timed sequence, and show(), which renders the dancer on the canvas with the draw() loop familiar in p5.js. One of the most impactful features is the Stage Direction functions. In response to community feedback that raw X and Y coordinates were “tricky,” Kate programmed familiar terms like center() (Center Stage), ul() (Upstage Left), and dr() (Downstage Right) to return coordinate objects, allowing artists to plot space using the language of the theatre.

Underpinning the project is an open-source ethos rooted in Kate’s background in live coding. She views p5.score not as a static product, but as a tool for the community to “take, adapt, and change.” For Kate, this is a matter of empowerment: “Having agency when you move, having agency when you code.”

To ground the library in practice, Kate hosted a two-day workshop in Richmond, Virginia, with ten choreographers and creative coders. The process followed a call-and-response between analog and digital mediums. Participants began by drawing scores by hand and using paper and markers, a familiar starting point that allowed them to realize that p5.js fundamentals like strokes, weights, and coordinates were simply digital extensions of drawing.

As they transitioned to the screen, participants realized that “when you code, it’s like choreography,” as you are telling an element what to do and how to do it. The workshop atmosphere was one of mutual exploration, where users experimented with adding images and theatrical scenery, transforming the scores into immersive backdrops.

The collaboration culminated with live dancers performing the generated scores. Two improvisers interpreted the digital patterns, which ranged from intimate floor projections that dancers followed closely to large-scale theatrical visuals. For Kate, witnessing the interpretation was a “sigh of relief,” proving that the tool could generate “beautiful movement” and that the dance community saw it as an innovative and valuable addition to their practice.

The Processing Foundation Fellowship supports artists and creative technologists developing open-source creative tools and practices that expand access to creative technology. Through financial support, mentorship, and community partnerships, fellows create tools, artistic works, and research that contribute to a more open and accessible creative coding ecosystem.

• Learn more about the Fellowship → here
• Support programs like this → here

Written by Amy B. Woodman; Edited by Patt Vira and Xin Xin

Fellowship Project: Where has the Lake Gone?

• Artists: Leonardo Aranda
• Links: GitHub Repository

“[Mexico City’s designers] have been building infrastructure to get rid of the water for 300 years and now we are building new infrastructure to try to bring water back into the city,” says media artist Leonardo Aranda.

Leonardo Aranda, director of the DIY creative space Medialabmx, developed the artistic research project Where Has the Lake Gone? during his 2025 Processing Foundation Fellowship. Through experimental cartography and open-source technology, the project investigates Mexico City from the perspective of its disappearing lakes, revealing how centuries of urban infrastructure have buried, redirected, and erased the waterways that once defined the region.

At the heart of Leonardo’s research is the concept of “slow violence.” Drawing from the work of Rob Nixon, Aranda describes this as a form of violence that occurs gradually and almost invisibly over time. In Mexico City, this slow violence is the 500-year history of draining the five-lake system upon which the city was originally built. While pre-Hispanic systems were based on coexistence with water, the colonial era introduced a tendency to control and eliminate nature, leading to the modern paradox of a city built on a lake that now suffers from both constant droughts and seasonal flooding.

Through his research in the National Archive of Water, Leonardo began to realize that the city’s history is “hidden in plain sight” within its modern layout. This shift in perspective allowed him to identify specific structures within bustling streets or common areas that the public often ignores.

Small towers scattered across neighborhoods, structures he had played around as a child, turned out to be aqueduct breathing towers, built to ventilate the colonial water system. In Chapultepec Park, the strange circular fields where people gather to play soccer are not merely decorative; they are the massive underground water tanks that help supply the entire city.

Even the city’s streets hold traces of its submerged past. Certain roads curve into organic Y-shaped patterns that seem oddly irregular in the rigid urban grid … until you realize they follow the paths of ancient rivers and canals. Architectural details offer similar clues. The elevated staircases on centuries-old churches begin to make sense when imagined from a different perspective: once, boats could pass directly beneath them. What appears today as an ordinary cityscape is, in fact, a layered map of waterways that once defined the valley.

To investigate what lies beneath the modern asphalt, Leonardo built a DIY Ground Penetration Radar (GPR) sensor. This device functions like an ultrasound, sending radio signals into the ground to create images of subsurface reflections.

But using scientific equipment in the middle of Mexico City presents its own challenges. Instead of arriving with conspicuous instruments, Leonardo mounted the sensor onto a bicycle disguised as a traditional tamale cart. Moving slowly through traffic and public plazas, he could scan the ground while blending into the everyday rhythms of the streets.

The method turned research into a kind of urban dérive. Riding through neighborhoods, Leonardo traced the invisible infrastructure beneath the city: the remnants of canals, buried waterways, and forgotten engineering systems that once shaped the valley’s relationship with water. The project became what he calls an “embodied investigation,” a speculative walk through history where his curiosity paired with his DIY spirit worked together to reveal the city’s submerged past.

The project Where has the Lake Gone is deeply rooted in open-source philosophy, which Leonardo views as an ethical necessity for “opening the blackboxed” systems of urban infrastructure. “For me it was important that I would use this idea of how openness has to go all the way through the whole process and the methodologies of the project. It is not only something that you use [as] a way of interrogating the system but something that has to be also applied to the process and the tools that you use,” he explains. He recycled code and circuits from the community and plans to keep his own GitHub repository, including Arduino and Processing code and circuit schemes, publicly available for others to reproduce.

Technically, Leonardo moved away from traditional digital cartography software to create a custom 3D environment in Processing. His process included:

• Data Translation: He used standard shapefiles to extract geographic coordinates, which were then stored in P-shaped objects for efficient rendering.
• Coordinate Mapping: Leonardo developed custom functions to translate real-world geographic coordinates into the 3D coordinate system within Processing.
• Historical Sedimentation: The resulting visualization represents the city as a “stack of infrastructure layers” using different depth values to visually map the city’s historical evolution over time.

Ultimately, Leonardo views the project not as a finished artwork but as the beginning of a methodology intended to empower artists, activists, and communities organizing around water. By opening the tools, code, and circuitry behind the project, he hopes others will build upon it, using creative technology to question the infrastructures that shape everyday life.

“There is a colonial tendency to try to control nature. This project asks how we might restore our coexistence with water,” says Leonardo. What began as a historical excavation becomes something more speculative: a way of imagining different futures for the city. By revealing the hidden waterways beneath streets and plazas, the project reminds us that Mexico City is still, in many ways, a lakebed. The water has not disappeared; it has only been buried. His final goal is to move past 500 years of environmental control and interrogate the systems that define modern life, eventually allowing the city to coexist with water once again.

The Processing Foundation Fellowship supports artists and creative technologists developing open-source creative tools and practices that expand access to creative technology. Through financial support, mentorship, and community partnerships, fellows create tools, artistic works, and research that contribute to a more open and accessible creative coding ecosystem.

• Learn more about the Fellowship → here
• Support programs like this → here

Written by Amy B. Woodman; Edited by Patt Vira and Xin Xin

Fellowship Project: Body as Data

• Artist: Daniel Corbani
• Luna Project: GitHub repository or the website

“Art doesn’t live in the tools; it lives in the experience we create.” Daniel Corbani, author of the Luna Video Mapping Library

Daniel Corbani, an engineer who transitioned into a visual artist and creative coder, dedicated his 2025 Processing Foundation Fellowship to a project titled “Body as Data.” This project expands his Luna Video Mapping library, seeking to bridge the gap between technical engineering and the ephemeral nature of live performance. For Daniel, technology is merely a tool, much like a dancer’s flexibility, and the true art exists in the shared experience between performers and their audience.

The fellowship project, “Body as Data,” focuses on interactive and embodied projection mapping. “The secret here is to use projection mapping to match the position of the generative content to the source… as best as possible to create the illusion that the physical body is touching / creating / interacting with the digital image,” says Daniel. His artistic expression is best exemplified in his collaboration with dancer Paola Higa, whose work involves charcoal drawings and mandalas created through full-body movement.

Luna facilitates this three-stage narrative journey in Paola’s performance:

1. The Illusion: Using pre-recorded video to create the sense of a digital double
2. The Merge: Blurring the lines between the physical performer and digital content
3. The Interaction: A “full merge” where the body’s movement creates images in real-time, such as a fluid or smoke simulation that reacts to the performer’s presence.

This approach transforms the human body into a source of data, using an infrared camera and background subtraction to turn performers into “white blobs” or masks. These masks then interact with digital objects, creating the illusion that the physical body is directly touching or creating the digital image.

Technically, Luna is designed to be both a functional software for non-coders and a flexible platform for developers. The architecture is built upon several core classes:

• Project: The central manager of the entire system
• Screen: A renderer that handles the output to external displays
• Scene: Manages specific moments in a performance, coordinating multiple media types
• Medialtem: Manages individual videos or images and contains the complex homography math required for mapping visuals onto physical surfaces.

A key technical breakthrough Daniel achieved during the fellowship was the implementation of Java interfaces. These act as a “bridge,” allowing Luna to recognize custom generative code as if it were a standard video file. This enables artists to use libraries like PixelFlow for real-time physics simulations while still utilizing Luna’s mapping and scene-management tools.

At the heart of Daniel’s work is a profound commitment to the philosophy of open source. He says Luna is open source largely because “I realized that so much of what I’ve been able to do exists thanks to others sharing their work with me,” whether it’s Processing itself, the libraries he uses, or the examples people publish in forums and on their websites. He continues, “It only felt fair to give something back by sharing my own work in the same spirit.” He views open-source software as both a technical choice and as a primary method for redistributing power to diminish inequality. He recognizes the place of big tech, yet imagines a more communal ecosystem where knowledge, access, and even some economic opportunity circulate freely, allowing creative tools and ideas to reach far beyond their original makers.

Daniel acknowledges that his own growth was made possible by the generosity of the Processing community and shared libraries. Consequently, he intends Luna to be an open platform for those who cannot afford expensive commercial software licenses, particularly artists from marginalized communities. By keeping the code accessible, he aims to share economic power and knowledge, allowing performers in theater and dance to integrate complex visuals without a high financial barrier.

Daniel’s work has generated significant excitement with the Brazilian arts community, where cultural workers are eager for free tools to incorporate coding and projection into their work. Looking forward, Daniel sees Luna as a way to facilitate remote collaboration, “What is most special to me is that with Luna I can reach people far… they can run Luna there and I can send my work and help them from a distance because now we have a great tool for that.”

The Processing Foundation Fellowship supports artists and creative technologists developing open-source creative tools and practices that expand access to creative technology. Through financial support, mentorship, and community partnerships, fellows create tools, artistic works, and research that contribute to a more open and accessible creative coding ecosystem.

• Learn more about the Fellowship → here
• Support programs like this → here

Written by Amy B. Woodman; Edited by Patt Vira and Xin Xin

Fellowship Project: Network Gong Ensemble Archive

• Artists: elekhlekha อีเหละเขละขละ
• Link: https://networkgongensemblearchive.online/

“We thought people would be shy when we asked them to play their gong,” Keng says, “but once they started, they didn’t want to stop. They were banging on their gongs; they listened to each other and responded to one another’s sounds.” No one wanted to stop and the show lasted much longer than expected.

The concept of the Network Gong Ensemble Archive (NGEA) emerged from a question: could a non-institutional effort create a living archive of Southeast Asian oral histories and musical traditions, especially for marginalized and diasporic communities beyond national state identities? The project responds to the ongoing risk of cultural loss caused by socio-political and environmental displacement across the region. The artists’ vision was to not only create an archive, but also a digital space to nurture the human connection of performance, where the act of making noise together creates spiritual and social bonds without the need for verbal communication. In interpreting this year’s Processing Foundation Fellowship theme, the project explores the tension between data, which is often measurable, quantifiable, and shaped by outsider documentation, and storytelling, which in Southeast Asian oral and aural traditions remains expansive, contextual, and relational. NGEA seeks to hold these together, treating sound and oral history as data without separating them from the cultural contexts that give them meaning. Through the medium of sound archival, this project tells the story of collective resilience.

The duo behind NGEA is Keng (Kengchakaj Kengkarnka) and Fame (Nitcha Tothong), who together are elekhlekha อีเหละเขละขละ, a Thai word that means “chaos” or “nondirection.” The name was chosen because it portrays an ethos that breaks free from dominant systems and the Western music lens. The idea for the project mirrors the distinct talents both Keng and Fame bring to their art. For Keng, who is a jazz pianist and electronics experimentalist, the idea for the project extended out of a line of questioning. After completing his college studies in music in Thailand, he noticed “that my head and my ear were geared towards Western music so much that I heard Thai music as out of tune.” He recalls researching how Thai music is often unfairly judged by Western musical standards and even mistranslated in music theory books. “How can I unlearn that?” Keng asks. For Fame, the project is a meditation on memory. Fame is a creative technologist and interdisciplinary artist who built the online experience of NGEA. Inspired by open source technology as a tool for transparency and democratic access to knowledge, she wanted to make the archive less of a museum-like tomb and more of a living, evolving, and communal space that encourages new iterations.

The Archive is a digital repository of living and breathing sound with particular attention to gong practices shared across the region. It is a digital space that compiles and captures the nuance and embodied sounds that reflect Southeast Asian tradition. When Keng and Fame talk about their collaboration with other musicians for this project, they speak with reverence, holding the heavy yet effervescent weight of ancestral knowledge. While documenting Southeast Asian sounds, Keng reminds us that these sound traditions don’t just differ from ethnic group to ethnic group, but sometimes from village to village. Keng and Fame worked with three sound contributors, who talk about how time and loss has also played a role in the evolving function and nuance of these sounds. Keng reflects on a story that was shared with him by an_outskirt, a duo from the Philippines. Back in the Phillipines, an_outskirt had met with a musician who played a traditional flute. However, when they arrived, the musician said he lost his flute. He directed them to come back in an hour, he’ll make a new one. quickly made a new flute and demonstrated its tuning system, as if the sound itself had been pulled from the ground. Measuring the bamboo’s circumference with a blade of grass, he shaped the instrument’s holes directly from the lang that produced it. “Sometimes sounds come from the ground, and what you are hearing is the sound of that day,” says Keng.

The first entries in the Archive bring together a geographically dispersed yet culturally connected group of Southeast Asian musicians. These include:

• an_outskirt, currently based in Brooklyn and originally from the Philippines;
• High Alter (A.k.a.Lynn Nandar Htoo), based in Cambodia with roots in Myanmar;
• and Sorawat Ruangamporn “Kru Amp,” now in New Jersey and originally from Thailand.

Each artist contributed recordings of their gong instruments and created a hand-drawn digital avatar of their gong; forms that were later translated into audio-visual p5.js sketches. Together, these contributions form the foundation of the interactive Network Gong Ensemble Archive website.

While sharing their gong sounds, they also shared their songs and the stories behind their instruments. Sarawot uses the Khong Wong Yai (large gong circle) as his main instrument and has played it for over 30 years. “The more I learned, the more I loved it, and I realized that Thai music has a unique charm that only reveals itself through study,” Sarawot remembers. When moving to New York, he had to cut his gong into three parts and ship it overseas. Once it was reassembled, he noticed it sounded slightly different, but he accepted that as part of its new story. He teaches Thai music today and reminisces on how certain songs that were once tied to a specific activity are now repurposed for this new space with new people, forming a hybridity between the old and new. What is born out of that friction is a third thing: something new born from displacement, memory, and adaptation.

High Altar (Lynn Nandar Htoo) contributed Khmer sound cultures during a tumultuous time in their life. Theirs is a story of personal survival as they fled war-torn Myanmar. They wrote, “Tradition persists not when life is easy, but when it becomes essential. The gong sound might be the only available peace on the most chaotic day.” Keng and Fame reflect on how sounds and songs stem from a place called home, and when forced to move by necessity, music has a healing function. Though High Altar is from Myanmar and Sorawat is from Thailand, the sound they contribute is essentially the same instrument.. Keng believes this is a crucial story to be told. Land disputes and forced displacement are based on “imaginary lines that the colonizers made.” We are all actually more alike than we are different and our sound cultures prove that.

Eleklekha immersed themselves in these sound cultures as they transposed oral histories into digital simulations of sound. The p5.js sketches of each gong are made with care. Fame says, “If you click on the smaller dot you can get an overtone of the two gong sounds together. We intentionally made the two sounds vary slightly in timing so one is hit before the other, reflecting what human gong expressions sound like.” Keng adds, “This is because the overtones are not fully aligned and it creates a beating noise and a sound that you associate with the gongs.”

Once you enter the NGEA site, you can explore sound stories and configure your own gong song. The “Ensemble Mode” feature allows anyone with an iphone or laptop to join a collective, live gong ensemble with other users. First, you are prompted to choose a gong from the library, then to configure your gong song by clicking on the chimes. The song begins looping and projecting around each user’s circle avatar.

When someone enters into your projection sphere by moving around the space with their arrow keys, you can hear their gong song intermingling with yours. Participants are encouraged to roam around, intersecting, colliding, and harmonizing with each other in a cacophony of beating chimes and gongs. Can you hear the echoes of your ancestors or, perhaps simply, the sound of the day?

Fame recounts how “open source tools are essential for our communities because they make creative work accessible to people who can’t afford expensive software and gives us the agency to become not just users or consumers, but creators and contributors.” Through the Processing Foundation Fellowship, Keng and Fame learned to see their collaborators as part of a larger ecosystem, and they felt empowered to share knowledge about these sound cultures without having to be “masters” of the work, but rather to share things little by little via long-term relationships. About 300 people have experienced NGEA as of today.

Open source tools are a labor of care, as Fame puts it. Keng says, “We also want to invite a larger community of people who are interested in Southeast Asian sound to this project. Therefore it’s a living document and helps change the perspective of how music can sound.” Their hope is that people continue to contribute and experiment with The Network Gong Ensemble Archive.

The process of making this project has also led to personal transformation for the artists. Keng says that now “everything is in tune.” He can’t pinpoint exactly how, but this project has changed his piano playing. In fact, it’s a “completely different” approach to the sounds he chooses. In December 2025, he performed at the Asian Art Initiative Festival and the panel noticed how different this performance sounded from the album, that this performance was an evolution. “I finally unlearned my ear,” Keng says, “anything can be in tune now.”

The Processing Foundation Fellowship supports artists and creative technologists developing open-source creative tools and practices that expand access to creative technology. Through financial support, mentorship, and community partnerships, fellows create tools, artistic works, and research that contribute to a more open and accessible creative coding ecosystem.

• Learn more about the Fellowship → here
• Support programs like this → here

Newly released features are typically experimental and open for community testing and feedback. You can find full release notes in the links below:

• p5.js 2.1: TypeScript integration, add-on Events API, and color contrast checking for web accessibility. Introduced branching (if/else) and looping (for) in p5.strands. This release was co-authored by 31 people!
• p5.js 2.2: Introduced WebGPU-based renderer, as well as in 2.2.1: a simpler, flatter API for p5.strands and in 2.2.2: performance improvements and support for “millis()” inside p5.strands

These releases build off of the major milestone release of p5.js 2.0 last year, which laid new foundations for the library’s future. Since then, versions 2.1 and 2.2 have focused on stabilizing and extending those foundations. The features and updates in all 2.x releases are based on community feedback since 2023, and as development still continues, we would love for more p5.js artists, learners, teachers, and creators to get involved in shaping the software we all use!

This post is an overview of the latest releases, and also a moment to acknowledge the people who sustain this library. p5.js has been going strong for over a decade, and like any long-lived open-source software project, its survival is communal. Projects like p5.js persist because of the people who dedicate their time to review pull requests, fix regressions, improve documentation, test edge cases, and respond to issues that most users will never see. Much of this work is quiet and ongoing.

What’s New in 2.1 and 2.2

Versions 2.1 and 2.2 build directly on the work introduced in 2.0. These releases emphasize fixes on stability and infrastructure improvements that make future development possible. Some highlights include:

• New add-on/template support for ecosystem contributors. This is a starter repository designed to help developers quickly scaffold and publish p5.js add-ons and extensions.
• Advanced graphics work (p5.strands and WebGPU): 2.2 continues refinement and stabilization of p5.strands, the shader programming API introduced in p5.js 2.0, to make it easier to get started with programming visuals using the GPU. Additionally, the experimental WebGPU-based renderer, in development for about half a year, is available directly from the p5.js 2.2 build onwards. WebGL shaders written in p5.strands will ultimately work in WebGPU as well, and support for compute shaders is in active development — learn more on the p5.js Discord if you are interested in helping shape this feature!
• Accessibility improvements and maintenance: added accessibility tooling to the core library, including contrast checks, with more utilities planned in future minor releases to help sketches better align with web accessibility standards (WCAG, EAA), alongside ongoing bug fixes, performance improvements, and internal codebase cleanups.

For full technical details, we encourage you to read the complete release notes here: 2.1, 2.2.1, and 2.2.2!

2.x Timeline: We are Here

If you are a p5.js user: this is also a reminder that p5.js 2.x will become the default version in the editor in July 2026.

If you maintain sketches, libraries, or teaching materials, now is a good time to review the compatibility guide and make any needed updates: https://github.com/processing/p5.js-compatibility

The goal of the 2.x transition is long-term sustainability, making sure p5.js can continue to evolve without accumulating unmanageable technical debt.

Learn more about some of the major changes here:

• Interview with Kit Kuksenok and Tim Rodenbröker on release of p5.js 2.0
• Code-along to learn how to use shaders with p5.strands in p5.js 2.0
• Learn more about variable fonts, asynchronous loading, text to contours, and 3D text extrusion

If you have questions, please get in touch via the p5.js Discord.

Friendlier Shaders with p5.strands

The recent releases have significantly advanced p5.strands, a new feature that was introduced in p5.js 2.0. It is a new shader programming API that makes it possible to create complex, high-performance graphics using familiar JavaScript-style code. Strands translates that code into GLSL behind the scenes, allowing sketches to run dramatically faster than equivalent JavaScript-only implementations, especially when scaled up over time.

What does p5.strands make possible?

First, consider this sketch, which uses JavaScript loops to draw a cube of cubes. It is only 40 lines, but if there are many more cubes, it will slow down very much. If it is running smoothly, try changing all the “15” to a higher and higher number, such as “30.” As the scene grows, the sketch performance will suffer very noticeably.

The purpose of shader is to use parallel, GPU-based computation to speed this up. Instead of for loops, here is a second version of the same sketch using GLSL. It is 200 lines of code, and, if you are not familiar with GLSL, may be very difficult to read. Look for the “15” here, too, and try changing it to a larger number, like “30” or beyond. The shader-based animation remains smooth, showing the performance benefits of GPU rendering.

Finally, the p5.strands version of this sketch combines a more accessible, readable style of JavaScript with the performance of GLSL.

With the introduction of the WebGPU-based renderer, p5.strands sketches can seamlessly use either WEBGL or WEBGPU. Here is the same example as above, but using the WebGPU-based renderer. The only changes needed were to use async/await with createCanvas(…), and to import both the main library and the p5.webgpu.js add-on:

<script src=”https://cdn.jsdelivr.net/npm/p5@2.2.2/lib/p5.js"></script>

<script src=”https://cdn.jsdelivr.net/npm/p5@2.2.2/lib/p5.webgpu.js"></script>

Special thanks to @davepagurek for creating the sketches throughout this post.

As development continues in 2.x, community feedback and experimentation play a central role in shaping this beginner-friendly approach to shader programming. The changes introduced in 2.1.1, 2.2.1 and 2.2.2 reflect contributions of not only code, but ideas in how the API should develop. With stabilization and improvement of WebGPU-based renderer, p5.strands WebGL shaders would also immediately work when switched to WebGPU.

If you’re curious to explore, test new capabilities, or help guide the future of p5.strands or the WebGPU-based renderer, we’d love for you to join the conversation on Discord (in #p5strands or #webgpu) and get involved!

Acknowledging Contributors and Stewards of p5.js

p5.js is built and maintained by a global community of contributors and stewards. Over its 10+ year lifespan, more than 800 people have contributed to p5.js, tracked using the all-contributors specification.

Versions 2.1 and 2.2 include code contributions, reviews, testing, and project stewardship from ~50 people. We’d like to give a big thank you to:

@Aayushdev18, @Abhayaj247, @acgillette, @ayushman1210, @calebfoss, @davepagurek, @dpanshug, @error-four-o-four, @FerrinThreatt, @Geethegreat, @GregStanton, @harishbit, @HughJacks, @IIITM-Jay, @Iron-56, @ksen0, @limzykenneth, @lirenjie95, @lukeplowden, @LalitNarayanYadav, @madhav2348, @nalindalal, @nbogie, @nickmcintyre, @nickswalker, @nking07049925, @Nitin2332, @nakednous, @perminder-17, @Piyushrathoree, @reshma045, @sophyphile, @SoundOfScooting, @tychedelia, @VANSH3104, @shawdm, @pearmini, @Vaivaswat2244, @shivasankaran18, @awood0727, @vietnuyen2358, @shuklaaryan367-byte, @rakesh2005, @aashu2006, @jjnawaaz, @LuLaValva, @dontwanttothink, @Anshumancanrock, @saurabh24thakur

While this reflects code contributions, it doesn’t yet capture the full range of work that sustains the project, including documentation, education, design, and community care. We’re actively working toward better ways to recognize these contributions because recognizing this labor matters. Below are reflections from some of these recent contributors:

“I learnt how to draw from coding, I am very bad at drawing and artistic things on hand and paper, but this project gave me opportunity to explore another aspect of my life.” — Nalin, he/him @nalindalal (Contributor)

“Being a contributor has been such a meaningful experience for me. I’m really proud of helping organize and support community discussions that brought people together and sparked new ideas. Along the way, I’ve learned that even small efforts — a bit of time, a helpful comment, a shared resource — can make a real difference. For anyone thinking about getting involved, I’d say just start small: join a chat, ask questions, and offer help where you can. You’ll be surprised how quickly you start feeling part of something bigger.” — Nitin Rajpoot @Nitin2332 (Contributor)

“Contributing to p5.js has been a deeply rewarding learning experience. I worked primarily on extending and improving noise functionality in p5.strands, including GLSL-based noise, fractal noise, vec2/vec3 support, and performance-related improvements, along with documentation and tooling fixes. Through this process, I learned how to work within a large, community-driven codebase, writing maintainable code, responding to reviews, and thinking carefully about API design and accessibility for creative coders. For anyone interested in getting involved, I would recommend starting with issues labeled “Good First PR,” reading existing code carefully, and not hesitating to ask questions. The p5.js community is welcoming, and small contributions quickly build confidence to take on more complex work.” — Lalit Narayan Yadav (she/her) (Contributor)

“I improved p5.js documentation through two PRs … clarified inline examples for better accessibility, and enhanced consistency and tone in instructional text. These updates made the reference pages clearer and more welcoming for new learners. I learned the value of community feedback, clear commit messages, and small, incremental improvements that meaningfully enhance user understanding in open-source projects. Start with “good first issue” tasks, follow contributor guidelines, and don’t hesitate to ask questions. Focus on small, impactful fixes — every improvement helps the community grow.” — Abu Harish @harishbit (Contributor)

“Working on p5.js has been a great learning experience. I focused on identifying and solving issues while continuously learning from the process. I’m proud of the progress I’ve made through contributing and growing as a developer. I’d encourage others to get involved — the p5.js community is incredibly supportive and welcoming, especially for beginner developers. It’s truly been a pleasure working on this project” — Vansh Kabra (he/him) @VANSH3104 (Contributor)

“p5.js has provided me with incredible opportunities to grow as a developer. Under Dave Pagurek’s mentorship I worked on p5.strands, and I feel the project’s values gave me the time and guidance I needed to succeed. I started making sketches soon after beginning to code, and I encourage anyone interested in contributing to do the same. Testing the limits of what I could make, I found myself reading the source code to understand how my sketch ran, and reading contributor docs. The way p5.js is set up for its community makes the move from user to contributor a natural step.” — Luke, he/him @lukeplowden (Contributor & Steward)

“In the past few releases, we have made a lot of progress on p5.strands, slowly making it a more capable and easier way to write shaders. I’ve also been toiling away for a while on WebGPU mode, now testable in the latest release. I’m really excited to see people test these features out, make creative things out of them, and also report bugs and suggestions to me! Plenty of these have been logged and fixed/implemented already. If you’re interested in learning, seeing what other people are doing, and helping direct the future of these endeavours, come join the discussion on the p5 discord!” — Dave Pagurek (he/him) @davepagurek (Maintainer & Steward)

If you contributed to p5.js recently and don’t see yourself credited, or would like to add an additional note, please add your information here so we can acknowledge your work:
https://docs.google.com/forms/d/1Nixz3VTes9W3d-V9kj6ouK3UKWHN28u-X8A9OGhLYfM

Getting Involved

Active development on p5.js continues and there are many ways to participate. We host monthly, informal developer chats on Discord — stop by to learn something new or bring your own bugs to get help. In these sessions contributors help each other troubleshoot issues and are welcome to share demos or propose new ideas. These are not recorded, intentionally low-pressure, and open to people with a wide range of experience.

If you use p5.js, we’d love to see you there:

• Join the p5.js Discord channels for #p5strands and #webgpu
• Check out the contributing guides on GitHub for p5.strands and WebGPU
• Want to test new features before they are released? Check recent releases (2.1, 2.2.1, and 2.2.2) and look for “release candidates!”. These contain instructions for testing, and finding bugs in them is a very helpful way to get involved with contribution!

Contributing to p5.js spans beyond just coding, you could also get involved by contributing to our documentation, education resources, testing, and tooling. Thank you to everyone who has co-created p5.js over the years!

The 2025 program followed up with the theme “Building Bridges,” focusing on stronger connections across the ecosystem: creating better connections between Processing and p5.js, strengthening interoperability, and building pathways that make these tools more accessible and powerful together. The spirit of “Building Bridges” was reflected not only in the projects, but also in the way the program evolved, with returning contributors supporting the next cohort.

Over four months (July-October 2025) our pr05 Developers, Stephan Max, Claire Peng, and Vaivaswat Dubey worked on projects that literally and figuratively built bridges across parts of the Processing ecosystem. Each grantee received 40 hours of mentorship along the way. We want to give a special thanks to pr05 mentors Connie Ye, Claudine Chen, and Stef Tervelde for their unyielding support and guidance.

In October, the cohort presented their projects at OpenAssembly, sharing the results of their four months of work. We’re excited to revisit what they built and take a closer look at the ideas that came out of last year’s program.

Written by Raphaël de Courville, edited by Patt Vira and Amy B. Woodman.

Claire Peng: Incremental TypeScript Migration for the p5.js Editor

Claire used her unique perspective to make the p5.js Editor easier to maintain. As a former fashion designer who discovered coding through Daniel Shiffman’s Coding Train tutorials, her non-traditional background shaped her approach to this technical project: making the codebase more approachable for contributors who, like her, learn best through visual hints and pattern-matching rather than dense technical documentation.

The p5.js Editor is a massive codebase (over 100,000 lines of code built over more than a decade) with layers of legacy dependencies. Rather than attempting to migrate everything, Claire took a strategic approach focused on broad coverage and clean ups across the codebase.

TypeScript allows your code editor to provide more ‘spell-checks’ (or type-checks, as they are called). It also provides better autocompletion to give you more guardrails as you code, sort of like a game of MadLibs, with hints underneath each blank. — Claire Peng

As a result of Claire’s work, the p5.js Editor codebase is now 27% TypeScript. From a user’s perspective, nothing looks different, but for new contributors, the repo now offers the guardrails that make contributing more visual and intuitive.

Thanks to Connie Ye for her mentorship and Rachel Lim for her guidance as core maintainer of the p5.js Editor.

Read More

Claire’s blog post: Incremental Typescript Migration for the p5.js Editor

Related Links

• Migration Project Technical Documentation
• Open Assembly Presentation Video

Vaivaswat Dubey: Building a Visual Regression Testing System for Processing

For a platform like Processing, success isn’t just about a sketch compiling without errors, it’s about how things look. If a shape renders even slightly differently on macOS than on Linux, or if a color blend changes subtly after a code refactor, that’s a regression that can break the creative intent of the work.

Processing has always been a place where art and code intersect. It empowers people to express ideas visually, even if they’ve never written code before. But behind its simplicity is a complex rendering system that must stay consistent across updates, platforms, and years of evolution. — Vaivaswat Dubey

Vaivaswat built a fully native, dependency-free visual testing system for Processing that automatically catches these visual differences. The system runs Processing sketches, captures snapshots of rendered output, compares them to stored baseline images, and highlights even the tiniest differences.

If the color value of a pixel changes, the testing system generates a visual diff (difference) where pixels that differ between the first and second images are highlighted in red.

Testing might not sound “creative,” but when it protects the integrity of an artistic tool like Processing, it becomes an art form of its own. — Vaivaswat Dubey

Thanks to Claudine Chen for her mentorship and guidance throughout the project.

Read More

Vaivaswat’s blog post: Catching Visual Bugs Before They Happen: Building a Visual Regression Testing System for Processing

Related Links

• Visual Testing Implementation

Stephan Max: Creating a New p5.js Mode for the Processing Development Environment

Stephan’s project allows users to create and run p5.js sketches directly inside the Processing Development Environment (PDE) even without internet connection. This new “mode” bridges the gap between web-based and desktop coding.

Now, p5.js users can go beyond the limitations of an internet-dependent, browser-based code editor. Some exciting new features include: saving and loading files locally, accessing system resources, using Node packages, and even exporting sketches as standalone desktop applications across Windows, macOS, and Linux.

My deep appreciation for the Processing Foundation does not come out of nowhere: Processing has been my companion for a while! It all started in 2009, when I bought the book ‘Generative Gestaltung’… That means I have been working with Processing for over 15 years. — Stephan Max

The mode is now available in the PDE’s contribution manager. Look for “p5.js Mode (experimental)”

Thanks to Stef Tervelde for his mentorship and Raphaël de Courville for his guidance as Processing Community Lead.

Read More

Stephan’s blog post: pr05 Grant Retrospective

Related Links

• processing-p5.js-mode Repository
• README file

Moving Forward

Through the pr05 grant, we wanted to show that open-source infrastructure work (the kind that happens quietly behind the scenes) creates meaningful bridges between communities and technologies. Our 2025 grantees embraced this fully, approaching their projects with incredible care, technical rigor, and thoughtfulness about the contributor experience.

I’m genuinely proud of how much intentionality our pr05 grantees put into their contributions. There is a lot more to each of their projects than can reasonably fit in this article, and I strongly encourage you to read their stories in their own words through the blog posts linked above. To watch the pr05 talks and the presentations from the Processing Foundation’s 2025 Fellows and 2025 Google Summer of Code contributors, visit https://openassembly.processingfoundation.org/.

Acknowledgements

Again, a huge thanks to our incredible and supportive mentors, Connie Ye, Stef Tervelde, and Claudine Chen!

Support the Processing Foundation

Processing Foundation is the non-profit behind Processing, p5.js, and the p5.js Editor. We’re imagining open-source software that is free, creative, equitable, and accessible to all. However, free software is expensive to make, and we cannot do this work without you.

Donate now!

Your support is what keeps the Processing ecosystem alive, including core development, infrastructure, community programs, and fellowships like pr05. It helps ensure these tools remain free, creative, and accessible to everyone.

Download Processing 4.5.1 from the Processing website.

Sustaining Processing

Processing has been around for 25 years, which in software years is… a lot.

That continuity is a testament to the foundations laid by Ben Fry, Casey Reas, and to the many contributors who have cared for Processing over the years. Projects like Processing do not persist by accident. They survive because people keep showing up to do the unglamorous work.

We know it is hard to get people excited about infrastructure, especially since much of this work is invisible to most users, but it is still essential. Over the past two years, a huge amount of effort has gone into bringing Processing back into a state where bug fixes and releases can happen.

Last September, we welcomed our new Processing Project Lead, Moon Davé, who is already focusing on clearing the path for contributors of all skill levels, and collaborating with the contributor community to breathe new life into the project.

At this point, we are in a place we feel good about. Processing is stable, moving again, and in a shape where meaningful contributions can happen.

Now feels like a good time to be excited about Processing :)

If Processing matters to you, there are many ways to get involved! Join the Processing Discord, or check out our contributing guide on GitHub.

What’s new in Processing 4.5

Full release notes for Processing 4.5.1

A refreshed user interface

Over the years, the editor has held up remarkably well with its timeless minimalist design. At the same time, some parts of the interface are starting to show their age and feel dated on modern systems.

More importantly, the underlying UI code has become harder to maintain and extend. Even small fixes can take longer than they should, which slows down development and causes frustration for everyone involved.

Starting with 4.5.1, the Welcome and Preferences screens have a new refreshed design, to support better accessibility and make it easier to add new features in future versions.

The main Processing editor window stays the same, and you should not expect any other visual changes elsewhere in this version.

What we’re building on

Starting with Processing 4.3.1, new features have been written primarily in the Kotlin language. Kotlin is fully interoperable with Java, which means we can adopt it incrementally while keeping the rest of the codebase intact. This makes it possible to use newer tooling alongside the existing Java and Swing code.

For the user interface, we are using Jetpack Compose Multiplatform, a modern, reactive UI toolkit built in Kotlin, together with the Material Design 3 design system. This allows us to build new interface components quickly, while still integrating with the existing Swing-based parts of Processing.

Contributors who are comfortable with Kotlin and interested in this work are very welcome to get involved. Come say hi on the Processing Discord.

Accessibility by default

Improving accessibility is a key motivation for this work. Processing’s underlying UI tech was not designed with modern accessibility needs in mind. If we kept everything as-is, we would keep shipping the same limitations.

Jetpack Compose for Desktop provides built-in support for screen readers, keyboard navigation, and other desktop accessibility features. As parts of the interface are ported to this system, they gain these accessibility features without additional work.

That’s the key shift: not “adding accessibility”, but moving toward a UI setup where accessibility is the default.

New UI components

With this foundation in place, parts of the Processing interface are beginning to move to the new UI system in this release.

Material Design comes with a lot of pre-made components which make it easier to ensure consistency across all parts of the UI.

Jetpack Compose also tends to be less verbose than Swing, which makes UI code easier to read and reason about. For example, here is the same component written in Swing and in Jetpack Compose.

Swing

class Processing : JFrame("Processing") {
    init {
        setDefaultCloseOperation(EXIT_ON_CLOSE)
        val label = JLabel("This is a label")
        val button = JButton("Click me")
        button.addActionListener {
            println("Button clicked")
        }
        add(label)
        pack()
        isVisible = true
    }
    companion object {
        @JvmStatic
        fun main(args: Array<String>) {
            SwingUtilities.invokeLater {
                Processing()
            }
        }
    }
}

Jetpack Compose

@Composable
fun Processing() {
    application {
        Window(onCloseRequest = ::exitApplication, title = "Processing") {
            Text("This is a label")
            Button(onClick = {
                println("Button clicked")
            }) {
                Text("Click me")
            }
        }
    }
}

The new Welcome screen adds faster ways to get started, a list of useful links, and a scrollable collection of example sketches.

In earlier versions of Processing, showing most options on a single screen worked well because there were only a handful of them. As more features were added, the Welcome and Preferences screens became increasingly cluttered, making them harder to use and difficult to expand upon.

The new Preferences are searchable, and organized into clear categories, which makes it easier to add new settings over time.

The new Preferences screen also makes it easier to work with experimental settings.

Previously, these settings could only be changed by manually editing the preferences.txt file. Now, they can be viewed and edited directly from within the Processing interface.

Incremental approach

We chose to migrate the Welcome and Preferences screens first because they are self-contained, and include most of the interface elements needed for the project (menus, cards, dropdowns, checkboxes, sliders, etc). This makes them a good place to start and test the new design.

Rather than doing a large redesign or re-starting from scratch, we chose to take a careful, incremental approach, so we can demonstrate the new system, gather feedback, and invite contributions as we move forward. This is possible thanks to Jetpack Compose’s interoperability with Swing.

It takes a village 💙

We have already received useful feedback from the community through the beta release of Processing 4.5. Thanks to everyone who tested early versions, shared feedback, reported issues, or contributed ideas.

Want to help make Processing better? Download Processing 4.5.1 from the Processing website, and if you find any bugs or issues in this release, please open an issue on GitHub.

Join the Processing Community on Discord.

Acknowledgment

Part of this work was made possible by funding from the Sovereign Tech Agency.

In 2025, the Processing Foundation celebrated its thirteenth year of participation in Google Summer of Code (GSoC)! The primary goal of the GSoC program is to welcome new contributors to open-source software development. Out of a pool of about 150 submissions, 3 outstanding projects were selected to improve p5.js coding experience. Each project was supported by mentors, and culminated in merged code and a public presentation at the Open Assembly in 2025.

Project 1: Context-Aware Autocomplete and Navigation for the p5.js Editor

• Contributor: Kamakshi Bali
• Mentors: Diya Solanki and Tristan Espinoza

Project 2: Translation Mapping and Accessibility for p5.js

• Contributor: Divyansh Srivastava
• Mentors: Kit Kuksenok

Project 3: p5.js Sketch Embed Tool for Blogs and Websites

• Contributor: Ego Nwaekpe
• Mentors: Dora Do

During GSoC, contributors work on projects in mentor orgs, learning how to be a part of the open source software community. In 2025, Processing Foundation was one of 185 accepted organizations. Each contributor is supported by one or two mentors, but is responsible for completing their own project. The contributors worked over the summer, and shared their work in the Open Assembly alongside other 2025 Processing Foundation grantees and fellows.

Once the GSoC program was complete in the fall, the mentors from the participating organizations came together in Munich for the GSoC Mentor summit. This inspiring and energizing unconference connected us with open source mentors and maintainers over conversations on how to make open source software communities more sustainable, inclusive, and welcoming.

This year, three mentors from Processing Foundation were able to attend: Diya Solanki, Tristan Espinoza, and Kit Kuksenok.

Processing Foundation mentor delegates, Diya, Tristan, and Kit participated in unconference sessions and discussions that reflected on improving GSoC application and contributor engagement, on funding and governance in open source, on diversity and open source community health and sustainability, on open source in academia and in computational biology, and tooling for supply chain security.

The conversations at the mentor summit translated practical input into ongoing project work and into ideas about projects in internationalization, simulation, and academic collaborations, as well as reflections for future programs. For example, this pull request introduces clear guidelines on how LLM-based tools should interact with this repository and its contributors. With the goal of removing barriers to contribution, we will improve the application processes with a clear template, focusing on custom projects grounded in experience with the Processing and p5.js ecosystem.

Thank you to our cohort of GSoC Contributors, mentors, and advisors for another amazing summer of code. We hope to keep supporting the creative code and open source community, year after year.

Want to support the Processing Foundation in this work? Donate here to support our ecosystem of open source contributions!