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

Bean Machine @ JH Labs

JH Labs main page with lots o’ projects

  • toby*spark

    that is hilariously a rip of the qc patching gui.

    but what i don't get is how the performance of these types of environments can't suck: qc is largely a veneer on the graphics card, and everything that isn't gpu native is c based compiled code. and if i have enough problems with framerate as it is…

    i guess how much java is actually going on is a factor, ie is it mostly the same open-gl calls just coming from java instead of obj-c, and another big one would be whether it manages to make more useful patches/nodes that make for a more computationally/gpu efficient composition.

  • wes

    does anyone know the name for a real time watcher path in qc.

  • Peter Kirn

    Toby, not quite sure what you're asking. Java can perform perfectly well in 3D applications. In fact, JOGL is largely a binding in the same way that Apple's Cocoa tools are (only a binding to OpenGL instead of Core Image *and* OpenGL, but the latter is also theoretically possible — though not cross-platform, by definition).

    I think some of these concerns about Java and speed come from the very early versions of Java, which really were painfully slow … back in the 90s.

    Of course, you can have performance bottlenecks anywhere … there are a couple in QC. ;)

  • Morpholux

    I'm not a big expert, but as far as I'm concern, every time we get stuck by something we can't to do in QC, we manage it trough the JavaScript Patch. With this kind of patch, you simply customized the Dataflow as you want. So for me, QC is quite a complete environment. Especially with some additions, like the Kineme plug-in.

    To WES : There are two kinds of module for time in QC : Patch time and System time. The first one is relative to the activation of the composition when you start the viewer. The second one is absolute and give you the difference between the actual time on your machine and the first of January 2001 GMT.

  • Peter Kirn

    Unless there's something I'm really missing, I don't think you can get the performance out of JavaScript that you can get out of Java. So I don't see that as an option. But then, that's why I don't use QC — so maybe we're doing different things. I think the other key is that this kind of approach, working with Java as the platform, is an option for cross-platform deployment, whereas QC is not.

  • memo

    The UI looks better than QC thats for sure! :P

    if I understand correctly, the Java here isn't a replacement for JavaScript in QC, its a replacement for JavaScript and/or Obj-C in QC (i.e. writing a new patch with the QC API). While you can use JavaScript in QC to do basic maths or decision making, flow control etc… you can't actually create, draw, or modify images – you need Obj-C for that. To see the performance of Java, just look at stuff done with Processing.

    This is a very interesting project… hope it matures well…