ICM - In Review
Having had little prior programming experience and a brain that seems to work at right angles to code – my semester spent with the Processing language (http://www.processing.org/) was sometimes a challenging if not harrowing experience. When confronted at 3am with an error message that looks something like the following:
Semantic Error: No applicable overload was found for a constructor with signature "XMLRequest(Temporary_4678_9363.Bubble, java.lang.String)" in type "simpleML.XMLRequest". Perhaps you wanted the overloaded version "XMLRequest(processing.core.PApplet $1, java.lang.String $2);" instead?
… I sink into my chair and stare intensely at the screen, waiting for it to reveal what’s really going on. It always seemed that my breakthroughs would come after eight or nine long hours of this. The most difficult leap has been transitioning from simple concepts (move square 1 from left to right and then repeat) to more complex and evolved ideas (see defunct final project idea). I have come a long way though. Part of what I’ve realized, what I’ve learned, is that I need to start with those simple concepts and gradually build up from there. My tendency was to have very grandiose visions for projects and then to get lost in the details.
Final Project – The Proposal
My original proposal for the final was to expand upon my midterm project – this bubbling tank of ITP listserv messages. I wanted to create a way for ITPers to tag their messages so that they would link together into topics on my visualization – forming clusters of ideas and threads as they appear and disappear within the student population. This turned out to be a rather ambitious idea.
The Processing language is primarily designed to be a tool to create visualizations. While it can be very easy and effective for that purpose, it’s not really meant to be performing complex text parsing – for example. Such that one might have to do if one were to create a listserv bubble visualization. Well, I stubbornly ignored this as I tried to pull hundreds of messages from email into my applet and display them with some rhyme or reason. I feel like I spent weeks just trying to coax Processing into checking my Gmail account.
Processing does not have a library to check email but Processing does have the ability to use Java libraries. Ahhh Java. Programming with Processing is actually programming with Java! But we were not learning Java – we were (supposed to be) working within the world of Processing.
In the end – the bubbles burst (ha). Although I was able to get the JavaMail libraries working within Processing (thanks to some help from Shiffman) I was not able to really make much sense of all the information on the screen.
A Photo Booth
Fortunately, I had another project brewing in my Physical Computing class. We were building a photo booth and needed to produce some code to actually display the high resolution output coming from my Canon 20D. This was the perfect application for Processing – and a rewarding and realizable use of my new found abilities.
Working with Daniel Soltis, we devised a system to trigger the digital SLR with an Arduino microcontroller, process the images, and feed them into an applet that displayed the photo strips.
The initial code worked well for a few test shots but quickly broke and became overwhelmed after hundreds of photos started to come in. Loading images while the applet is running tends to cause some hiccups in the display… especially, if you try to process the images at the same time (rotate, adjust color, crop, etc.). It stored the photographs in an ever expanding arraylist which quickly sank the computer due to the use of RAM. Another problem was that some weird bug in Processing (or the use of array lists) caused the two film strips on either side of the screen to behave erratically – change speed, overlap, etc. if the program displayed the same image twice on the screen.
These problems were eventually solved by rewriting the code to display shorter photo strips and controlling each moving image independently - reverting back to a fixed sized array of 32 photographs. The program still ate about 1 GB of RAM but it was manageable and stable. I also implemented a method to display the current photo set to the user after they existed the booth.
The only bug in the system which has not been corrected is an occasional photo rotation problem. In order to off load the work from the display applet, we’re currently doing the post proccessing using a set of Canon utilities. When the picture is downloaded from the Camera, it needs to be rotated and processed for display on the screen. The camera only sends data in landscape orientation so the file needs to be opened, corrected, and saved so that Processing can pick it up. Because the Canon application is not talking to the Processing applet, they occasionally (maybe 1 – 5 % of the time) step on each others toes – both trying to access the same file at the same time. The display applet does not have any connection to the applet that is determining the timing for the shoot at the moment. One solution may be to network the two computers (silhouette visualization and photo display) so that one knows what the other is doing. Another might be to write a script to move the photos to the applets data folder after they’ve been processed by the photo utilities.
In the end, I was very happy with the results – both with the entire project and my evolution with code. My instructor, Daniel Shiffman introduced me to a wonderful tool for future ITP projects, and provided an excellent framework in which to get up off my feet (and an excellent book! wink wink). I may still have a long way to go with programming but I’m really looking forward to future classes and the transition to Java.