Noisecraft - anyone heard of it?

General
1

Hi There!

I just found this and was amazed: https://noisecraft.app for example: bounding balls - NoiseCraft (press play top right)

Basically node-based visual-coding for synths! Its all open source and available at github.

Warning: very addictive for people who like viewing flows and now listening to them :slight_smile:

2 Likes
2

Yeah node based flow programming is everywhere:

1 Like
3

Modular synths have been like that since the late 60's i think :wink:
If you are into modular synths, I would highly recommend vcvrack (free).

4

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:

5

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!

6

To that list you can add https://nodescript.dev/ they have also have a github NodeScript · GitHub

2 Likes
7

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

8

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

9

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

[rant]
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.
[/rant]

1 Like
10

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.

11

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!

12

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:

13

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
14

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
15

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.

16

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
17

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.

18

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!

19

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!

20

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 Node-RED.py and not Node.py, 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!