I have a piece in the San Francisco International Film Festival. Weird, right? They have a thing called Generator which is an amalgam of a bunch of digital art shorts. My Advanced Beauty piece is in there, along side the works of Lia, Toxi, Watz, and several others. Thanks to Matt Pyke for entering it. I think he entered it. I didn’t.

After 95% of the comments suggested I submit the Radiohead piece to the Aniboom contest, I went ahead.
http://www.aniboom.com/Player.aspx?v=210097

I poked about a bit to see some of the other submissions, and there are some really well thought out storyboards up there. Im looking forward to seeing the final selections.

As many of you know, Radiohead is having a video contest dealie. Lance pointed this out to me back in March and suggested that I give it a go. And a go I did give.

First, however, I will discuss why I have decided not to submit my entry.

After I started working on the piece, I read the rules and regulations and reread the original post on Wired. And then I rewatched my piece. Thats when I decided to skip the contest. Its not because I don’t like the piece I made. Quite the opposite actually. But after watching and watching, I realized my piece has nothing to do with Radiohead at all. You could swap it out with any electronica song and it would actually fit a little better. My piece just doesn’t feel Radioheadish.

Also, the contest seems to focus on the notion of Storyboards and Animations. That seems to be what they are looking for: a user-made Paranoid Android type video. Something with a story. Something with characters. Something with personality. And I am afraid my piece lacks in those three categories.

But still, I do like the piece and now I will discuss why I like it.

Firstly, its got some mad crazy super duper beat detection going on. I reused the application I wrote to make the Goldfrapp piece but went a few steps further. I manually input each bass beat, snare, highhat, and arpeggio note, not to mention all the vocals and syllable breaks. Crazy! It took about 6 hours but I think it was the right way to do it. I would have wasted much more time than that had I chosen to do the beat detection algorithmically. But man, scrubbing through that track, over and over, marking every note… it was a carpal pain.

Secondly, it is Processing from start to finish. There is no post processing (oooh, a literal pun!) or editing after the fact. I import the audio data from the analysis, augment it with the direct FFT data from the Sonia analysis, press play, and after it is done, I have the finished piece. This is both a plus and a minus.

The plus is that it kinda rocks to have a full video like this created with code. An unnecessary restriction really, but a bragging point for sure. The minus is that it highlights the weaknesses in my programming. Mainly, the camera object.

I wanted a more robust camera movement in the piece but just didn’t have time to figure it out properly. I played with attaching the camera to springs and changing the target programmatically, but the end result was rather jerky and very obviously springy. Ideally, it would have more of a handheld camera feel, but I just couldn’t quite get there.

Also, the flocking movement feels less organic than some flocking experiments I have done in the past and I plan on addressing this eventually.

I received some nice feedback from fellow Barbarian Andrew Bell and fellow SF friend Mike Creighton. Mike in particular had a big effect on the end result and many thanks to him for his ideas.

You can view the full 200MB Quicktime here.

Or you can watch the Vimeo version below. I recommend the Quicktime for now but once I render it out in HD, I will link to Vimeo HD version.

Weird Fishes: Arpeggi from flight404 on Vimeo.

UPDATE——————————————–
After reading all these wonderful comments from people telling me to submit the video, I relented and added my offering to the 700+ already submitted.
http://www.aniboom.com/Player.aspx?v=210097

FiTC 2008 Toronto has wrapped up. As I write this, I am on a plane somewhere over the square states. My dinner of slightly burned vegetarian ravioli is meeting up with the bloody mary appetizer already happily resting in my gut. Now that we are entering turbulent air, I am writing this post to distract me from the unfortunate swaying.

The flight from Toronto to Detroit, where I changed planes, was a bit sucky. As we were coming in for a landing, one got the distinct impression the pilot was drunk. Given the stereotype of pilot’s proclivities towards alcohol, this wasn’t a difficult thing to imagine. He even gunned the twin engines on the DC-9 a couple times while banking. Not reassuring at all.

We slammed into the runway. This was not a bumpy landing. This was a shocking BANG that caused overhead compartment doors to swing open. Gasps filled the compartment. As we pulled up to the jetway, the pilot got on the speaker and informed us that we should congratulate the co-pilot for not killing us on his very first landing. Should they, I thought angrily, please not test their skills with a plane filled with people who payed way too much for their tickets? Man, I hate flying.

And then there was the second leg from Detroit to San Francisco. The pilot warned us of some possible bumpy air. No biggie. But two hours in, a very exasperated sounding pilot came on the PA and said that ‘two cells have formed ahead of us and we are going to try to go around it. Please fasten your seat belts. I repeat, please fasten your seat belts’. Two things you never want to hear a pilot say. ‘Try’ and ‘I repeat’. Sigh.

But back to the point: FiTC was an entertaining romp. I had the good fortune of being the final speaker on the final day. As a fellow co-worker Andrew put it, ‘dude, you are the grand finale.’ It was really good to see my conference buddies again. Many thanks to Pucknell and his very capable staff for organizing another great conference.

As I mentioned a couple posts ago, FiTC is coming in latish April. FiTC is a technology and design conference that originated in Toronto, but has since expanded to other cities in the US and Europe. Originally Flash-focued, it has evolved into a more opened ended format highlighting all manner of multimedia.

I am particularly excited about this years FiTC. Many major influences in my coding style and design aesthetics will be speaking. Of course, the always impressive Erik Natzke will the there showcasing his unique blend of painterly sensibilities combined with a strong technical foundation. Beautiful stuff!

Also present is Mario Klingemann. I hadn’t seen Mario speak in a long while but had the pleasure of seeing him give a talk at Flash on the Beach last year. Such a bizarre blend of comic quirkiness and absurdly intelligent subject matter… Mario is unlike anyone I have ever met. So very humble and so goddamn smart.

New to the Flash conference scene this year is friend and coworker, Andrew Bell. What can I say, this man is a force to be reckoned with. Prior to joining Barbarian, he was doing motion graphics work for Method Studios in Los Angeles. He was looking for a change and we seemed to fit the bill. He works out of our New York office, but if I had my way, he would move to San Francisco and be my partner in crime. In his presentation, he will be talking about Flash, Processing, openframeworks, Python, Maya, and OpenGL shader language. Crazy! I have the pleasure of working with him every day, and I am still looking forward to his presentation. He has taught me a great deal in the short time he has been at Barbarian and I am glad to see him represent Barbarian in Toronto. Do check it out.

Also representing Barbarian is none other than Benjamin Palmer, the CEO of Barbarian Group. It was Ben’s brainchild to start up this little company of ours and we spent our first few months working out of his apartment in Boston. He will be speaking on a panel on the last day of FiTC.

So there you have it. Id mention each and every person I am looking forward to seeing but there are just too many. If you haven’t gotten your tickets yet, do it soon. Oh, and I have the pleasure of letting you all know that if you use the special discount code ‘flight404′, you can get 10% off any ticket. Go go go!

The April 2008 Seed Magazine is out. Hooray! Im excited both for the content, and the 4 full spreads that I did at their request. This issue profiles ‘7 revolutionary minds’, but the Seed Salon is dedicated to Benoit Mandelbrot. Seed Magazine asked me to provide some fractal images, specifically whole Buddhabrots. The Buddhabrot is an alternate way to render the more traditional Mandelbrot set. I first heard about Buddhabrots after seeing some versions that Jared Tarbell had produced using Processing.

The Buddhabrot is not that different from the Mandelbrot set, however doing any zooms of the Buddhabrot can be quite time consuming. After doing a bit of poking about, I found steckles.com where Alexander Boswell details how to implement a Metropolis-Hastings algorithm to dramatically speed up the render process when zooming in on a specific section of the Buddhabrot. In the end, this addition was not needed as whole Buddhabrots worked well in the Seed layout, but it was certainly an interesting mental exercise.

And say what you will about fractals, they still continue to impress me. Something so incredibly complex coming from such a small amount of code… what’s not to like?

Oh, and there is a nice image from Mr. Natzke and a great article about the Design and the Elastic Mind exhibit at the MoMA.

Southern California Institute of Architecture were great hosts. I had a really good time, despite being on the tail end of what I can only describe as the most insidious lung infection evar. Luckily, I had Chandler and Ben there to comfort me and put up with my constant whines of “its sooo hard to breathe”.

It was weird talking to architects. Up until now, my audiences have all been coders and designers at Flash-centric conferences. Even with the talk at UCLA in January, I was speaking to the Digital and Media Arts department so it was easy to assume the audience knew exactly what I was talking about. But with SCI-Arc, I kept wondering, “Why do they wanna hear from me? I envy architects! They actually make things… big things… so large you can walk inside of them.” But I guess they like code as much as the rest of us. It was fascinating to think about how new structures could be designing using some of the same processes I use to make a simple music visualizer. Perhaps a collaboration!

And heads up, Flash in the Can (now known as FiTC in much the same way Kentucky Fried Chicken is known as KFC… FiTC is about much more than Flash) is coming. Very soon! Check the website for more details. It should be fun and it will certainly be a treat to see the gang again. Hurry and buy some tickets, they wont be around much longer.

Living in a seismic hot spot has its pros and cons. My grandfather died from injuries he sustained during the last big quake in Kobe. My family is not immune to the effects of a trembling planetary shell. Perhaps this is part of the reason why they fascinate me so.

After moving to San Francisco, several months went by before I was able to experience my first trembler. Thats not to say I wasn’t around for the nearly hourly quakes. I just didn’t feel the first few hundred that rolled beneath my feet. They weren’t strong enough (or I wasn’t sensitive enough).

The first quake I felt was subtle, but rewarding. It was a 3.4 south of Berkeley if I remember correctly. I loved it! It was always strange to me that I could hope for something so violent, but with the catch that it shouldn’t be so intense that I lose valuables. And nobody should be injured, of course.

The view of the city from the top of my building is phenomenal. Its not uncommon for me to be up there late at night and invariably, my thoughts turn to how it would look if a huge shockwave rolled through the city from beyond downtown. Would I see the buildings sway before the shockwave hit me? Would the city lights go out before I felt anything? Would I see a ripple? What would it sound like?

This thinking led me to revisit a piece I started shortly after feeling that first quake. After Googling about, I came across the USGS recent earthquake site. It is the first bookmark in my Daily Visitations bookmark bar. And without fail, if I am near a computer when a quake hits, I bring up the USGS site and hit refresh repeatedly until the data shows up. I need to know how big the square is going to be. Thats all it comes down to. These horribly ominous red squares. The more area the square covers, the more lives are effected. (Also, my my, what happens with 8.0 or higher? Why is there no square preview for that? Is it because if an 8.0 or higher hits, the internet will go away?)

Sadly though, I cannot seem to find a system for getting the data in real time. Quick pokes about the intertubes has proved to me that services exist, but they cost thousand and thousands of dollars. Meh. Id use the Sudden Motion Sensor™ in my laptop, but that wouldn’t help me triangulate the data, not to mention the constant construction near my office would register a ton of false positives.

The current goal of this project is fairly nebulous. Right now I am content with exploring Earthquake-Driven Compositional Studies. The ultimate goal is to make earthquake responsive installations, but again, real-time data would be preferred. Although there is something conceptually sound about making an installation that only activates if a huge earthquake rumbles through. The one time you could see it in its true form is also the time where such aesthetic concerns take backseat to the flight response. Fun! On the flip side, how shitty would it be to make such a device and find that in the moment of Richter-based vigorously shaking truth, the thing malfunctions cause your code was wrong.

My creative process is very sculptural. Seeing as how I graduated with a degree in sculpture, this is no surprise. When I code, I keep adding and adding and adding until I reach a point where I start to get confused. Then I step back and look at the piece from all angles until I see some direction I would like to explore. Then I do a little clean up to eliminate the parts that don’t belong in the new direction, and then its back to adding.

With this in mind, I have revisited the first source release. I have chosen not to release something entirely different, instead opting to build on the foundation that the first source provided. I think it might be useful for people to see that I generally don’t build towards a specific goal. I just wander. Sometimes I wander down dead ends, but sometimes I find myself in places that I hadn’t imagined could exist. Man, I need more coffee. These code-metaphors are starting to get a little cheese.

So here it is, release 2.

Same deal as before but with a few extra features. As before, you can toggle the perlin noise, gravity, floor plane, and particle trail. The gravity and floor are now on by default.

‘P’ will toggle a Perlin Noise influence to the Particle velocity.
‘G’ will add a gravity influence to the Particle velocity.
‘F’ will toggle on an invisible floor allowing the Particles to bounce.
‘T’ will toggle the rendering of a Particle trail.

In addition, you can also turn on a basic smoke emitter and save out image sequences.

‘N’ will toggle the smoke effect (nebula).
‘S’ will toggle the saving out of images, one per loop.

Some features of this piece of source code:
• Basic camera controls using Kristian Damkjer’s OCD library. Right click and drag will reorient the camera.
• Added basic smoke effects.
• Added fake-lighting textures on the floor plane.
• Some simple depth testing to allow the floor plane to occlude the additive blended bits. I will probably expand on this in the next release because I have received a lot of comments about this particular process.
• Particles can now split if they hit the floor with enough force.
• Loaded images are now in the Images class. Organizational change more than a functional one.
• Saves out image sequences when the ’s’ key is pressed. Hit ’s’ again to turn of feature.

I must warn you this source release is not optimized to be processor friendly. If you leave the trails and smoke off, it can do okay. However, since the particles can split into even more particles, if you slam the emitter into the floor while holding down the left mouse button, you will create a fountain of particles that will multiply when they hit the floor and the frame rate will drop.

I could have limited the max particles the piece can have at once, but instead I will leave it as is. Maybe someone like Simon (cough) will attempt another shader version.

This source was a bit more rushed than the last one so it is not as well commented. If you are starting here and find yourself confused, I would recommend checking out pt. 1 first.

Click here to download the source code.

For this first release, I am showing how I go about making a generic particle emitter. I used Processing v.135 and Karsten Schmidt’s Vec3D library. It was developed on a MacBook Pro laptop, but this shouldn’t be a problem.

There is an emitter on screen which will follow your cursor position. When you click and hold the left mouse button, it will create particles with a randomized velocity and send them out into the world.

‘P’ will toggle a Perlin Noise influence to the Particle velocity.
‘G’ will add a gravity influence to the Particle velocity.
‘F’ will turn on an invisible floor allowing the Particles to bounce.
‘T’ will toggle the rendering of a Particle trail.

Some features of this piece of source code:
• Some example usage of Karsten’s Vec3D library.
• ArrayList to handle the variable number of particles.
• Location history used as a ribbon trail.
• OpenGL display lists and additive blending.

Click here to download the source code.

UPDATES———————————————————————
• February 11th, 2008: Implemented an OpenGL reorganization as per Simon Gelfius’ recommendation. Should improve performance a bit.