During the high-definition wars, your feelings about new higher-capacity storage discs may have ranged from ambivalence to dread to simple disinterest. (Well, that’s how I felt, anyway.) But with Blu-ray triumphant comes this realization: "hey, brain, we’ve suddenly got increasingly-affordable ways of burning high-capacity media!" Drive upgrades on the PC side cost what DVD burners once did, and if you’re hooked up to a TV, the writer can be your player, too. (There’s already a Lite-On internal drive for around US$350, and I expect these prices will plummet as production ramps up.)

That’s burning, anyway — authoring is obviously essential.

It’s still early in development (read: it often crashes), but The Bean Machine applies nodal, patch-based development to Java. The interface is mysteriously close to Quartz Composer, down to capabilities, UI, and even the 3D cube tutorial. Personally, I use Java because it can do things Quartz Composer can’t, but it’s interesting nonetheless — and raises, again, the question of why we don’t see more tools that try to meld the capabilities of code and patches.

The cool bit: nodes are Java Beans, so you really could use this to combine the best of both worlds if it matures. No download yet, but we’ll be watching … perhaps it will inspire other developers, as well.

The project is labeled “experimental”, but could be worth a look. Developer Jerry Huxtable has lots of other goodies for Java-heads on his page, including lots of 2D image processing stuff and a map editor — Processing lovers, might want to pop this into your del.icio.us.

Bean Machine @ JH Labs

JH Labs main page with lots o’ projects

Attention, vector math fans! Wait … stop. That’s a terrible lead. Let me try again.

Open source advocates, your attention, please! Okay, slightly better.

Anyway, Java3D, the fully object-oriented Java API to 3D visuals, is now fully open source. That actually is big news to vector math coder types, because the vector math packages are now all modifiable if you like. For visualists, the news is that even the relatively sophisticated portions of Java are going fully open — including, in this case, a key 3D component for the ubiquitous taste sensation Processing I keep talking about ad infinitum.

Much as Cat Stevens became Yusuf Islam and Lesley Hornby became Twiggy, Java3D won’t be called Java3D any more. Since 3D graphics programmers excel at marketing, it’ll instead be called “3D Graphics API for the Java Platform.”

On the off chance you’re not confused yet, Java3D isn’t the only open source 3D graphics API for the … um … Java platform. JOGL, the Java binding to OpenGL, is also open source (under the BSD instead of the GPL). So, what’s the difference between JOGL and the API Formerly Known as Java3D? (Speaking of which, can we just call the latter Fred? Fred is a great name for an API.)

I used to be resistant to the idea of coding. It wasn’t just fear that I couldn’t do it, though that was part of it; it was also the sense that I wouldn’t be able to get to the actual art and music making if I got too involved in programming. And, actually, that bit can be true. But a group of pioneers, working on projects like Processing, OpenFrameworks, and other intelligent development frameworks, has been working really hard to make code an elegant an expressive tool rather than a hindrance. Processing has reached widespread popularity because it does this really, really well — even if you’ve never programmed before.

I’ll be teaching a three-part class on Processing at Harvestworks in New York next month. If you’re in the area, there should still be openings if you’d like to sign up (and if you’re enrolled, feel free to holler hi here — if I hear from you in advance, I can help tailor the course to your needs).

For intermediate digital artists, even those who have never coded before, we will introduce techniques in Processing. Processing is an elegant, high-level, Java-based tool designed to make coding friendly to artists. We will learn how to create generative art in just a few lines of code, building interactive works in minutes. We’ll also look at some of the deeper possibilities for manipulating data, video, images, sound, and MIDI and other I/O. The emphasis will be on basic sketches that help introduce fundamental coding skills.

Wednesdays, March 5, 12 and 19, 6:30 – 9:30pm
$325/$385

Class page / signup @ Harvestworks

The class will specifically focus on how to make video, 3D visuals, MIDI, and sound work for performance. Making Processing a performance tool definitely involves some particular skills. But I’ll also use this as an opportunity to teach very basic coding techniques so that unfamiliar programming topics can immediately generate something on the screen or some sound, since that’s part of the appeal of the whole tool.

But what if you’re not in New York?

We’ll soon have CDM Labs up, which will include examples from the team at CDM, plus other stuff from around the Web, not only in Processing but related tools, as well. I’ll use this as a playground for the course, so what I share with them, I can share with you. And, honestly, we hope this will help discipline us here to keep coding and keep documenting. More on that soon.

I’m also hoping to refine this course into something that can be offered elsewhere; if you’re interested, get in touch.

More on Processing:

Random sketchbook of mine, the kind of stuff you can put together in minutes

Flickr Processing pool

Processing videos on Vimeo

Processing tag on Create Digital Motion

Official Processing exhibition page

Create Digital Music got an interesting comment about allegedly, what really happened to Java in Leopard. Short version: nearly all of the development team is gone; the one Java 6 person left and many others were moved to, of all things, iCal. Java 5 is likely to be all you get on Leopard, and still without improvements to JavaSound or QuickTime for Java, which have left sound and video support pretty weak. (QuickTime for Java is an even worse choice on Windows, though at least on Windows and Linux JavaSound runs better.)

Caution: this could be no more than a rumor. There seems to still be a Java development team at Apple, so at the very least, it sounds exaggerated. However, it’s also clear that Apple’s commitment to developing Java on the Mac is tenuous to say the least.

For Processing fans, though, there’s various good news. First, Apple has updated Java 5, the version of Java targeted by Processing currently. Secondly, while JavaSound still lags behind major quality improvements made on Mac and Linux, if Apple really is abandoning Java on the Mac, it could mean the finger pointing is over and finally Sun could develop Java on the Mac platform, bringing all three desktop OSes in sync (sorry, Solaris, that’s Linux, Mac, and Windows for nearly all of us). Another interesting tidbit: JavaFX, if Sun is to be believed, could be more than a scripting language, it could provide better multimedia support long lacking in Java. I imagine that could be incorporated into Processing. See the CDM story for more details — taking them with a grain of salt, as none of this has been officially confirmed.

Rumor: Mac Java’s Demise is Real, and Why That Could Be Good News for Multimedia

For more on the creation of the new VISP visual app, there’s a terrific story by creator Michael Creighton at Adobe Edge:

Building a visual performance app with Adobe AIR, Flex, and Flash

The advantages of this combination are potent for visual development:

• File system API (so you can easily manage video clips, generative sketches, whatever)
• Native window system API (so your UI looks at home on your OS)
• Flex, for CSS + XML goodness
• Clarity of the ActionScript 3.0 language (I’m totally onboard with this one, frankly, despite complaints from AS old-timers)
• Ease of development in Eclipse

As I noted, it looks like MIDI support comes from an external application. But there’s hope for more interesting possibilities in the future, by hooking up VISP to Java via a new AIR-to-Java bridge called Artemis:

Artemis Tutorial

Now we’re talking. It seems Michael is thinking like I was: wouldn’t it be great to have Processing hooked up to all of this? Now, of course, I hoped to do everything on the Java side, though there is that pesky problem with video support in Java being, how shall we say, less than fresh. But, in the meantime, I’m happy to combine the two where it makes sense.

Onyx was a little shorter on the AIR stuff (aka Apollo), which is what lets you manage files from the file system, so I could see some of what’s in VISP benefiting Onyx, as well .. and visa versa.

Now, someone in Javaland: you know you really want to improve Java’s multimedia support. Come on. All the Adobe people are having so much fun. They’re going to have much better parties. Think about it, won’t you? (Yes, unfortunately, Apple is one of the players who could help remedy the situation and they’re extraordinarily unlikely to be interested, but surely there’s a way.)

It’s no secret that a major update to Max/MSP/Jitter is coming from Cycling ‘74, with a major overhaul of the underlying code and an entirely new, friendlier interface. What has been secret is just what that upgrade will look like. We still don’t know what it’ll look like visually, but Cycling ‘74 today released some new details about what it is and isn’t.

In short, it promises to be:

• Easier to use: Multiple undo, debugging tools for patches, and a visual catalog for perusing objects.
• Easier to learn: Integrated, rewritten documentation, even including Web links.
• Easier on the eyes: A new, zoomable patching interface with lots of new goodies — that’s not only skin deep, but makes patches easier to navigate.
• Mo cross-platform: A new code foundation should make Max more modern, reliable, easier to support on C74’s part, and better supported across OSes. It even opens the possibility of someday seeing Max/MSP/Jitter on Linux and not just Mac/Windows.
• Not full of gobs of new objects: Normally this is not a feature, but here, it’s a good thing: by introducing only a few objects, the new Max focuses instead on improving existing objects and building a better environment / platform for the future.

I’m meeting with Cycling ‘74 this week at AES, so hope to have more details then, including more on what’s changed for Jitter users. Audio users should note a big caveat — Pluggo support won’t be present in Max 5 at launch, which is critical to using patches as audio effects and instruments in other hosts, though it sounds as though that may be added at an undetermined point in the future. But on the visual side, it looks like it could be a pretty smooth upgrade: most patches and externals should be compatible, with some potential updates needed for tools that have special UI features. (I imagine some patches will look a little odd, too, once they hit the new UI — worth keeping that older Max copy around, just in case.) Overall, looks like good news. Naturally, we want to know more. Lots more. Soon. I’ll keep you posted.

Java and JavaScript support will continue to work. And that means Processing is supported, as well (via mxj), so this could be a great Processing prototyping environment, or a way of coupling Processing with other features. (See jklabs MaxLink. And yeah, it really does work … very cool. Viva Java.)

Cycling ‘74 Releases Max 5 Details: Bringing Max Out of the 80s, into to the Future [Create Digital Music]

Believe it or not, people making art with webcams don’t rate very highly on the priority list for big computer companies. (Who would have thought?) On the PC, at least, there’s a thriving market for webcams for video chat, since so few PCs have built-in cameras. Meanwhile, on the Mac, Apple has absolutely zero interest in you using any webcams other than those built into their machines, or, if you’re lucky, one of the FireWire iSights Apple made before Apple discontinued them. (Given the high failure rate I’ve seen on the iSights, that assumes you’re lucky enough not only to have found one, but to have it still working.) Ditto, naturally, third-party manufacturers, since there’s unlikely to be any significant market for their wares — and they’re busy navigating the morass of driver development complexity on PCs.

Long story short: the Creative Labs Live! Optia I raved about in the fall is one of the few choices you’ve got that doesn’t require drivers. It’s USB video class-compliant, though unlike other USB classes, it’s not entirely clear that that’s all that meaningful.

But, for several glorious months, through last week, I was able to keep my Live Optia working perfectly with Processing (and thus QuickTime for Java) and QuickTime (via tools like Jitter). Until today, that is. Now I’ve got two of them, five Macs to test, and — nada. On 10.4.10 / QT 7.2 and 10.4.8 / QT 7.1.3 and 7.2, I get either a black screen or (in QuickTime video capture) garbled video. It looks like the sequence grabber isn’t properly setting the resolution, so pixels are being dumped arbitrarily from the camera … I suspect the other errors I’m seeing are also related. USB video class support is relatively new; it only hit iChat in 10.4.9 and may have reached the OS at the same time — I would know for sure, except documentation from Apple is scant.

I suspect some misbehaved QuickTime update, though I find it especially odd that it fails on multiple machines (all Intel — iMac, MacBook, MacBook Pro, and Mac mini) with different versions. I’ve tried reinstalling QT, zapping NVRAM (formerly PRAM), the lot. For once, I can’t blame QuickTime for Java, because everything else is broken, too.

Webcams working some of the time under unpredictable circumstances don’t inspire confidence. Suggestions, anyone? Any idea why this is happening? Anyone got a rock-solid solution for Mac webcams that doesn’t spontaneously cease functioning?

Incidentally, Windows isn’t much better; weird driver bugs there can cause fabulous results like an echo-cancellation driver knocking out USB MIDI devices, driver-related blue screens of death, and other goodies.

Maybe I should just start making my own cameras and writing my own drivers. Yeah, that’s it.

3D goodness means getting cozy with your local graphics API — and getting ready to nerd out in a big way. OpenGL continues to progress with a major overhaul. It’s a way off, but you’ve still got lots of eye candy with OpenGL 2.1. So … if you’re not Electronic Arts or Bungie, is there really any reason to use DirectX?

With the release of Windows Vista, we’ve been hearing a lot about DirectX, Microsoft’s Windows-only API for accessing graphics hardware. Of course, most of what you’ve been hearing is Windows gaming lovers complaining because they have to upgrade to Vista just to get DirectX 10 — and they take a compatibility and performance hit for many existing games as a result. (The latter isn’t DirectX 10’s fault; it’s a side effect of a new driver and display model in Vista itself, which impacts OpenGL and DX9, as well.) So what’s going on in the OpenGL camp? At SIGGRAPH, OpenGL 3 was announced. The full spec isn’t available yet, and actual OpenGL 3 hardware will be some ways off, but the future looks bright. In a presentation on the new OpenGL, NVIDIA’s Michael Gold pointed to these major hallmarks:

• Getting “back to the bare metal” for performance. This includes cutting back on overhead, streamlining the API, and actually revamping the object model in a way that should boost raw speed.
• Simpler, more efficient application development.
• Simpler driver development.

So that all sounds good. The object model appears to be the major change, with new object meta-classes that make it easier and more efficient to, well, make stuff. Good luck deciphering this at this point (I expect it’ll be easier once the real spec is out), but here’s more on the announcement, with slides:

OpenGL 3.0 Birds of a Feather at SIGGRAPH
PDF with slides, via NVIDIA’s Michael Gold

Us visualists, of course, can leave most of this to developers and hardware makers. What’s nice is that when we do want to make things look slick, we have access to a cross-platform 3D API in tools like Processing/Java, Pure Data (via GEM, etc.), and Max/MSP/Jitter.

As it happens, I’ve been looking at both OpenGL and DirectX solutions while putting together tools and frameworks to do new 3D work.

Some more shots of projects I sketched while in Ben Fry’s Processing class:

And heck, even extremely basic, fundamental code starts to become a fun exercise, like a mind workout for 3D translation and quick coding:

As we got into the later days, I was really interested to watch as my colleague’s work tended to get more painterly and organic. The ability to do this quickly is really encouraging.

I’ll definitely be debriefing with some information and code examples soon — probably after I develop more of what I was thinking about while at the workshop. But I can’t say enough about how great it was to get to work with Ben and absorb his unique insight into his tool and artmaking in general. It’s really made me want to devote a great deal of new time to Processing — and has given me some sense of the best directions to take that work. Still on the road here (hello, airport lounge!); more soon.