Almost two months ago, I posted a status update on my ongoing project I’m calling Flow. That was a long time ago.
What you guys might not realize is that the last couple months have really been dedicated to making sure Flow is a successful project in 2010. That’s what all this NaNoDrawMo and drawing business has been about. In my mind, Flow is completely dependent on my ability to create visually compelling traditional art.
Now let me give you the details of the project.
Flow is going to be a project (the first of many, hopefully) where I explore the intersections of traditional media and digital media. The impetus for Flow was originally the untitled conté drawing I produced in November of last year. When I was making that drawing, I realized so much of what I loved about the stuff I did was due to being in a flow state. Moreover, when I draw or make traditional art (which doesn’t really require any critical thinking skills), I’m able to completely lose my sense of self. It becomes meditative, rewarding, and I find myself to be at my happiest.
So I wanted to create a project for myself that would a) permit me opportunities to enter this state of “flow” and b) help me bring together these seemingly opposing mediums: traditional art + digital art.
The goal of Flow is to capture the energy, the gestures, the strokes that are lost forever in many traditional art-making techniques as a digital data set. Then to create derivative works generated from that data through digital computational means. I aim to create works that can be played back in realtime or as pre-rendered static pieces.
Eventually, Flow may evolve into a real-time drawing system, but first I want to see where this original goal takes the project.
All that said, we’ve got a few distinct modules that make up the Flow project:
That’s me. It’s my arm, my hand, my pencil. I make marks, and that’s where this all starts.
This is what I was building today. It’s a back-end system that’s a locally-running web server with a database (all powered by XAMPP) running an application I created using the excellent open source PHP framework called CodeIgniter. This stores the projects (so I can do multiple pieces) and their respective point data — all time-stamped.
This is the front-end that receives the data from the Flow Converter. It’s what you’re seeing in the wireframe sketch. For this iteration, it will be an Adobe AIR application that receives the data from the Flow Converter module (via a FLOSC UDP->TCP conversion) and send this data to the Flow Storage module. This AIR app will be used to create new projects, start/stop the recording of data, and finally output XML or CSV data sets of all the point data collected for any given project.
Once a piece’s data has been stored and a flat file of the data has been generated, I’ll be able to start creating derivative works from that data. Because I’m using a common file format for the data, I’ll be able to use practically any programming environment to read, manipulate, and generate from that data set.
Why the modular approach?
As you can see, I’m using a TON of different technologies here. The biggest reason I’m not baking this all into one cohesive application is because I want to be able to use these various pieces later on in the year / decade / my life. By making the Flow Receiver module only dependent on TUIO input, I can use any number of other wacky TUIO-generating input devices / systems to create data. (I’m really interested in the idea of plastering myself with IR LEDs and dancing — basically doing motion capture.)
By creating the back-end portion (the Flow Storage module) as a web app, I could feasibly turn this into a multi-user or online application — rather than baking the MySQL database into the AIR app as a SQLite database. Moreover, it gives me flexibility on the front-end — I could create any number of other applications for receiving that TUIO data (to replace the Flow Receiver module), transforming it in realtime before it hits the database. I’m thinking about the idea of realtime data manipulation by other humans as one human is generating the source data — a collaborative creative process. And both roles don’t need to be humans — either could also be a computer. Or heck, both could be computers. The point is this: decoupling the data receiver and the data storage components yields better possibilities.
Lastly, I’m also using the technologies I know (PHP, ActionScript, etc) because it’s faster (for me to work with, not from a performance standpoint). And I’m heavily relying on various open source projects because a) it’s free and b) they do a lot of heavy lifting. I don’t need to reinvent the wheel. It’s always best to stand on the shoulders of giants. And mix metaphors.
I need to get to the point where I can just start creating the source data. So, tomorrow I’ll make the front-end AIR app which should take a couple hours. Then I’ll be ready to go. I’ll probably do a test sketch just to get some data in, then do a really simple visualization on that data. Seems like a good day project.
So that’s it. Flow is on its way to being an actual thing. And it has me super excited.