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/

“The hills are alive /
with the sound of browsers”

Ever thought you’d make sounds in a browser, or have new ways of visualizing music playback? It’s happening, with builds of Firefox anyone can download.

Work to make browsers rich with sound synthesis and visualization continues. “Compatibility” isn’t really an advantage yet, because Firefox is the only browser with support, and only in the next version, though that could change in the future. And yes, Flash is capable of some of this, too (though not real 3D), with 90-95% saturation, conservatively, of computers. But if not compatibility, what these experiments do represent is what happens when someone working on a tool (Firefox, in this case) really commits to making sound a priority, and supporting free standards and developer tools (an emerging standard API, WebGL, Processing.js, etc.).

In fact, it’d be great if this occurred everywhere: if you’re making a platform, make sound a priority, and people will do mind-blowing stuff with your platform.

Among the latest fruits:

1. 3D eye candy. Charles Cliffe has a psychedelic visualization of sound playback. The JavaScript nuts are also proceeding to do more things with their language than most would deem possible, even moving DSP calculations to JavaScript code. I remain a bit skeptical there: the question to me isn’t whether JavaScript is “fast enough,” but whether native code is faster or simply the better tool for some jobs. Details below.

2. Patching in a browser – with a Pd clone. Chris McCormick is porting a subset of basic Pd objects to the browser. Now, one side of me wonders whether Pd is the best choice; it’s a somewhat idiosyncratic, if powerful, language for describing sound patching. But on the other hand, I could see this being fantastic in teaching and sharing: put basic patches up in a browser, let people play with them live, then build more advanced tools (with greater hardware access and external support than is possible in a browse) in the traditional Pd tool. As I keep saying, I think there’s far too much partisanship in the discussion (“Browsers for everything!” / “Browsers are useless!”), far too little thinking about how the browser and the desktop tool are more powerful together.

Web Audio Data API – Pure Data and Processing.js from David Humphrey on Vimeo.

Check out:
mccormick.cx/dev/webpd/
wiki.mozilla.org/Audio_Data_API

Also — heck, I may try this out in workshops as soon as next week. The browser could build a basic language for music and visuals in Processing and Pd, then robust performance tools could be built in the native tools, with quite a lot of compatibility between the two.

3. Actual standards. The W3C, the standards body behind HTML, has added this discussion to an Audio Incubator group. (It’s been incubating for some time, but maybe this will help something actually hatch.) Now I’d just like to see these things in Chrome/Chromium, too – I wonder if anyone’s up to a test build, as the standards adoption discussion continues. A number of readers have pointed out that MPEG4 had a specification that included, wholesale evidently, Csound. But this process seems more organic to me – you need actual tools and real-world experiments to evaluate the validity of something, not just standards on paper.

Putting the Awesomeness in Context: An Appeal

A side rant, though: why do Web geeks only care about what happens in the browser? It’s funny to me it seems that outlets like Slashdot jump on stories like browser-based tools, but ignore exactly the same ideas if they’re in a separate app. That’s not a criticism of the Mozilla crew or these brilliant hackers – this is what development is all about, pushing your tools to the limits. But if there isn’t a broader recognition of the value of what you’re doing or why you’re doing it in the first place, there’s a danger that unsustainable tool fetish will miss the point. That is, synthesis in the browser is excellent, but if people don’t understand the value of the synthesis itself, we have a lot more work to do.

Even the tools themselves need a context. It also JavaScript is amazing, but so are tools in Python, Java, Scala, and so on… and some of the enduring power of C still shows here. Browser powers are cool, but the OS is just as important – performance of Firefox would be heavily dependent on support for OS-native, low-latency audio outputs, like JACK on Linux. (Yes, it’s open source, so you can go do it yourself. No, I have no idea how to build Firefox for JACK – maybe a reader does?)

I’ve still yet to see a compelling explanation of what the browser really is, and what’s possible with its interface paradigm. That should be a fascinating discussion, actually, especially with the radical transformation of the browser, particularly as players like Google make it the central aspect of TV-watching or tablet experiences. But the discussion is only really interesting if you don’t start out with the value as a given. For instance, if browsers become a bigger part of what we do, is its simplistic tab metaphor really sufficient? If browsers simply bundle a set of native tools, are there ways “standalone” apps might adopt similar, standards-based approaches?

David Humphrey argues that part of the value here is the view source concept, but the Web has had the same empowering influence on sharing, collaboration, and reuse with platforms other than just JavaScript. The browser itself is a largely misunderstood piece of technology, partly because users (understandably) focus on their experience, and doesn’t pay attention to which aspects are delivered by the browser, the OS, or some other piece of code.

Oh, side note: this isn’t about “the cloud.” The cool stuff here is happening on your local hardware, period. That’s what makes it fast, and that’s what makes it work for audio, and your local machine is getting cheaper, cooler, and less power-hungry all the time. New DSP and floating-point capabilities in devices like tablets could make sound more powerful and flexible than ever before – provided people work out how to maximize, not squander, those capabilities.

So, here’s what I’d like to ask: what form will the standards discussion take? And how can these larger discussions – many of which transcend the discussion of any one tool or standard – find a forum?

Behind the Scenes, More Info

While you ponder that (and I’m open to suggestions), here’s more reading for you:
Experiments with audio, part X [Dave Humphrey's increasingly-awesome blog]

Previously:
Real Sound Synthesis, Now in the Browser; Possible New Standard?

More details on the first example, and how it was built (Minefield is Firefox 3.7):

All runs in real-time with Javascript, WebGL and HTML5 only (uses Minefield Audio build) — no browser plugins are used.

This demo combines the CubicVR 3D engine on WebGL (www.cubicvr.org) with the Mozilla HTML5 Audio API (hacks.mozilla.org), Processing.js (www.processingjs.org) and BeatDetektor.js (www.beatdetektor.com)

Mozilla Audio API is used to sample the HTML5 audio tag on the page, this information is processed by BeatDetektor.js which produces timing information for the Processing.js real-time canvas textures and the CubicVR.js procedurally generated WebGL scene using them.

The camera is set to free roam a simple chase pattern with a probability to follow a nearby cube (fully automated).

Available online at:

http://cubicvr.org/CubicVR.js/bd3/BeatDetektor3HD.html

or if you have a Float32Array enabled Minefield build:

http://cubicvr.org/CubicVR.js/bd3/Bea…

you can find more info about audio api-enabled Minefield builds at:

https://wiki.mozilla.org/Audio_Data_API

You can also feel free to chat with us about the Audio API via the #audio channel on irc.mozilla.org

Enjoy! And yes, I’ll have to work out a more beginner-friendly, here’s how to do this post.

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.

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.

You’ve likely seen impressive sequenced Christmas lights in videos before. Very often, though, these setups use proprietary systems. Here, Processing makes it quick and easy to code lighting effects in a friendly, open-source environment. And, naturally, if you think you might want to do something like this and don’t want to wait for Christmas 2009, I can imagine quite a few other interesting lighting applications.Creator Jack Kern describes the project:

This is my first attempt at a computer controlled light show for our Christmas lights. Everything was DIY including the software which I wrote in Processing (processing.org). Simple wiring using parallel port output to switch some 120v relays. Only 8 channels, 1500w per channel max. Next year I’ll be trying for many more, dimmable, LED’s and DMX control of our RGY lasers!

It’s worth checking out Jack Kern’s projects page for other goodness. Think Java-based games (2D mobile and 3D desktop), a ray tracer, and source C/C++ code. And yet the man still has hobbies.

Big thanks to TJ Pallas on Facebook for the tip. And please, I do actually enjoy keeping in touch with readers on Facebook. (See my page / profile / CDM’s fan page.)

All is quiet as this week folks celebrate Christmas and Hanukah. But this is a quick note to say that we won’t be waiting until the ball drops to jump start one New Year’s Resolution a lot of readers have: learning Processing, the artist-friendly, multimedia-savvy, open-source coding platform. We’ll be kicking off a series of tutorials on Processing (and Java and related technologies) starting all next week. And for those of you who already know Processing, just substitute “get  even better at Processing” in the previous paragraph.

If you have other tutorial requests for ‘09 (vvvv, perhaps) or tutorials you’ve put together you’d like us to link to, do give us a shout. I’ll be editing through the weekend, so see you Monday!