something in the way

For people coding for visuals, Processing just keeps getting better. And for people who aren’t … well, you might just want to give it a second look, as a growing global army of people who never fancied themselves coders suddenly start typing up new creations. A new release makes mobile development easier and corrects lots of bugs. But specifically of interest to readers here, powerful libraries for 3D help make Processing an intensive tool for creating visuals. With the aid of running of your GPU, they can also deliver eye-popping real-time performance not normally associated with Java.

Processing 1.5

In a surprise release, much of what’s coming in Processing 2.0 this summer is now available in a stable, general release of Processing 1.5. It lacks the new built-in renderer – OPENGL2 – but does incorporate new features for developing for Android and, via the third-party library GLGraphics, you get all sorts of new OpenGL goodies. (Note: Processing 1.5 = 0196. The previous pre-release version, 0195, is worth downloading if you want to play with the new OPENGL2 renderer and its examples. Both are on the download page, and they can be installed side-by-side.)

Most importantly, for anyone publishing to the Web, you need to download this version now and re-export sketches. Applets were seeming to run very slow in Chrome and Firefox 4. (While I vastly prefer the Java version for things like performance tools or installations, I also appreciate the Processing.js JavaScript fork for Web delivery – but this fix does make applets work pretty well.)

New to Processing 1.5:

• Tons of editor fixes in the PDE development environment
• An essential bug fix that corrects slow performance when exporting for the Web.
• Android development support – in preview builds, but now in a stable build. (I think this is still considered a pre-release feature, but it means you can run the stable build to try it out.) Now go make stuff for phones and tablets easily.

Processing 1.5 is a good start, but for me, the live visual workflow isn’t complete without two additional libraries, toxiclibs and GLGraphics. A new GLGraphics update improves integration with both toxiclibs and the new Processing release.

toxiclibs

toxiclibs represents over 270 classes in 7 libraries, some 25,000 lines of code, written by digital artist Karsten “toxi” Schmidt. There’s gobs of stuff in there. The most useful is a basic set of classes for things like geometries, meshes, and 3D vectors which you’d otherwise have to build from scratch, and which are generally built in fairly standard ways. With elegant math, Verlet physics, and color libraries, and wonderfully-usable API design, Karsten gives you all the essentials in a way that will inspire you to use them and make something truly original. (A full tour is probably a good subject for another post. Just ignore the toxi.audio packages; with the libpd crew, I’m working on something with Pd I think you’ll find more useful and stable.)

I had a discussion with one colleague who felt that, indeed, toxi’s libraries are so powerful that people are simply using it as a crutch. That may be true to an extent: people should prominently credit toxi’s work, and to do otherwise is plagiarism. But with proper credit, I feel that standing on the shoulders of someone else’s work can be a good thing. Digging through toxi’s libraries is like going to school for the sorts of math and geometry that you need to learn to understand 3D generation. For many of these classes, involving essential mathematics operations and 3D modeling, I’d have no idea where to start, would spend weeks or months writing something inefficient, and would come out with something that reinvented the wheel. A lot of the techniques themselves in those 27,000 lines of code weren’t developed by Karsten, either: it’s more like seeing the wisdom of a master teacher, assembled from a wide variety of sources and passed on.

In fact, this is a rant that I should probably invoke elsewhere, but to me received knowledge is the essence of any craft. Composers don’t invent new rules of harmony (well, at least, not tonal harmony). Engineers don’t work out the laws of physics from scratch each time they build something.

And most importantly, because all of this exists in code, you can read and modify anything you find. It’s a black box if you want it to be, but I very often dig directly into the code to understand how things work.

There’s a bunch of documentation and a showcase for great work:
http://toxiclibs.org/

GLGraphics

All of this, though, brings me to GLGraphics. As I’ve been saying for – gee, years now – GLGraphics is the future of Processing. Now, that’s come to pass: gifted developer Andres Colubri authored the new OPENGL2 renderer that is similarly based on native OpenGL calls, and now runs the Processing Android port and upcoming Processing 2.0.

GLGraphics is separate from OPENGL2, but it’s your best bet for work on the stable Processing 1.5 build. Version 0.95 adds compatibility for that latest release, and adds two essential other features:

• An example of how to integrate with toxiclibs
• GLSL shader support, which can in turn be used for complex mesh generation.

See yesterday’s blog post announcing the update:
Processing 1.5 / GLGraphics 0.95

And there should be still more coolness to talk about soon, at least for Mac users, with the availability of Syphon for Processing. Stay tuned on that.

I think I have to hide away in a hole and do nothing but code this weekend. Anyone want to hop on IRC or PiratePad and pass code snippets back and forth?

Pick up a pen and draw a sketch. There, that was easy – however crude, you can get out an idea. Sketching with paper is still the fastest way for most of us to imagine something. But between that immediacy and the end result, you need prototypes.

The Processing language has long been one of the easiest ways to sketch an idea in code – best after you’ve first put pen to paper, but as an immediate next step (and for ideas you just can’t draw). Built in Java, the creation of Ben Fry and Casey Reas and a broad community of free software makers, it runs on Mac, Windows, and Linux. Via Processing.js, the same API works in a browser via JavaScript. It has inspired the OpenFrameworks project, which uses nearly the same API. Those tools let you intermingle Java, JavaScript, and C++, as they’re written natively in those languages.

Processing now runs just as easily on a mobile platform with Android. You can try it with the free SDK and emulator, but it’s most fun with a device. Using all free software, you can sketch easily on mobile and desktop from one environment, and with only minor modifications, run the same code on a desktop, a browser, and a mobile device.

Translation: with one, elegant API, you can “sketch” visual ideas on screens from an Android phone to a browser to a projection or installation. As a prototyping tool, or for finished projects, that makes it an exceptional, expressive tool for making interactive visuals for screens.

This is a first-draft tutorial, as I make the same presentation in Stockholm at the info-rich Android Only conference. I’m eager to put it out there and find out that people have problems, as I can then improve the documentation. So do give it a try – especially if you’ve got (or can borrow) an Android phone.

Processing on Android performs all of the core functions of Processing on desktop – 2D and 3D visuals, data manipulation, images, and type – and you can mix in Android code using the standard Android APIs, right in the same project. Processing controls the screen on which it’s drawing, for now, but you can mix and match everything else, to support multi-touch, sensors, and even NDK code. (I’m using it with Pd for Android, with Pd doing sound and Processing doing visuals.)

I’m assuming basic familiarity with Processing, so if you haven’t tried it out yet, check out the excellent tutorials available online to get rolling.

Install Processing and the Android SDK

Definitely read the latest official instructions:
http://wiki.processing.org/w/Android

1. Download the latest pre-release version of Processing. Eventually, the standard Processing download will support Android automatically out of the box – very cool. The current stable version doesn’t yet have Android support, however, so for now, you’ll need the latest pre-release build, which includes all the code for the testing release of Processing for desktop and Android. I tested with 0190.

2. Download the Android SDK. For now, you do need to download the SDK for Android separately, which is an extra step – but at least it’s completely free, and runs on any OS. See:
developer.android.com (This step will eventually go away.)

You can put the SDK anywhere you want; just make a note of where you’ve installed it, as you’ll need to point Processing to that location later. Follow the instructions carefully on Google’s site. On Windows, you’ll need to download the USB driver. On Linux, you’ll want to read the complete Developing on a Device instructions, as there are a few short commands you have to enter at the command line because of the way Linux talks to USB devices.

Lastly, even though that SDK is a big download, you’re not done until you download additional components from Google. This allows a single recent version of the SDK – like the 2.2 SDK I tested – to support a variety of older versions for backwards compatibility.

I have Eclipse installed, because it’s a handy tool for developing Processing for desktop and Processing for Android on any OS. Once you’ve installed the Eclipse plug-in for the Android SDK, you can add components from inside Eclipse. Inside that IDE, choose Window > Android SDK and AVD Manager Manager and you’ll get a graphical interface for adding these components (pictured).

You can now also access the same interface from within Processing. Choose Android > Android SDK and AVD Manager.

For Processing 0190, you need the SDK Platform 2.1, API 7 and Google APIs by Google, Android API 7. (If you’re an Android developer, you’ll probably also select some other components here, as well.) Components are available under the Available Packages.

If for some reason you prefer to use the command line, head to the Windows, Mac, or Linux command line, and follow the commands in the Quick Start under the Android SDK download instructions.

3. Run Processing, and switch to Android Mode. Load the Processing IDE you just installed, and switch to Android Mode.

The first time you do this, you’ll need to direct Processing to your Android SDK. Choose the root directory of the SDK – the directory that contains “add-ons,” “docs,” “platforms,” “tools,” and the like.

4. Try running a sketch on the emulator. I’m compiling a set of simple sketches you can use with Android, but even many of the basic examples will work out of the box. For fun, you can try sketches like those found in the Examples > Basics folder and some of the other included Processing Examples. They don’t take into account varying screen resolutions, which is a cool feature of Processing for Android, but it’s still fun to watch them run.

It’s simple to run a sketch. Open the sketch you want, go to Android > Android Mode to enable Android Mode for the sketch, and then hit Run. Instead of opening in a window as desktop Processing sketches do, you’ll see an Android emulator appear.

Be prepared for the emulator to take … some … time. You’ll spend a long time looking at the load screen. When it does finally load and install, there may still be a delay as you stare at the main screen. You may have to hit run again. You may see error messages saying an application has become unresponsive – don’t worry about that; Android has a low threshold for applications timing out, so while the emulator is loading, just choose “wait.” And because the emulator defaults to a large screen size, it’ll also take up some room on-screen.

It’s just slow, painful, slow, and unreliable. Fortunately, running on the device is near-instantaneous and speedy, so beg or borrow access to one and try the next step.

5. Try running a sketch on a device (if you’ve got one). Running on the emulator is a pain, but running on a device is very quick – even quicker than you might imagine if you’ve come from a background on iOS. (Remember, you’re working with Java, not native code.)

In a clever design feature, to run on the device instead of the emulator, simply choose Present instead of Run. (The quickest way is simply to shift-click the play button.)

So long as you have a device connected with USB, and USB debugging is switched on, and you’ve done the setup correctly above, you’ll see your sketch appear on the device.

Now, that’s more like it.

“But, wait,” you say. “Android devices have all different screen sizes. Augh, fragmentation, fragmentation!”

Fret not: computers have different screen sizes. Projectors have different screen sizes. And Processing on Android can easily adapt to the size of the screen. We won’t need much Android-specific code, but let’s get started with our own Processing sketch and see how it works when you’re preparing for mobile.

Try Writing Some Code

Okay, so what does a Processing sketch for Android look like? Here’s a really simple example, just to show off basic drawing, managing different screen sizes, and simple (single) touch. (I’ll leave density for another day; multitouch and other touch events are also possible.)

float sw, sh, touchX, touchY;

void setup() {
  size(screenWidth, screenHeight, A2D);
  println(screenWidth);
  println(screenHeight);
  sw = screenWidth;
  sh = screenHeight;
}

void draw() {
  background(0);
  smooth();
  fill(255);
  noStroke();
  ellipse(sw/2, sh/2, sw/4, sw/4);
  noFill();
  stroke(255,0,0);
  strokeWeight(2);
  ellipse(touchX, touchY, sw/4, sw/4);
}

void mouseDragged() {
  touchX = mouseX;
  touchY = mouseY;
}

Two things to note, in particular:

size(screenWidth, screenHeight, A2D);

(Warning: don’t put variables in that size() command.)

Processing for Android will map the desktop renderer names to either A2D (for 2D graphics) or A3D (for 3D). (I’m using the Android names here, but the other names will work just fine.)

Also, since static pixel sizes don’t make sense on mobile platforms with different screens, you can substitute “screenWidth” or “screenHeight” and get dimensions from the device on which you’re running. (I just used “sw” and “sh” because they’e shorter, and then I can make everything else relative.)

void mouseDragged() {
  touchX = mouseX;
  touchY = mouseY;
}

Here’s the really cool part — touch input works exactly the same way as it does on Processing on a desktop, for relevant mouse commands (nothing involving these strange “buttons” of which you speak). mousePressed, mouseDragged, and mouseX and mouseY all work as expected, so long as you’re satisfied with simple, single touch and don’t need gestures, multitouch, and the like. Don’t be confused by my touchX and touchY variables — those are just to demonstrate that my circle only moves when it’s “dragged” — or your finger slides across the screen. What we have is the beginnings of a drawing app, which I’ll be expanding over coming tutorials.

Here’s the other cool thing: modifying only the references to screenWidth and screenHeight, and the renderer, I can run exactly the same code in Processing on the desktop, or even in Processing.js on a browser.

Tune in Next Time…

This is not a replacement for the official wiki documentation, so do read that, please.

In coming installments, I’ll share:
1. How to get Processing for Android working inside Eclipse. In short – it works. That makes adding Processing to an existing Android app easy. (Hoping to follow that up with gedit and Ant)
2. More advanced tricks for dealing with screen dimensions and touch.
3. Android-native snippets for connecting sensors.
4. How you can combine sound and visuals with Pd and Processing, both running on Pd.

Other things that are possible to do with Processing for Android (which I’ll cover):

• Use install custom or installed fonts
• Data visualization (just as on the desktop version – making this much easier on mobile than in the past)
• Touch events, relative motion, and key events
• Force a specific orientation
• Add security requirements to the manifest (for things like sensors), right from the PDE app – no need to edit a file or go to Eclipse

I also hope to take some notes on what happens here at Android Only.

Processing for Android is still in development, and this is pre-release software. So be prepared to encounter issues. That said, I want to refine this documentation, so please let me know if you encounter issues with my instructions.

Presentation slides

Here’s my presentation from Stockholm:

Share what you’re doing…

Noisepages registration is open again as we finish the site. Share what you’re doing, devices you’re testing, or other thoughts:
http://noisepages.com/groups/processing/forum/

Mobile games are on slower hardware, similar to later 90′s computers so native is a great way to go for 3d and 2d game development because of this limitation at the current time and well into the next few years.  Take this time to learn you some native gamedev. andengine isn’t native directly as it is Java based but compiled with the Dalvik JIT virtual machine. Another way to go native on Android is the Android NDK which allows C and C++.

• andengine download at google code
• andengine examples at google code
• andengine blog
• Mercurial repository at google code
• cocos2d-android port of cocos2d-iphone with BSD license
• rokon android is another BSD licensed android game engine

The engine also has extensions that can be easily added and some great ones exist already.

Kaleido Demo from Agnes Chang on Vimeo.

Part of the beauty of working with code is that it can refine the way you think, challenging you to make design ideas into systems. But what’s often a challenge for beginners – heck, sometimes even for experienced coders – is thinking through the ways in which component parts function and combine.

We’ve seen code systems and visual patching systems, but Kaleido is something a bit different: it uses visual diagrams to loosely reinforce ideas in the code. Because it’s not rigidly attached to the code, you can use it to sketch out thoughts. But if you like, you can also attach sections of code to color-coded modules and immediately jump to bits of code from the visual interface, combining some of the best of visual programming and textual programming.

Kaleido works with Processing, adding an extra, visual pane to the standard Processing IDE. It’s the work of the Design Ecology Group at the MIT Media Lab and a Masters’ Thesis for Agnes Chang.

The always-wonderful designplaygrounds covered the technology recently, found via Processing co-creator Casey Reas:
Kaleido

Getting Started with Kaleido

In my own teaching, I try to emphasize object-oriented coding as early as possible. For me, it most neatly and nearly approximates the way we intuitively think about conceptual problems in general. It helps to systematize design. I’m not entirely sure Kaleido would work perfectly for me in the object-oriented workflow, if only because it seems to assume blocks of code, linearly, define function, rather than inheriting the relationships you create in classes. In fact – speaking to more advanced coders for a moment – maybe there’s a chance to do a sort of UML-for-artists tool that feels more creative and less like a computer engineering project. And I still like using Eclipse. But I could see Kaleido being a lovely addition to the Processing sketchbook, even in my work; I’ll have to give it a try.

Oh yeah, and someone has to try porting it to a non-Mac environment. (That should be eminently doable, by the way.)

The Processing IDE is entirely extensible. If you’re interested in customizing the coding experience yourself, there’s a terrific how-to video by sojama (Andreas Schlegel), just posted, that shows you how. See also his excellent new tutorial for making libraries in Eclipse, too.

processing-tool-template setup from sojamo on Vimeo.

You’ll hear odd cynicism about people working on free software / open source projects. Something like, “well, harumph, it’s not as though a bunch of people will make this stuff in their free time.”

Not only are these folks wrong, but you can actually visualize the contributions to source trees – and the results look spectacularly hypnotic. It’s free software – the music video.

Okay, now, granted, I may get so mesmerized by the results that I’ll just spend time staring at that instead of getting actual work done, but – working too hard isn’t good for you, anyway. It’s an organic high, audiovisuals.

At top, Ryadh Amar sends in a visualization of the excellent, lightweight LXDE windowing environment for Linux. (Actually, I’m inspired to give LXDE a fresh install.) At bottom, a collage of various projects showing that these data visualizations can take on various identities. Gource can support just about any project repository, too: Git, Bazaar (popular on Ubuntu), and Mercurial (recently added to Google Code, incidentally) are available native, and CVS and SVN are available as third-party extensions for those of you kickin’ it oldskool and non-distributed. (Though, really, come join the 21st Century – it’s awesome.)

And Gource can visualize itself. Freaky. It’s all thanks to the ongoing awesomeness of OpenGL.

http://code.google.com/p/gource/

I’d love to see this added to project management so you’d have a sort of live, superb visual to inspire you to keep the code moving forward.

Who knew source code would turn out to be so visually inspiring? (Now I just need a new way of visualizing me writing bad code and then correcting and cleaning it up. I think it could be best represented as a set of stick figures getting stuck in quicksand and hitting each other over the head. Then there could be a big Smoke Monster that represented the Evil Force of Procrastination.)

But wait! There’s more! You can visualize web logs, too. (It works with Apache; I have to see if I can make it work with our nginx logs, as visualizers could actually be very beneficial with the kind of complex data you get in something like a web log):

Boards Interactive Magazine – Walkthrough from Theo Watson on Vimeo.

Augmented reality has inspired plenty of experiments, magazines included – some successful, some failing to get far beyond the gimmick. What’s nice about this work is that it introduces the concept of motion to the typically-static pages of print, and inspires readers to imagine a world beyond the bounds of the page. There’s also an elegant expression of the theme.

It’s all made with OpenFrameworks (again – yes, OF is one of the easiest ways to hook into augmented reality). And none other than Theo Watson was involved.

For the March 2010 issue of Boards Magazine, Emily Gobeille and I worked with Nexus Productions to develop an interactive cover experience called Rise and Fall. Here is a little preview of the experience.

You can download the software and the cover from: boardsmag.com/RiseAndFall

Update: Found out you can buy a copy of the magzine for $7 by emailing – BoardsCustomerCare@boardsmag.com . You can also download the cover as a pdf from the link above.

The project uses the Ferns library for tracking ( cvlab.epfl.ch/software/ferns/index.php ) and the whole project is open source released under the GPL v2.0 . Grab the source code here: boardsmag.com/RiseAndFall

Credits:

Digital Directors:
Emily Gobeille – zanyparade.com
Theo Watson – theowatson.com

Produced by:
Nexus Productions – nexusproductions.com

Sound Design:
MOST Original Soundtracks – m-ost.nl

Software:
Made with openFrameworks – openframeworks.cc
Using the Ferns library for tracking – cvlab.epfl.ch/software/ferns/index.php

Thanks to @wetterberg via Twitter for sending this our way.

Google’s open-source Android mobile platform runs on Java. Processing, the elegant coding language for visualization, art, and media, is built in Java. The marriage of the two, therefore, is one we’ve long been anticipating. Processing’s ability to focus on lightweight, portable implementation is a perfect match for the demands of mobile development. For artists and visualists wanting to make handheld devices and tablets more expressive, I have good news: it’s coming. While not fully implemented or ready for widespread testing yet, Processing is in active development on the platform.

Ben Fry, co-creator of Processing, has been hard at work making Processing run on Android. Interestingly, in some ways Android itself vindicates the direction Processing charted years ago. Google made their platform work based on open-source development tools. They removed parts of the Java platform that would have overwhelmed the limited processing power of handhelds – even as a handful of purist Java developers cried foul. Graphics focuses on lightweight 2D and OpenGL drawing output, much in the same way that Processing strips Java to its bare essentials.

Best of all, doing Processing development for Android promises the same streamlined, sketchbook-like production flow that Processing does on desktop. To create Android apps, you simply set Processing to “Android mode.” (Right now, you have to point to Google’s SDK, but that happens only once and may be removed in future versions.) Hit run, and your sketch launches in the Emulator. Plug in an Android device via USB, and it’ll run on your device. Soon, you should have one-click-export of apps in the way that you do Processing desktop apps.

This also suggests some great possibilities for cheap, handheld devices, installations, and reliable portable devices for visual performance. Sure, right now a lot of Android-powered devices require a phone contract and don’t output video, but a lot of devices slated for later this year are media devices with video output and tablets, too.

Processing for Android is an early work-in-progress. If you’re thinking about playing with it and you don’t know what you’re doing, or you have little patience for bugs and wrinkles, you should wait until the waters grow safer. Right now, the team working on testing the port is intended to be limited, although as someone testing it myself, I can say it’s already a lot of fun and holds a lot of promise for the future. OpenGL support is currently not available, but it’s coming – and I’ll say again, if you want to know what Processing’s 3D future looks like, check out the superb GLGraphics library. Anyone who thinks Processing can’t be fast, or do intensive GPU work, or mix HD video (okay, not on Android, but on desktop at least), check out this library. OpenCL should also be possible soon.

http://android.processing.org/

BIG, BIG disclaimers! Please don’t go testing Processing on Android assuming it’ll work out of the box – for the brave ONLY, at least for now. (That should change very, very soon, but I couldn’t keep the news under my hat any longer.) As the disclaimer says (hilariously):

Do not use this code while operating heavy equipment. Do not rely on this code for thesis or diploma work, as you will not graduate. Do not use this code if you’re prone to whining about incomplete software that you download for free.

A number of us have already begun talking about the possibility of adding libraries to connect Processing’s capabilities to Google’s own APIs for the phone, SMS, sensors, and so on. Sound and synthesis via external libraries should also be possible.

I think Processing for Android is the perfect complement to openFrameworks for native code on mobile platforms. Right now, OF has already been used for terrific work on the iPhone. It’s not quite as user-friendly as Processing for Android for a number of reasons, but it has Processing-derived syntax, aesthetics, and philosophy, and it’s also free and open. For a superb guide to developing on the iPhone with OF, plus some links:

http://www.openframeworks.cc/setup/iphone

OF does not appear to be a practical solution for Android development, not least because Android requires apps to be distributed as Java, and uses Java to talk to all the native APIs. But it’s a good option for some of these other devices, and you can run the two alongside one another in Eclipse if you like, more advanced users.

With OF on the iPhone (and presumably other native platforms in future – Nokia N900, anyone?), and Processing for Android, plus tools like Pd and SuperCollider for synthesis (more on that soon), there’s no reason not to go completely open with portable interactive art on mobile devices.

If the question is if Unity can do interactives as smooth and stylish as Flash I think you may soon find out.  Carlos Ulloa of Papervision 3D fame has kicked it up a notch in Unity 3D with this interactive very reminiscent of the Ford Focus demo that helped bring in Papervision 3D for flash in style. Gotta say though a mini is much better than a Ford Focus.

Flash is still the leader in web interactives and even marketing interactive 3d, Unity largely replaced Director and tools like it and high-end hardware rendered required interactives and games. This interactive by HelloEnjoy has loads of polygons, unity physics system, lighting, environment mapping, showroom cameras, reflection, skid decals, highly detailed mesh and more.  Just take a peek inside the vehicle and at the rims for the detail that is impossible with the 2000 poly limit of Flash 3D software rendered engines.

Web interactives this heavy aren’t doable in a non hardware rendered player like Flash.  Unity is looking to pretty much own this level of quality in a browser.  I don’t think I have seen another interactive looking this good with Unity 3D.

Unity still is lacking many features that Flash has in support of making interactives for the web such as webcam support, mic support, better video support, better gui system, html support (although flash barely) and a larger install base but Unity could easily take the high-end advertising market in addition to owning highly immersive games that need hardware rendering which it is already doing for web gaming.  It is 2010 soon, most computers have a decent video card.  Put them to use!

• Blog Post on the project
• View the project

Interface 27 from CyberPatrolUnit on Vimeo.

There has been a long tradition in live visuals and motion graphics, inherited from many other media, of maintaining a “secret sauce,” or the guarded formula of eleven herbs and spices. Ironically, for all you hear today “DIY” and “open source” in the same sentence, a lot of the motivation for doing something yourself has historically been doing something no one else can. Keep your secrets, and raise your value.

As our friend Bryant Place / CyberPatrolUnit sends over this latest set of live clips from a recent gig, and I browse through the comments, and reflect on the conversations I had last week at OFFF and during and following my own talk there, though, I’m struck.

The world has changed. First off, the Internet isn’t really about secrets. Your value is almost in direct proportion to how much you can share. Connections are forged through links of mutual exchange and good will. It’s not just about sharing your output or getting fans (the MySpace model), but sharing with a network of enthusiasts, and fellow artists. Those are the people from whom you often get real support (artistic, technical, and personal), gigs – and inspiration. (Even if you hate 8-bit music, that community is a really amazing model: their work to support each other and advocate for the whole subgenre has been I think the single biggest ingredient in their viral success.)

The visualist community increasingly itches not only to improve the quality of their own individual work, but everyone around them. A lot of us are in a battle for the future of this whole medium. Some parts of the world are devoid of live visuals, while others have mass-produced club visuals filling the nightlife.

Before I get carried away, the video itself is just the latest from the ongoing Interface 27 series. It employs a touch interface to control abstract visual pictures formed from streams of particles.

The reason I’m pulling back into the larger question is that these visuals are enabled by a library for Processing, a library we’ve seen here previously, developed by Memo Atken:

MSAFluid for processing (and Java)

If you’d rather use openFrameworks, there’s that version, too, as pictured below running blazingly fast:

ofxMSAFluid for openFrameworks

There’s even an ActionScript 3 port, in case you want to code Flash on the beach.

ofxMSAFluid for openFrameworks from Memo Akten on Vimeo.

So, why do I bring this up? Well, the work done on Processing (Ben Fry, Casey Reas, contributors like Karsten Schmidt, and others), on openFrameworks (Zachary Lieberman, Theo Watson, and their own team), and Memo’s own library, based in turn on many other libraries and implementations, was all a big risk.

It’s not an easy thing to put blood, sweat, and tears into open source. None of those people has exactly gotten rich in the process – not even via the ways you’re supposed to profit from open source, doing the lecture circuit and such. But on the other hand, we’re seeing things that would have been otherwise impossible.

And there’s artistic merit, too. Bryant’s work looks different than Memo’s. The library actually takes on a new life as it gets in someone else’s hands. Bryant actually just wrote me:

As for the Interface video - mention how cool it is that people like Memo post code for other VJ’s to tweak and use.  Mention "FaderTouch" - a 100buk touchscreen off ebay that "vjFader" programmed - using a rear projection onto a translucent screen/ touch sensor we were able to use processing in a very intuitive way.

I got the “mention” part down, I guess. ;)

The responsibility is partly ours to make all of this work: file bug reports, fix bugs if you can, document your work, properly credit the people making it, write documentation for projects, and so on. But it’s not hard to see an ideal start to happen:

1. Person x makes a library / framework.

2. Person y build on that library to make their own tool – and contributes it.

3. Artist uses the tool, gives back to the project, goes in a new direction.

4. More and better work spreads, the project grows, the medium grows, and the audience grows.

None of this happens automatically. We all have a lot more work to do. But having stood onstage in front of a few thousand people calling for just this, it’s nice to keep opening my inbox and seeing it happening. We’re seeing the first seeds planted for what could ultimately be a larger ecosystem. Now, I know there’s also a big gap left – Processing doesn’t have nearly enough contributors, bug squashers, or documenters, and it’s one of the biggest projects, so you can imagine what happens when you get upstream to libraries and the like.

Over the coming months, I think we’ll continue to look for opportunities to help structure some of that involvement and to explaining how you can contribute, too. Stay tuned.

In the meantime, go play with some particles.

For more on Bryant, here he is on his current activities:

- I just did Coachella with [Friend of CDM and contributor] Momo, and in the near future, will be heading to Detroit for http://www.myspace.com/detroitmusicfest

I’m not on the website, however, Kero.fm and Derek Michael - two people who essentially helped build the festival from the ground up 10 years ago - are booking me to play with various acts including CLP, Richard Devine, Drumcell, Busy P (which I did a solo VJ set with at Coachella) so I am super excited to be a part for the first time this year.

Here is a cool video from previous Interface 26:

After Detroit - Mutek.

http://www.mutek.org/

There are also some killer podcasts from past Mutek - http://www.mutek.org/podcast

I am going to meet artists, see the latest AV performances, attend workshops.

I’ll be at Mutek, too, so see you there.

Wish granted!

Think 3D in the browser will never catch on? Think again. The folks at Google Labs have built an incredible-looking 3D API called O3D. It does just about everything you want, and then some:

• It’s multi-platform: Mac + Windows + Linux.
• It can render to both OpenGL and DirectX render pipelines.
• You can write your own vertex and pixel shaders. You have to use O3D’s own language for doing this, but that actually enhances compatibility, as frustrated shader coders may already know. (See the FAQ)
• It’s a scene graph, so managing complex 3D scenes isn’t a chore.
• It has powerful built-in functions like viewports and pickers (plus custom pickers), so you can actually get something up and running in a reasonable time.
• It has an import workflow with COLLADA, an open standard for 3D assets (and which, incidentally, has support in Google’s own SketchUp).
• You code in JavaScript, using the powerful V8 engine (developed for Chrome).
• Gears lets you run offline.

There are already some complaints about “another standard,” but to me, putting together a whole package here and employing other, lower-level standards (JavaScript, COLLADA, OpenGL, DirectX) makes a lot of sense.

http://code.google.com/apis/o3d/

I expect the folks working on Java and JavaFX are busy thinking about the fact that Sun just got bought by Oracle – something I’m hopeful, at least, ensures Sun’s future and is ultimately a good thing. But I hope someone on those teams is starting to get the message: 3D isn’t just something that’d be “nice to have.” It’s essential. And while even most developers likely don’t have a clue about things like custom shaders, having access to customize the graphics pipeline is likewise something ultimately benefits all developers – even if they just wind up relying on someone else’s code. I really do hope this is a priority with the coming development of Java and JavaFX, which could have the power to do these sorts of things. (Heck, Java could even benefit from the code Google just posted.)

On the proprietary side, this to me is a big blow to Microsoft’s WPF and Silverlight and Adobe’s Director. Unlike those products, O3D looks simple, powerful, flexible, open source, and directly programmable with JavaScript.

That’s not to say there aren’t some questions here – and the Java/JavaFX comparison is especially relevant:

• Another plug-in: You do have to install a plug-in to work with O3D, something that actually isn’t necessary with JavaFX (when it finally does 3D) or right now with JOGL and Java3D.
• Mobile, or just desktop? My big question I have is what this means for mobile. I’d love to have O3D work with OpenGL ES on, say, Google’s own Android platform.
• Not Just JavaScript? It would be nice if eventually you could use other languages like Java to program O3D.
• Sound? Oh, yeah, that. 3D sound is an ideal complement to this sort of scene, and the browser may be a bit constrained in that respect. I’m curious whether O3D might eventually include an audio API. (And yes, that’s where something like Director is still unparalleled.)
• Making it actually work: Okay, there’s also the fact that I haven’t successfully installed it just yet. Working on that.

(I’ll try to get answers to those questions.)

Oh yeah, and then there are details like the necessity to write your own custom shaders just to add more than one light to a scene – I think this will initially appeal only to folks with some real 3D experience.

But am I excited? Ohhhhh, yes, indeed. O3D itself looks fantastic, and I think this is a sign that 3D times ahead are going to be really fantastic.

And as long as you have the plug-in working and a browser in full-screen mode, you could literally set up an O3D project as a performance / installation tool. O3D visualists? Absolutely. Enjoy.