+ View large.

+ View large.

Lots of new stuff learned over the weekend. Here’s a summary:

• Really understand basic OpenGL lighting now.
• Understand how to do basic material coloring now.
• Learned how to texture a quad!
• Starting to learn some things about the Boost C++ libraries.
• Finally remembered that OpenGL is a state machine.

I think I actually (finally) have enough know-how to execute what I’ve got going on in my head. It’s going to require some refactoring of code, but I don’t feel like I’m up against an unclimbable wall anymore, which is precisely how I felt by the end of the day on Sunday.

I still think this looks boring / uninteresting, but it’s just another step closer and a lot of lessons learned.

Here’s a video render of what it looks like in realtime:

Update on 04-29-2010: The C++ framework that I’m using has just been released to the public. It’s called Cinder. Big ups to Andrew Bell, Robert Hodgin, and The Barbarian Group for all the time and effort put into releasing such a powerful and fun open source framework for creative coding!

Everyone, I’m caught up in a project at work that’s forcing me to put a hold on the release of this software. However, I realize I need to put out some proof that this thing exists. So, above is a screen cap from the software I’ve entitled visp.

And I want it to be no secret that the title comes from these words: visual performer. I also want to say that this software was designed as a prototype for a personal proof-of-concept; it isn’t intended to be software that’s supported or salable. And I actually haven’t taken the time to reflect on whether or not my concept was proved as a result of its development. Anyway, enough jibber jabber. Here’s why I built visp along with a general list of its features.

The Reason(s)

Too much UI management. That’s why I hate VJ software. More often than not, VJ software gets you sucked into managing the UI during your performance rather than putting the emphasis on performing. That’s something I never really understood. I always wanted to be gestural with my performance. I wanted to be able to physically say, “Now I want the visuals to blow up.” or “Now let’s start highlighting this sound.” Instead, I found myself using the keyboard and mouse to manage some UI element, forcing me to miss those precious cues. Granted, yes, I could use some sort of controller (MIDI or OSC or something hacked together). But that leads me to my next irk.

Too much focus on clip triggering. I don’t think like this. I’ve got an interactive media background. I think in dynamics. I think in variables and rule sets. I don’t think in terms of linear media (generally). Almost all the software out there has this huge focus on layering video clips and that’s just not for me. So, yes, while I can gesturally trigger clips using some sort of controller, adjusting layer opacities and filters using sliders, I’m still limited to the linear pre-rendered footage in my library. And it just doesn’t suit my tastes. So, you may ask, why not use something programmatic like Processing or Max/MSP/Jitter or Touch?

Maintaining visual continuity is so difficult. In a lot of these other software environments, you can build very beautiful, very dynamic, and very interactive visuals. However, moving from one visual construct to another is no simple task. There’s no “meta” application that really lets you string these pieces together in a unified environment (unless you build it yourself). I started off actually doing just that for Processing applets but was instantly thwarted due to a bug in the latest build. Fortunately, I had access to Adobe’s new desktop platform, codenamed Apollo.

The Solution

Apollo came at just the right time. I could leverage my abundant Flash / ActionScript kung-fu. I could develop a standalone desktop application (that gave me access to native OS windows). And I could leverage the very easy-to-use Flex paradigm of application development. The Flash 9 Player was miles ahead of the Flash 8 Player, so I thought I’d take her for a spin.

Also, I wanted as much of a hands-off-the-keyboard-and-mouse experience as possible. I need to evaluate still where I’ve succeeded and where I’ve failed. Frankly, right now if you don’t have a MIDI controller, this thing is useless.

The Features

I’m just going to list these off in no particular order and with no real explanation. That’ll all come when it gets released.

• Support for development of your own “Modules” that essentially give you a Flash canvas to play in and do whatever your heart desires
• Module browser using thumbnails you make yourself
• Full MIDI support using an external, standalone Java applet (also opensource)
• 6 slider-like MIDI inputs for use in your own custom “Modules”
• 4 velocity-aware button-like MIDI inputs for use in your own custom “Modules”
• Support for transitioning between Modules (using built-in Transitions). You choose the duration and the transition effect.
• Change the stage’s background color (wow)
• Two active filters can be going at a time, with up to three MIDI assignable sliders – and a UI interface that you build yourself
• Output your visuals in a separate, chrome-less window of 320×240 or 640×480 resolution (thank you Apollo team)
• Real-time 640×480 preview screen
• BPM Tempo Tapper for assigning some beat-driven automation to the input sliders and buttons. It’s not audio-driven but VJ-driven. You gotta tap the tempo yourself.
• FPS (frames per second) display
• OS X and Windows compatible — seriously — I’m actually able to jump back and forth with the same codebase and same modules without any hiccups or platform-specific code!
• It’s internet aware – that’s the beauty of Apollo.

That’s all I’m going to say about this thing for now. But feel free to post questions. I’ll be happy to answer them.

And thus we have some real-time video output. So, what I’m working on right now is a fairly versatile piece of content that still needs a bit more pushing. But I think I can pretty much sign this one off as finished.

This would be the second video from a second capture session.

And finally the third video captured this evening from that second session. Forgive me for not elaborating more, but it’s kind of late. If you’ve got questions, I’ll follow up with answers. And for the record, I will be releasing this VJ software as open-source, cross-platform software and I will be doing a run-through of its functionality and features.

You can expect that after April 28th, as I’m doing all of this for two upcoming gigs. After the 28th, I’ll be free to focus on cleaning up the code, documenting it (better), and shooting some video to show what this software does (from an interface perspective).

One thing I will note is that pretty much all motion is controlled by hand in these clips via a MIDI controller. And I’m not showing off all that this particular piece of content can do (gotta save something for the night).

I’m not going to go into too much explanation just yet. This is just a hint of what might be to come. And I’ll post some source code so that you too can do this with your favorite video clips.