Free tools like Processing and OpenFrameworks have provided elegant, quick coding for live graphics, but their interfaces have tended to be code-based. One exception has been the Mac-based Field, which provides graphical patching. Now, you can add NodeBox to that list. This free graphical creation toolkit, built on Python, had long allowed tinkering with and exporting beautiful illustrations, but its interface used code exclusively – and it ran on Macs only. Now, NodeBox 2, in an actively-developed beta, runs on Windows and adds a graphical patching interface.

The “Core Vector” Nodes act as much as a set of macros as anything, with basic objects for shapes, grids, lines, curves, and text paths – a bit like what you’d find in the toolbox of a graphical editing package.

Windows support is a good thing for PC users, but the terrific Digital Tools blog asks an interesting question – is adding more necessarily a good thing?

I just played with it a little bit, and can confirm, that this approach really leads to once again much quicker results, than tinkering with code only … [though] tinkering with code only is also an option

… I am totally in love with this plain simplicity of NodeBox1. Having too much of everything, and getting results too quickly is not always for the best.

NodeBox 2: Things are getting modular [Digital Tools]

It’s a reasonable point. After all, an environment like Processing could easily enough add this sort of patching interface – but sometimes, focusing on code, and even adjusting code, then running the results, can be more productive. And by resisting such functionality, Processing remains lightweight and easier to support.

On the other hand, modular patching can be a powerful interface metaphor.

NodeBox remains one to watch. It’s still not suitable for live visuals, animation, and interaction as are other environments, but it could offer lessons for those tools. And it remains a fascinating way to produce illustrations and designs.

  • neb

    I'm voting strongly for more visual programming environments, mainly because they allow right-brain network oriented thinkers to be much more productive in interactive design. As someone who is drawn to programming, but finds code permanently unintuitive, good visual flow programming tools (patching) have been a life-changing boon.

  • Wow! Thank you Peter for spreading this, I wasn't aware of it. The node, the expression and the 'edit parameters in the viewer' paradigm is quite similar to the one of Apples Shake, which I really like. Oh, and I'm in love with Python too. Definitely something to dig into – like right now.

  • I've toyed for an hour with Nodebox 1.x. a while back, and though it wasn't real-time, I remember it having provisions for iteration so you could do animation.

    All in all, I prefer Python over Java but see the point in Processing running damn near anywhere. It's a tradeoff, but in the perfect world Python would be my choice – it really is easier for non-programmers.

    Other than that, I think I'd reached my limit for experimental visual programming languages when I first saw it. That's probably still the case, but the more the merrier!

  • As the author of NodeBox I'd like to elaborate on the point of the visual interface, and why we choose to add it to a purely code environment.

    We do a lot of workshops with students, and we find that time and time again they have problems with the code. First, it requires considerable efforts for graphic design students used to Photoshop and Illustrator to understand the need for coding your own tools. It just seems like too much effort.

    We are able to explain the basics of programming and get them up to speed, and they get a lot of nice results. The libraries we provide allow them to use a lot of our code to generate interesting stuff. But most of them stop there. 95% of the design students will never be programmers: most understand loops and variables, but few really grok object-oriented design, let alone recursion. This poses a considerable problem.

    NodeBox 2 provides an additional layer on top of the code. One where each node is a visual block that contains a Python program that does something: generate a rectangle, transform some geometry, etc. All of the code is there for users to see and understand. Users can just connect existing nodes together and then adapt a specific node to their needs. Basically, we "lure" users in through a nice graphical user interface, and gradually nudge them to code.

    The importance here is that users can build on existing, hopefully exemplary code without worrying about how to arrange functions and the benefits of OO. All of those high-level abstractions should be dealt with in the GUI by assembling blocks.

    When I was a kid, I loved playing with Lego blocks and electronics; opening up stuff to see how it worked, assembling constructions with simple parts. All of these concepts are in NodeBox: being able to see what makes a node work allows users to build their own. Building complex designs out of simple blocks. Linking blocks using expressions. And diving in the code, adapting existing code or writing your own nodes from scratch.

    We designed the application to grow with you.
    Not only by how the app is structured, but also through contributions and remarks by the community. Feel free to jump in and provide us with your remarks, bug reports and patches.

    By the way, we're currently working on animation support.

  • David Prouty

    "I’m voting strongly for more visual programming" …… I second that statement.

    Ease the curve and increase creative output. Many people today are spending huge amounts of time on preparing to be creative as opposed to actually producing the created item.

    Something similar to the Peter Principle. Instead of rising to your level of incompetence, you prepare to the level that you never have time to actually finish something great. You may finish but that extra ten percent that takes it over the top was used on the learning curve and unintuitive tools.

    Ive had this sneaking suspicion while watching executives make work but failing to get much done, that this may well end up being the reason for so many large companies doing poorly. To much management not enough creative production.

    Visual programming eases the curve allowing creation to happen while you learn and a script engine underneath allows you to grow when its time.

    Bravo Frederik …

  • Hey, I definitely see some advantages to a visual patching metaphor, even in conjunction with a coding interface. My best guess is usually around the time I start drawing signal flow diagrams while coding. 😉

    Animation support sounds fantastic. It's a really lovely tool.

    PS, I think it's theoretically possible to code in Processing with Python. Here's an example:

    And The Field has accomplished something similar. I've also seen encouraging work with Processing and Scala.

    Now, to me, as beautiful a language as Python is, Java isn't *so* bad — it's usually the layers of APIs and classes you have to dig through that makes Java coding a pain, more than the latest, coolest language features..