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.

+ View larger on Flickr.

+ View larger on Flickr.

+ View larger on Flickr.

Everything for Flow Receiver is built using Adobe AIR. It communicates with Community Core Vision using CCV’s built-in UDP->TCP bridge which sends out TUIO data associated with the tracked blobs.

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:

Flow Generator

That’s me. It’s my arm, my hand, my pencil. I make marks, and that’s where this all starts.

Flow Converter

This portion is described in this post. A piece of software called CCV uses OpenCV to track the movements of my mark-making. It then outputs this tracked data as TUIO 2D cursor objects.

Flow Storage

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.

Flow Receiver

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.

Flow Visualize

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.

What’s next?

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.

It definitely took some time. But it’s finally out. And just when I thought I had all my bases covered, Adobe has just released a new public beta of AIR along with a new public beta of Flex 3. This renders two very crucial tutorials that I put together obsolete. I’ll be working this week to update those two tutorials.

For now, if you’re willing to brave it, here are the links a few folks have been waiting for:

• visp-vj.com – The official site for visp.
• visp Google Code Project – This is the project’s home for source code, bug tracking, and other related nerdiness.
• Mailing List – This is the Google Groups mailing list for visp.

I do want to say that visp has definitely been created with programmers in mind. You build your custom media from the ground up. I’ve tried to simply encapsulate things into the flash.display.Sprite class as a base (for custom media) and provide an easy API for handling both software UI input along with MIDI input.

If you’ve got questions, problems, bugs, or simply need some help, please head over to the Mailing List. I won’t be answering anything in the comments of this post. On the list, I’ll do my best to answer in a timely manner. And if you’ve got feature requests, they’ll be duly noted. But remember, this is opensource software, so you’re more than welcome to build the features yourself.

I’ve got a long list of excuses and a short list of completed milestones. However, visp is still moving forward (believe it or not). Here’s what I’ve done since the first preview post:

• Revised functionality (by taking a lot of the more complicated and not-100%-solid features out)
• Revised interface size so that it’ll work with 1024×768 screens (since that’s likely to be the minimum resolution for most laptop VJs)
• Created a consistent API for creating media modules, filter modules, and transition modules
• Set up the proper destination site and domain along with the Subversion respository
• Combed through source code to keep formatting and variable naming consistent
• Fixed some bugs
• Updated codebase to use the latest public release of Apollo (beta 1) and Flex Builder 3 (beta 1)
• Rewrote the MIDI proxy to be usable with all MIDI devices and not dependent on Processing (to reduce memory and processing overhead).
• Rewrote the input interface so that media can be controlled via on-screen UI elements (sliders and buttons)

I’ve still got some more items to go. I want to make sure folks have proper documentation and tutorials for creating their own media, filters, and transitions. I also want to make sure that simply getting the projects set up in Flex Builder 3 is very straight forward (i.e. step-by-step instructions). There will be a 1.0 release in mid-September; I have an Adobe Edge Newsletter article being published on visp, so it has to be done.

Thanks for your continued patience, everyone.