Here are some of the better sketches that came out of the evening from me.
Compressed charcoal and charcoal pencil.
Continuing from yesterday’s progress, this time around I’m visualizing the data set as actual strokes (ribbons) and trying to show amplify their velocities by increasing stroke width. It’s a basic drawing trick that you see all over the place.
I guess I’m trying to wrap my head around the data set right now. I have a lot of ideas about where I could take this, but I’m not quite sure which one to pick.
Today I finished up a drawing — a bad self portrait. This is the first piece I’ve used as a data source for the new Flow Receiver capture system. It was drawn over a couple days / sessions. As soon as I finished it, I immediately exported the captured data, a 9MB XML file consisting of about 150,000 points.
Then I made the simplest visualization of the data I could. Using openFrameworks and the TinyXML C++ library, I plotted a semi-transparent circle for each point in the data set. You can see the output rendered here:
Note: Super sorry about the seriously shaky footage above. Next time I’ll make sure it doesn’t happen.
Yesterday, I spent about 12 hours making what I thought would take “a couple hours” — the Flow Receiver module. In the video above, you can see me demoing the system. Everything is up and running and working seemingly well. This means it’s time to start creating “art.”
I designed the UI for this thing to be as simple as I could make it while also accounting for the fact that I’d be using it on a touch-enabled display. It only has three different “views” which you can see below.
Flow Receiver intercepts this TUIO data and displays the incoming data in the right-side panel. I’ll also use this software to interface with the Flow Storage back-end module for creating projects and recording the TUIO data to those projects.
When in “recording mode”, Flow Receiver buffers the incoming TUIO points until its internal “cache” is full, then sends that info via HTTP POST request to Flow Storage which dumps it into a MySQL database. I’m also storing a timestamp (to the millisecond) with each TUIO point collected so that I can later determine velocity data between “frames” as needed.
When it’s time to export a project’s data, I’ll use Flow Receiver to export the data as either an XML or CSV text file.
Not much else to it than that; it’s a super-simple application.
On a side note, I’m pretty amazed at what we can do with technology these days, the number of options from which we have to choose, and the speed at which we can produce this stuff. I’ve somehow managed to create a fully-functioning toolset in a total of about 20 man-hours, cobbled together from open source libraries, applications, and various other technologies — all at pretty much zero cost (aside from the time put in).
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.
As I prepare for my new job which starts on January 4th, I’m taking some time to learn Derivative’s TouchDesigner. It’s a realtime procedural 3D / compositing tool. Well, it’s actually so much more than that, but it’s very difficult to describe.
Anyway, I’m trying to learn it. And I’ve found the best way to learn stuff (for me) is to take something I’ve already made and try to recreate it in the new environment. So, that’s what I’ve started doing here. I’m not sure how much further I want to go with this, but it’s nice to know that I could pull this much together after about an hour’s worth of work.
This software is terribly powerful, and more and more documentation / improvements / tutorial videos are being added all the time. It’s making me very excited about 2010.
Another ugly self portrait. 2B charcoal pencil. Kinda lost interest after a bit, so I didn’t bother with the eraser.
I’m feeling the mouth and the nose areas, though. This would actually look / be more interesting with a tight crop focusing on those parts (you can see what I mean in the grid).
Eh, it’s a sketch. More to come.
Created this one with Vellum. Having some difficulties getting to sleep tonight, so I thought I’d try out the new ink quality and improved zoom functionality of the app. Definitely feeling better, but I’m looking forward to future updates so I don’t have to do an entire drawing in a single session.
I’m referencing another photo I took of myself where I’m pushing my face around with my hands.