Spiral5PTL (Daniel Sandin, 1975)

Early in 2013, Processing Chicago hosted an event in tandem with ReCode Project. Unlike most ReCode translation projects, P5 Chicago chose to translate an early work of video art by Daniel Sandin. The choice is unique not only for its medium, but also because the original piece was a live performace. Translating this kind of work raised a lot of interesting questions, the most important of which was how to maintain the original intent and feel of the work in a coded, non-live environment.

In their brief to the attendees, the organizers emphasized "As this piece was originally performed, the goal is to create a framework that allows new performances. So, we ask that people who work on this keep it that way. That can take any form one prefers, e.g. a Processing UI library (like controlP5), Processing talking to an Arduino + knobs, buttons, etc."

To that end, the group set to work with a few goals specific to Spiral5PTL:

  • Maintain the artifacts caused by the PDP-11 Vector General Calligraphic Display, such as slowly decaying visual forms.
  • Accompanying sounds similar to what was done originally on an ARP 2600 analog synthesizer.
  • Provide a user interface that allows ease of performance, and the ability to change parameters of the piece quickly and easily, with the ability to save certain states for resuse.

The code for this translation can be seen on GitHub: https://github.com/spiralP5/spiralP5.

Below are some responses from one of the founders of Processing Chicago, JD Pirtle.

How did you find Spiral5PTL, and why did you chose it to work on?

I chose Spiral5PTL due to the fact that I am employed as a researcher at the Electronic Visualization Lab at the University of Illinois at Chicago, and Spiral5PTL is a work by the founders of this lab (Dan Sandin and Tom Defanti). Both are pioneers in computer graphics, video processing and transdisciplinary art making. They founded the lab in 1973, and in 1980 created one of the earliest MFA programs in art and tech. I regularly collaborate with Sandin on many of the lab's current research efforts, and have always been a huge fan of his work and philosophy. It seemed like a good choice for Processing Chicago's participation in the ReCode Project, as I host our meetings in the lab.

As for the reasoning behind the choice of video, it was a matter of selecting one of Sandin and Defanti’s pieces that was iconic of their work and of the origins of this lab. This piece is unusual in that it was originally performed, so what we are actually doing is creating a framework or environment for unique performances of the piece, but trying to keep the look and feel of the original framework (e.g. artifacts of the vector displays used).

How did you approach the project as a group?

There are a lot of different aspects of this piece, so we knew that the port would be complicated and would require a bunch of people working on each component individually to accomplish it. The typical Processing Chicago meeting is ~2 hours, so my goal was to establish a dialogue about the goals of the project, and to come up with a sensible outline. Fortunately, Dan Sandin was able to attend and gave a talk about the piece, with an excellent portion dedicated to how it was made and what the components he thought would be important for a successful port.

I put the code that a few Processing Chicago attendees began on GitHub after this initial meeting, and I’m hoping that folks will continue to add to what we started. I am particularly interested in the audio needs for the piece (originally performed on a ARP 2600 analog synthesizer), so that is the area I am working on.

What did you encounter along the way?

So far, it’s been really interesting to see how people have approached the port. There’s no surviving source code for the piece, so aside from Sandin’s guidance, we are basically working from the videos made of the piece being performed, and the equation for a spiral (which is the origin of the basic forms being manipulated in the piece).

How do we use it? What can we learn from it?

There has been some great work done thus far by several people to get the project started, but there’s a lot left to do. My goal was to initiate the effort, and then provide an opportunity for people to work on it wherever or whenever they want. Many regular Processing Chicago attendees expressed interest in the project—as well as a number of other artists—so GitHub seemed like the obvious choice for an ongoing, open collaboration. I’d love to eventually see numerous versions being carried out in a variety of ways, with interesting approaches to recreating the feel of the piece and using novel control systems for the performance.

I think the most important thing we’ve learned so far is the overall need to constantly be thinking about the archival potential of any work of computational art. For example, if we have the source code for an artwork, we could at the very least understand the basic principles of what the artist was doing, and reinterpret that to something contemporary. However, the ideal scenario would be regular ports of an artist’s body of work…at least more frequent than 35 years.

Processing Chicago serves as a node for creative coding and electronics, hosting a monthly meeting at the Electronic Visualization Laboratory (EVL) at the University of Illinois at Chicago. The meetings consist of workshops and presentations given by artists, designers and scientists exploring creative research using a variety of media and toolsets, including (but not limited to) Processing, Arduino, openFrameworks, Cinder, Max/MSP and Supercollider. Processing Chicago was founded by Daniel Sauter and JD Pirtle.