visp Interface Screenshot and Features Overview

visp VJ Software Interface+ view (very) large image

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.

  • http://abstrakt.vade.info vade

    Hey Mike. Looks lovely. I look forward to a release. It sounds like VISP will be completely open source? Hows performance with Apollo? Whats the max output resolution?

    Great work, it looks lovely!

  • http://www.mikecreighton.com Mike Creighton

    Yes, visp will be completely opensource. That’s actually something great about Adobe’s products right now: you can download the Flex 2.0 SDK and the Apollo SDK and have all you need to compile the code on both Windows and OS X. And the MIDI support is done through a small Processing applet that is all opensource as well.

    As for performance: there are a couple things that need to be optimized. That tempo tapper feature adds a lot of processing overhead. I think my code is bad; it was pretty rushed. Running a ton of vector-based animation slows things down on the Mac side, and it seems the cacheAsBitmap property breaks when used inside of visp right now. I’m not sure if that’s an Apollo issue or an issue with my code. Being able to turn that on would speed up that type of display data. But, overall, I’m generally able to maintain something between 24 and 30 FPS with at least one filter being applied to the output. I’m running it on a Macbook Pro Core 2 Duo, 2.33GHz.

    Max resolution: 640×480. That’s not to say it couldn’t be higher (i.e. up-scaling a base 640×480 image). And that’s not to say you couldn’t actually start with a higher-res base image. But there’s a processor hit when the Flash player scales down a bitmap — which would happen in the preview output area. And I haven’t actually tried anything higher than 640×480. I have a feeling that unless you’ve got a fast computer, you’d see a significant performance hit going up to 800×600 or 1024×768.

    In the end, while the new Flash player is significantly faster than the older version, it’s still not amazingly fast. However, I was able to bring the visual ideas I had to life with no problems.

  • http://www.freejays.be Jonas

    Can’t wait for it to come out, I’m very excited about this project. Is there any way for us enthusiasts to try a beta version? I must admit, I’m a sample-kind-of-veejay but very interested in generative/realtime/interactive works/intallation. I started toying in processing and vvvv recently but got stuck way too early in the process.

    Kind regards.

  • BirdFLU

    I’ve been doing music on computers for years and have recently been looking for “the” visual app for me. I see lots of things that are okay, but there’s always some niggle that keeps me from staying with the software. I’m not even a visual performer and I totally understand your list of gripes because they’re mostly the same as mine. I’m anxious to see what you’ve come up with.

  • http://www.onyx-vj.com Daniel Hai

    Hey Mike, this is Dan over at Onyx-VJ. Glad to see someone else doing next gen stuff. Can’t wait to see what you got cooked up (maybe we can contribute to your project and vise versa)

    Also, I think it’s funny that I work for adbe (on certain unnamed projects) with Odopod on that same unnamed project. Can’t wait to see what you got cooked up …

    - Daniel Hai

  • http://www.mikecreighton.com Mike Creighton

    @Jonas: Enthusiasts and everyone will be able to try this thing out hopefully after Memorial Day weekend. That’s when I’m going to attempt to migrate my SVN repository over to a Google Code repository. I’ll have a nice long list of things that do and don’t work — and leave it all up to the community to change / implement / remove as they care to. I’m toying with the idea of making the SVN read and write capable for anyone who asks, since I think that I’m going to move onto other projects.

    @BirdFLU: Like I said in the post, I’m not totally sure that I actually came up with what I intended. I think a common trait of software development is the simple desire to wedge features in (where they aren’t necessarily needed) because the developer thinks they might be useful. So, before I post this to the public, I’m going to actually strip away features since there were definitely things that weren’t useful at all.

    @Daniel: I actually spent a lot of time analyzing Onyx-VJ, specifically how you dealt with the general render stack, tempo manager, filters, etc. Then after seeing how much thought and work was put into Onyx’s architecture, I realized that I needed to focus on rapid development / getting the prototype done and working (I had an event driving a deadline). So more thinking re: standardized approaches / design patterns in visp’s architecture definitely needs to be done. However, since I did start from the get-go developing within the Apollo / Flex environment, I think that perhaps my efforts might prove useful as you start to move forward with the Apollo version of Onyx. Obviously there will be drastic difference with approach from a UI perspective since you’ve gone pure AS3 on Onyx.

  • http://morphvisual.com MoRpH

    Looks very promising, will be very interesting to take it out for a spin as I’m very interested like Jonas in moving into some more generative visuals with flash.

    “Deliver us from darkness” – VJ 26:18

  • http://www.slipdraft.com Sam

    This looks good. Sounds like you’ve got the right idea.

    I absolutely agree with your gripes, especially on the UI and true cross platform support. My favourite visual app is Resolume, mainly because of the UI, but I always wished it could be ported to Mac. I assume that it would be more stable on a mac. I never found any program with a UI that good on a Mac.

    The only cross platform app that I can think of is Arkaos, and I hate it for all the reasons listed in your article.

    Open source is also great, so long as it doesn’t affect the stability.

    So yeah, good luck with the project.

  • http://www.slipdraft.com Sam

    Just to backtrack there, Oinx in a great cross platform app. I had completely overlooked it, but having just messed around with it, I’m really impressed.

  • http://allanwhite.net/ Allan W.

    Very, very cool stuff – I’ll be watching. I hadn’t heard of Onyx, I’ll have a look.

  • http://allanwhite.net/ Allan W.

    Mike – a question popped in my head. I was a flash dev for a long time, though a lousy programmer. I have an idea for an app in my head/sketchbook, that I wonder if Apollo might be a useful toolset to approach a solution.

    Basically it’s a better Media Shout with a decent interface: an app that lets me put videos in a queue, play them, but set loop points and do basic overlays (announcments, etc.). Something that would give me decent video performance (I don’t even need to composite two, though crossfading would be nice). I see a work-table-like environment for zooming in & out of the “show” with expandable “mini-shows” within, and a “live” and “next/preview” monitors.

    Media Shout _works_, but man it’s ugly and the UI is not very user-friendly. After my last event, I can’t get this vision out of my head. Any thoughts, anyone? Thanks!

  • http://www.dailymotion.com/defektv thomas

    looks very promising!
    could you let me know by email when you release it?

    cheers!

  • http://www.onyx-vj.com Daniel Hai

    Man, I love the look Mike.

    I did build Onyx as an Apollo app way back — (changing the root .mxml to an .as file will still work). I was having other problems getting the plugins to be recognized, Apollo doesn’t seem to recognize interfaces made by the normal mxmlc compiler. I’ll probably circle back after a version with that bug is fixed.

    We should do lunch? I think we were supposed to have lunch with some of the odopod folks at some point anyways.