Casey Reas

I studied graphic design specifically, while hanging out with architects and industrial designers and fashion designers all the time. At the University of Cincinnati, there was a lot of mixing between all the different disciplines. That education was, in the 1990s, very similar to an experimental art education from 50 years before.

It was Bauhaus-based education; very open to exploration. Let’s look at what a material can do and then explore those properties and have the work come out of a process rather than a preconceived notion of what we want to do. At that time there was a strong shift away from the analog to the digital. The first few years I spent in art school, I was painting every day, drawing every day. And then the last few years, I was working completely on the computer. It was a shift and a transition.

What I got out of that was this idea of following process, having an experimental practice, which for me means not knowing what’s going to happen. I’ve brought that all into the work I’ve been doing since. The real shift was going to graduate school at the MIT Media Lab and studying specifically with John Maeda and working with the other students there. That was my pivot more from a design-centric point of view to an art-centric point of view.

That’s very essential to everything I’ve been doing. It’s a desire to get outside of myself. It’s a desire to get out of biases and things that I already know and to search for something unexpected.

The way that I do that is through a balance. There’s a lot of analogies you can make. If you’re drawing, you have ideas about what you’re doing, but then the materials, your hand – things happen. If you’re working with music, the kind of music that I like is very improvisational. You have a foundation, you have a basis, but unexpected things happen in the act of performing. For me, I search for the same thing in the software. There’s a lot of decision-making and a lot of framing in there, but for me, it’s not interesting unless unexpected things happen.

Ideally, when I look at the work running live as code, I see things that I’ve never seen before. And when I walk into the room where my work is installed, I see something I’ve never seen before. That spark and that balance between having something that is controlled and something that’s out of control is in all the work that I make.

That work was all done with Ben Fry and started in 2001. The landscape of art and technology and code and generative art was very different in 2001. We started Processing for two reasons. One was to have something that allowed us to make the work that we wanted to make in a way that we felt was more fluid. Second, we wanted something to teach with, to emphasize what we thought was most essential about computation.

We have always talked about coding as “sketching with code.” The more traditional way of thinking about code is to plan, and to plan, and to plan, and then implement it. The idea of sketching with code is that you don't really know where you’re going. You get things out quickly. The idea is that sketching works best when you’re sketching in a similar medium to the final. If you’re an architect who's sketching, you’re going to work with cardboard or chipboard. If you’re a musician who's sketching, you’re going to work with the instrument that you’re most expressive with. If you’re coding and sketching, it’s not enough to make diagrams and to draw and to plan. You actually need to experience things running as code.

Also, we weren’t comfortable with any of our options for teaching coding to beginning artists and designers who wanted to learn it. Twenty-four years ago, there wasn’t a lot of coding happening in art schools. When it did happen, it was often a software corporation’s view of what a coding tool for artists would look like, or an engineer’s view. One thing about Processing is it’s always been made directly by designers, artists, and architects for other people in those fields. It’s always been open source, non-proprietary, and has always been extended by the community based on what different individuals and groups in the community wanted to do.

It’s about how to engage with the technology directly so that the assumptions that other people have made about technology can be pushed further. There’s a lot of tools that emulate prior media, like Photoshop started as a digital darkroom, Illustrator started as a simulated drafting table, but software medium can move far beyond mimicking or simulating prior media. Once you really learn how to code and get your head around what it can be, that opens up a space for, “What else can I do?”

Another way we do that is through reading. The generations who’ve grown up with the internet and grown up with technology always being there might be less critical than the older generations because it’s something that has always been that way for them. So we read critiques, people questioning the ethics of social media or data sets, and begin to imagine what else could be. The reason for doing that is to encourage them to imagine something else, encourage them to build the future of what art and technology will be like rather than assuming this is it.

If I’ve learned one thing over the last 25 years of engaging with this is that things change rapidly and assumptions you make are often wrong. It requires constant rethinking and course correction in order to move the world in the way that you want, and individuals have strong agency for doing that.

Net Art absolutely is a standout moment. With the World Wide Web in 1995, we no longer needed to wait for curators or institutions to tap us on the shoulder. We could publish our own work. We could create new ecologies for viewing and experiencing art at a global scale that were outside of that system. A lot of work emerged out of that. Then it was largely subsumed by the dot-com bubble and crash, only to reemerge on the other side as something different.

In the early 2000s, there was a strong and vibrant energy around creative coding. At the time, people generally talked about it in terms of “generative art” and “computational design.” That was fueled by what the web and the internet provided. We could publish our work online, host it on our own web servers, and share the source code. The idea of sharing code grew out of the open nature of the early web. In the early days you could always go to a website and view source and sort of see how it was made. That’s how everybody learned how to work on the web then. We applied that to creative coding too. Collective learning was established at that time.

When NFT communities surged in 2021, it felt like that same energy from 1995 and the early 2000s was back. It was a moment of creative explosion – artists sharing their work with one another, and supporting each other. For me, those moments continue to stand out.

I think There’s two fundamental different approaches that artists can take. One is the emulation approach, where this software was made on Windows 95 and it should always be seen on Windows 95 on a CRT monitor. My own approach has been that I'm very frustrated with the technology at all moments. it’s low resolution. it’s not fast enough for my vision of what I want the work to be. I always think of it as being transitional.

My approach is that the work should be ported and migrated to whatever the technology is in the moment. Some of my works have now been ported three times from prior systems up to the present moment of 4K displays. I’ve been continuously migrating work and I hope the work will be continuously migrated.

For me, the source code is not precious. it’s not the most important thing, but the source code has all of my ideas about what the work is within it. The source code is the sheet music. That’s how somebody will know how to perform this work in the future. Every detail and definition and idea I have about the work is encoded there. The source code needs to be available. It needs to move with the work and that’s where things are in the end. I really want the work to be migrated as technology evolves.

The most significant one was a long time ago, around 1994. I was in my early 20s then. I was working in Boston as a graphic designer. I visited the MIT Media Lab for a symposium. The work of Muriel Cooper's group, which was called the Visual Language Workshop, was being presented. That was a moment where I believe I saw, for the first time, the potential of software as a medium, as being completely unique and on a different path from what I understood from video and film and print.

Muriel unfortunately passed away young, and John Maeda came to the Media Lab to hold that space of combining design and computer science together. When I first saw John's work, I saw my path forward there. It was this hybrid of ideas of computation with extreme visual sophistication. Until I saw that work from John, I wasn't able to find my path forward. At that moment, it was like lightning. Everything that I did for years after that was working towards that goal.

I left my day job, studied computer science at evening school at NYU. And then a couple of years later, found myself at the Media Lab doing exactly that – beginning to explore that synthesis of ideas of computation and visual systems through art.

It was years of desire and years of trying to find that path, but it was elusive. And then, all of a sudden, there was great clarity.