Noisecraft - anyone heard of it?

Cheers for the links :+1:

Interestingly of those 3 the only one where I got to a page where I could try out the product was litegraph but that got me to an empty screen - the other two were with signup (n8n) or "sorry our product is broken"-popup (total.js).

Probably the lesson is that a browser-based node-flow-visual-programming tool for profit-and-gain should have an working example page (without signup please!) :wink:

I keep bumping into them but never really stuck with me (modular synths). I enjoy the visual chaos of noisecraft, along with the sound and it runs in my browser!

I've played with supercollider and discovered my next time-sinkhole in the form of supercollider node-red nodes ... thankfully noisecraft came inbetween!

To that list you can add they have also have a github NodeScript · GitHub


There is currently a discussion on n8n on hacker news with some more alternatives -

You can also look into TouchDesigner and NodeBox that are also designed for low-code audio-visuals

Both look like they are inspired by node programming in Blender which for me was always kind of confusing.

I think what Node-RED does right is the one-or-zero inputs and no typing of inputs/outputs - most node programming environments have types for their inputs, confusing me no end. Admittedly most use colours to distinguish types, so one learns red outputs can only go into red inputs (for example).

IMHO Node programming is confusing enough (for beginners) without having colour coded inputs/outputs. I personally hope Node-RED sticks to the grey one-or-zero concept.

1 Like

I think it really depends on the application as to whether an event-based or graph-based nodes are a better fit. IMO, graphs are better for introducing complex and simultaneous functionality, like in audio-visual or state-based systems. Event based applications are easier to start with and they make sense for much more linear systems like IoT and industrial settings.

Thanks for that, I never thought of it like that. :+1:

If I understand correctly, things like noisecraft are clock-based state machines - i.e. everything is synchronised to a clock and states change with the tick of the clock. So in a sense each wire is always on and has some value that is read with the clock goes tick. In Blender I'd guess that would be frame counter.

While Node-RED is event-based and data-driven meaning that data flows when events happen otherwise the wires or pipes are empty or off. Node-RED describes action that should happen when something does happen!

Fun to think of seeing two identical flows yet their outcomes or meaning is completely different since one is event-driven and the other is a state machine!

And, just to confuse things further! Node-RED is not really flow-based at all! :grin:

In that it only appears to be flow-based since nothing is actually "flowing". The wire connections simply create data shared between connected nodes via an event function.

Least, that's what I think happens. :rofl:

That's why I see pipes and not wires :slight_smile: I keep thinking of Unix pipes... Where Yahoo pipes got its name from...

1 Like

So I wrote my thoughts down in pipes, wires & nodes, for me it seems that visual programming and the representation of flows will become more confusing since they all look the same but can be completely different.

Compared to textual programming language, one can visually recognise the difference between lisp code and java code and thereby one knows what the underlying concepts of the program are: object oriented programming or list-based functional programming - this isn't possible in a visual programming world.

1 Like

You might be able to but I know a lot of people who wouldn't. :rofl: And I've seen plenty of Java code that might as well be Lisp!

But how many people would know the difference in approach without doing some research if they'd not come across either language before?

So maybe we are over-thinking things here? I'm not convinced it matter that much as long as there is clear and accessible information on the basics of how the platform works and what the differences mean.

For example, my tongue-in-cheek explanation of Node-RED's approach really doesn't matter to most people - at least until they get into more complex concepts. That a message doesn't really "flow" is not important to start with, only that it appears to do so.

To me, I think the most important difference in approaches of different visual programming tools is whether the flow is linear/synchronous or asynchronous. Node-RED is asynchronous which is why only a single input port exists for each node. Most visual programming tools have multiple ports because the coupling between nodes is tight, not loose like Node-RED. So a node defines input variables that translate to input ports, 1 for each variable. Node-RED uses loose coupling with its "message" based approach.

Most people would literally not know how to use a keyboard - 8 billion, some 2 or more billion living in poverty who would never have seen a keyboard. Then probably another 2 billion who are barely surviving and are happy to know how to use a mobile phone. Of course, most people won't give a flying banana what we're discussing here :slight_smile:

The point is not to reach everyone, the point is to leave bread crumbs for people who come along and start thinking about these things. Little bread crumbs to follow along the trail of learning Node-RED and discovering visual programming.

There isn't a single approach to explaining Node-RED to others, and the more I try to explain Node-RED, the more I realise that Node-RED is very complex because of its visual programming nature. But that makes it far better in explaining some things than a long text file with some obscure programming language. I also wrote about the visual programming approach and how it comes far more naturally to some people.

Exactly, another approach to explain Node-RED :+1: For me I wouldn't see it like you but I understand what your saying. If someone comes along and reads that and suddenly they understand Node-RED, perfect - that's my goal: spreading the understanding of Node-RED and visual programming.

I have a completely different approach to Node-RED than you - that's why I build RSS to node convertors - totally obscure, totally questionable what might be the purpose but totally possible with Node-RED!

One final thing I did today was to explicitly convert Python to Node-RED - fun experiment, don't know about what is better but I do know: Node-RED flow is visual and code, that's what UML wanted to be!

1 Like

Yes, I wish there were a Python version of Node-RED. :slight_smile: I know so many data scientists and analysts who would absolutely love it.

I've always been annoyed that Python and JavaScript have different strengths that overlap but aren't quite aligned.

Literally it won't be that hard to build a basic python interpretor for a node Red json file. You just need to emulate the basic nodes (change, switch, join and split) and integrate v8 into python for the function nodes :wink:

A weekend tops!

I'll await with baited breath. :rofl:

In the meantime, I need to think some more about better ways to visually process tabular data in the browser linked to Node-RED (and uibuilder of course!).

Some thoughts (sorry going well off-topic here. If there is further interest in a discussion, we can take to another thread).

  • An editable table widget for the browser where data changes are sent back to Node-RED.

  • Some DataFrame style tools for manipulating 2d tabular JSON data.

    • Using msg._ui low-code - facilitating quick table updates from Node-RED.
    • In Node-RED functions - enabling simpler manipulation of 2d JSON data.
    • In the browser - as above.
  • A live JavaScript interpreter in the browser that would let users do Jupyter notebook style interactions with browser data.

More stuff to add to the uibuilder backlog I guess!

I see what you mean:

Having read that discussion I might stay away from a computer on the weekend! It would really make more sense to create a and not, i.e. completely build a new visual programming tool (as you suggested in that thread). It's only a pity since the frontend would have to be reimplemented in JS anyway.

What I was thinking of was a simple head-less python engine for interpreting some of the core nodes based on being sent a flows.json from the frontend. I would do that if there was a) a specific use case with b) a specific limited number of nodes involved, i.e., the core logic nodes. But since I don't have a use-case, the weekend is saved!

How does google sheets do that? They seem to have it down pat. Are you planning to have parallel updates of data by multiple users? Or just one user manipulating the data? O(1) or O(n) headaches!


The dynamics are actually quite easy since Node-RED with uibuilder already provides all the tools.

Even the multi-user issue is dealt with already since uibuilder already surfaces a number of properties (client id, tab id, page name, ip address) and custom ones are easily added if needed.

What you do with the data back in Node-RED is, of course, entirely down to your skill with authoring flows and wrangling data. :grin:

Actually, another thread reminded me about Perspective | Perspective ( which does much of what I'm looking for - except one major thing, you cannot update data via the grid as far as I can tell. Which is sad because I can easily create a uibuilder extermal template that would let anyone easily throw a Perspective data view onto a web page. It is just a few lines of code.

Anyone here know what happened to (highlight from me):

It is with a sad heart that we've decided to not pursue monetization of Interface Vision's core technologies. We've done a lot of amazing things, but there just isn't a market for visual programming environments: yet. It will happen: it's inevitable. But just not now.

That statement seems to have been from 2014. (they also have a long list of visual programming interfaces - Visual Programming Languages - Snapshots)

I got there from - which seems to be a research group from Facebook.

Seems to have been a 1-man band. Also his list didn't even include Node-RED!!!

And clearly there was already a market when he wrote that, he just couldn't leverage it it would seem. After all, Node-RED dates from before then.

Also annoying that they don't mention Node-RED which is an excellent example of a node graph!

Not really surprising that most of the examples of node-graph processing come from the music and visual world since those are obvious use-cases for the orchestration of, often highly time-dependent, actions. But of course, that is a very different use-case to Node-RED's asynchronous processing that was originally intended to orchestrate sensors and robotic controls.

I still think that Node-RED has one of the easiest approaches to get into visual programming, the use of JavaScript objects ("messages") greatly simplifies the visual aspects, minimising the number and spaghetti nature of the wiring.

1 Like