The Lab

Thinking with Code

As a designer, I typically approach problems with a visual solution in mind. Through the process of brainstorming and sketching, I eventually arrive at a “vision” of a solution that only fully exists in my head until it’s fully produced. The digital tools available for this kind of work make it very easy to produce tangible sketch versions very quickly, and layer complexity on top until a polished version of that vision is finished.

From an outsider perspective, it’s easy to think that making music has nothing to do with painting, but the more I branch out into new creative fields, the more similarities I see. I’m a firm believer that creative process is modular and universal to an extent. The steps of research, ideation, development and revision exist in all creative fields, whether it’s music, pottery, interior design, coding or anything in between.

Working on Cymata has given me new perspective on code projects. I’ve heard the term “creative coding” tossed around, but always thought that was referring to the result, not the process. It’s just numbers, after all. As the project unfolds, and we test new territory, we always find new challenges to overcome. It’s really helped me realize that the process of creative problem solving is indeed the same in any discipline. It’s the problems that are different.


In Matt’s last post, he explained some of the process involved in laser cutting our last prototype. Above is an example of the raw output from the processing sketch. A grid of circles, with their size controlled by audio parameters. This approach seemed logical for our first test run, but was very wasteful in terms of material usage at the laser cutter. A problem we never really considered on screen. Below is an example of how the cutsheet should be optimized for cutting, to minimize wasted material.


While it’s certainly possible to manually correct this problem on a small scale, what happens when we scale the project up to produce several thousand “snapshot” circles. Suddenly, it’s not as easy as dragging and dropping a few times, and not really a feasible time investment. Another problem is that the circles themselves are a variable radius (eventually varying in shape as well). Now what we’re looking at resembles more of a math/physics problem than a visual one.

Daniel Shiffman‘s Nature of Code project is an amazing resource for learning the connections between natural phenomenon and physics and how to develop the math to reproduce them in processing. In his chapter about Physics Libraries, he looks at very similar problems to our cutsheet.

Polygon Physics

Without getting too far into the math and code, above is an example, showing more complex shapes colliding, but not intersecting. Our solution looks similar, but the boundaries are just extended past the original shape, to provide spacing between them.

This is just a small example problem, the kind any coder could run into every day, and that we’ve seen many times since the beginning of Cymata. Just like with more traditional art, I find a lot of times it’s the things that seem simple that really aren’t. In 3D animation, it’s surprisingly easy to simulate the motion of water. Making an object float on that water, while it’s in motion is a much more complex problem, though.

Overall, the idea here is that thinking in code (or any new medium) can give a refreshing source of new problems to solve. The word “problem” might not sound exciting, but it’s the process of overcoming those problems that gets creatives really excited. I’m no exception. If you’re ever feeling like you need a change in whatever art you practice, try another one. You might be surprised what you learn about yourself and your process.

Drop a comment

Your email address will not be published. Required fields are marked *