something in the way

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’ve seen the demos. You like the idea of tracking tags in the real world to create visuals. And now you want to try augmented reality for yourself - and, incidentally, you’re a Flash developer.

Reader Eric Socolofsky writes to share a framework he’s created that makes it much easier to work with the Flash-based, open source FLARToolkit, called FLARManager. Version 0.4 is just released:

http://words.transmote.com/wp/20090618/flarmanager-v04/

FLARManager has a number of features that improve upon the existing work done by FLARToolkit:

• Building the apps themselves is easier. Fire up the framework with Flex Builder (or Flash, or Eclipse, or FlashDevelop), and you have access to all the libraries you need, so you can start playing more or less out of the box. Hello, world, indeed.
• You don’t have to rely on Papervision if you don’t want to. Papervision, the faux-3D library for Flash, is included with the distribution. But marker tracking is decoupled from Papervision, so you don’t have to use it if you don’t need it.
• Better event management. Marker adding, updating, and removal, multiple pattern detection and management, and the like are all extended in FLARManager.
• Great documentation. Eric has taken the time to read some fantastic getting started tutorials, all accessible from the site above so you can go play.

Now, you wouldn’t pick Flash for speed - that’s not the idea.

This is about the slowest implementation of ARToolkit you’ll find. But you’d use it for compatibility, because of easy deployment to the browser. Speaking of speed, the NyARToolkit Java implementation actually outperforms the original C version. I’m the last person you should talk to about writing efficient, optimized code, but I can tell you that the notion that Java is “slower” than C is simply wrong. There are a great many other, more important variables, and in some cases Java can in fact outperform C. That doesn’t mean that Java is always the right tool for the job any more than C is, though, and in fact because Java’s Garbage Collector and event scheduling aren’t really built for real-time performance, and because “native” code is suited to certain situations, there are in fact times when you wouldn’t want to use Java. Understanding the application is what really matters - and that’s why it’s nice that NyARToolkit and siblings are available for AS3, C#, the mobile Android platform, iPhone, and others.

Eric doesn’t just do this to fool around, either; he works in interactive design for museums, and has what has to be one of the world’s sweetest “day jobs” - working for the legendary Exploratorium. He’s also working with Processing and the wonderful reacTIVision library on a separate project that’s working with tangible table-based interfaces; more on that separately. Thanks, Eric!

If you get interesting work in augmented reality going, let us know. And if you need some inspiration, my current favorite is from our friend Marco Tempest, working with Zach Lieberman in OpenFrameworks on augmented magic.