Archive for July 2012
Phew! Been very busy around here. The Holofunk Jam, mentioned last post, went very well — met a few talented local loopers who gave me invaluable hands-on advice. Demoed to the Kinect for Windows team and got some good feedback there. My sister has requested a Holofunk performance at her wedding in Boston near the end of August, and before that, the Microsoft Garage team has twisted my arm to give another public demo on August 16th. Plus I had my tenth wedding anniversary with my wife last weekend. Life is full, full, FULL! And I’m in no way whatsoever complaining.
Time To Put Up, Or Else To Shut Up
One piece of feedback I’ve gotten consistently is that darn near everyone is skeptical that this thing can really be useful for full-on performance. “It’s a fun Kinect-y toy,” many say, “but it needs a lot of work before you can take it on stage.” This is emerging as the central challenge of this project: can I get it to the point where I can credibly rock a room with it? If I personally can’t use it to funk out in an undeniable and audience-connected manner, it’s for damn sure no one else will be able to either.
So it’s time to focus on performance features for the software, and improved beatboxing and looping skills for me!
The number one performance feature it needs is dual monitor support. Right now, when you’re using Holofunk, you’re facing a screen on which your image is projected. The Kinect is under the screen, facing you, and the screen shows what the Kinect sees.
This is standard Kinect videogame setup — you are effectively looking at your mirrored video image, which moves as you do. It’s great… if you’re the only one playing.
But if you have an audience, then the audience is looking at your back, and you’re all (you and the audience) looking at the projected screen.
Like this — and BEHOLD MY PROGRAMMER ART!
No solo performer wants their back to the audience.
So what I need is dual screen support. I should be able to have Holofunk on my laptop. I face the audience; the laptop is between me and the audience, facing me; I’m watching the laptop screen and Holofunking on it. The Kinect is sitting by the laptop, and the laptop is putting out a mirror-reversed image for the projection screen behind me, which the audience is watching.
With that setup, I can make eye contact with the audience while still driving Holofunk, and the audience can still see what I’m doing with Holofunk.
So, that’s the number one feature… probably the only major feature I’ll be adding before next month’s demos.
The question is, how?
XNA No More
Right now Holofunk uses the XNA C# graphics library from Microsoft. Problem is, this seems defunct; it is stuck on DirectX 9 (a several-year-old graphics API at this point), and there is no indication it will ever be made available for Windows 8 Metro.
I looked into porting Holofunk to C++. It was terrifying. I’ll be sticking with C#, thanks. But not only is XNA a dead end, it doesn’t support multiple displays! You get only one game window.
In a nutshell: SlimDX has been around for longer, and has significantly better documentation. SharpDX is more up-to-date (it already has Windows 8 support, unlike SlimDX), and is “closer to the metal” (it’s more consistently generated directly from the DirectX C++ API definitions).
As always in the open source world, one of the first things to check — beyond “do the samples compile?” and “is there any API documentation?” — is how many commits have been made recently to the projects’ source trees.
In the SlimDX case, there was a flurry of activity back in March, and since then there has been very little activity at all. In the SharpDX case, the developer is an animal and is frenetically committing almost every day.
SharpDX’s most recent release is from last month. SlimDX’s is from January.
Finally, I found this thread about possible directions for SlimDX 2, and it doesn’t seem that anyone is actively carrying the torch.
So, SharpDX wins from a support perspective. The problem for me is, it looks like a lot of DirectX boilerplate compared to XNA.
I just, though, turned up a reference to this other project ANX — an XNA-compatible API wrapper around SharpDX. That looks just about perfect for me. So I will be investigating ANX on top of SharpDX first; if that falls through, I’ll go just with SharpDX alone.
This is daunting simply because it’s always a bit of a drag to switch to a new framework — they all have learning curves, and XNA’s was easy, but SharpDX’s won’t be. So I have to psych myself up for it a bit. The good news, though, is once I have a more modern API under the hood, I can start doing crazy things like realtime video recording and video texture playback… that’s a 2013 feature at the earliest, by the way 🙂