Node-based a/v composition: programs as graphs and graphs as compositional tools

this is a great project, i am interested to see more competitors to pd, vvvv, and max matthews little program. a lot of great work has been made on tools like this.

check out touchdesigner, it has the ability to go deep into GLSL and python but is also quite approachable. i feel like it is generally regarded as a node based graphics programming environment, but would argue that it is really just an arbitrary real time data handling system that happens to have a lot of built in graphics nodes.

A git or otherwise nice version control with diffs and such for a visual language would be killer.

He didn't mention a few other big ones with good demo versions: Nuke, Touch Designer and Digital Fusion (much more awkward, but free).

Figuring out why programs like these work well and what gaps are between them and general programs is interesting because many of the reasons come down to pragmatic workflow and not technical limitations.

They all operate on a very limited set of data types (just images, images + geometry, etc.) and don't have to deal with state, branching, or loops. Results can be viewed easily at each stage and each operation can be isolated and iterated with real time interactivity.

This project tries to use message passing nodes as a backbone and data flow as the heavy lifting to get to visual C++ programs:

https://github.com/LiveAsynchronousVisualizedArchitecture/la...

From a creative perspective the modular/node-based way of thinking has always been a niche, having seen many attempts such as this to place it into a broader model of creativity (including my own [1]). Its telling that the enduring musical instruments of the electronic age have been relatively fixed-function (Minimoog, Yamaha FM synths, 808/909) with constrained options for patchability, rather than modular synths highlighted by the article. The metaphor is further strained by modular synthesis' lack of basic affordances a programmer would expect, such as a memory model, data types, composability/reusability of "code", etc.

These issues translate to digital node-based systems- dealing with structured data in e.g. Max or TouchDesigner becomes an exercise in patience, and their mechanisms for composing and reusing code are somewhat baroque as well.

The other major creative limitation of flow-based programming (and in fact, most computational art systems) is the absence of a timeline (as mentioned by another commenter). This is a showstopper for many creative pros Ive talked to. But it grazes on topics that are interesting purely from a computer science perspective- imagine if you could freely jump to any point in a program's execution?

To be clear, having spent my doctoral studies in this space I find these to be interesting problems to solve rather than indictments of node-based programming as a whole. Im interested to see how eternal and other efforts mentioned in the comments here tackle these and other challenges.

[1] https://purl.stanford.edu/mf249vj6694