4 ms·

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 mo

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 https://purl.stanford.edu/mf249vj6694

andybak 7y ago
Flow-based, node-based, visual - whatever you want to call it, it is programming and needs one to think like a programmer for anything but the most simple tasks. In fact - it can be more complex than "actual" coding in some ways as the pallette of abstractions is often more limited - or the interface creates hoops to jump through that a text-based format wouldn't. (I do like jumping between text and visual node-based representations however. Learnability and discoverability are an advantage of the latter. And it fosters a different style of tinkering.) With regard to timelines - I can think of several ways a timeline would work with a graph. It can simply be another input for any exposed parameters. Or it can be a node in it's own right.
kousun12 7y ago
Agree on most of this; most systems I've used so far feel a bit clunky (Houdini has by far been the most sophisticated system I've worked in), and my sense is that if it had more mindshare / attention, the paradigm could actually be pretty fluid. Using most node-based tools today (including eternal), I get the admonition that it's like using text edit to write python compared to a pro at using pycharm. The timeline thing is really key. Houdini does it in a sort of clever way where "time" as a variable is exported globally to any node that wants to use it, and the timeline feature is a consequence of using the time variable in any of your functions. i.e. it's not jumping you to a point in the program's execution, but rather acting as a controller for all time-dependent functions. sort of like exporting a time uniform to graphics shader
- ssalazar 7y ago
  Agreed- a lot of the issues people bring up with node-based programming have promising solutions, its just a matter of exploring the space and finding successful implementations. As far as timeline, I also think the digital audio workstation model is interesting- modules export parameters that can be assigned to an automation channel and dragged/tweaked visually on some hierarchy of timelines.

andybak 7y ago

Flow-based, node-based, visual - whatever you want to call it, it is programming and needs one to think like a programmer for anything but the most simple tasks. In fact - it can be more complex than "actual" coding in some ways as the pallette of abstractions is often more limited - or the interface creates hoops to jump through that a text-based format wouldn't. (I do like jumping between text and visual node-based representations however. Learnability and discoverability are an advantage of the latter. And it fosters a different style of tinkering.) With regard to timelines - I can think of several ways a timeline would work with a graph. It can simply be another input for any exposed parameters. Or it can be a node in it's own right.

kousun12 7y ago

Agree on most of this; most systems I've used so far feel a bit clunky (Houdini has by far been the most sophisticated system I've worked in), and my sense is that if it had more mindshare / attention, the paradigm could actually be pretty fluid. Using most node-based tools today (including eternal), I get the admonition that it's like using text edit to write python compared to a pro at using pycharm. The timeline thing is really key. Houdini does it in a sort of clever way where "time" as a variable is exported globally to any node that wants to use it, and the timeline feature is a consequence of using the time variable in any of your functions. i.e. it's not jumping you to a point in the program's execution, but rather acting as a controller for all time-dependent functions. sort of like exporting a time uniform to graphics shader

ssalazar 7y ago
Agreed- a lot of the issues people bring up with node-based programming have promising solutions, its just a matter of exploring the space and finding successful implementations. As far as timeline, I also think the digital audio workstation model is interesting- modules export parameters that can be assigned to an automation channel and dragged/tweaked visually on some hierarchy of timelines.