In the past few days at college I’ve been designing the way patches would look inside the editor – doing this inside Photoshop rather than any programming environment. Right now, this is the way typical nodes are supposed to look like inside the editor:

To the left is a typical node. Again, I’m adopting a node abstraction that’s similar to the way vvvv does stuff – that is, the node is simply represented by its name, and sometimes its value, with no special rendering mode unless there’s a very special reason for that. You probably won’t see a myriad of different buttons, sliders, switches, potentiometers, lights and any other crazy stuff on a typical Fnk patch (there will be toggle/bang buttons and sliders, though).

The node to the right is one of those exceptions. It’s a graphical node – what I’m calling composite right now – which will display some rendered content inside itself. That design sample doesn’t show much more than a black background, though.

The visible representation of the nodes has to respond to certain constraints – say, normal text nodes have a maximum height, and a minimum width – but overall, they’re fully movable and resizable. You’ll notice the above nodes have a move handle area on their left side – clicking there and dragging will always move the node – while the right side has a resize handle area that lets you resize the nodes as needed. My biggest interface frustration with programs such as vvvv and Max (specially) has been the inability to properly move and resize nodes without making constant mistakes, and this is something I’ll hopefully address with Fnk by using those handles.

Lastly, I’ve also been focused on getting Fnk’s editor and renderer up and running. Basically, trying to give each side of the brain a balanced time to work in something. It’s not like the editor will reach a mature state so soon – there’s still a lot I have to decide regarding its execution structure and general data features it’ll support – but I needed to see it running so I could do my own data transformation tests in context. So, without further ado, see a very early alpha version of Fnk running here (or the most recent version here).

This version employs most of the structure I’ll need with Fnk player and editor – node and link rendering, patch processing, and even XML patch parsing.

Notice, though, that the sample patch used is very, very simple. It’s pretty much the equivalent of this:

(1 + 1) + 1

The sample also employs one additional “Statistics” node, grabbing some system data (current framerate, time to execute each frame in milliseconds, and current memory usage in MB) and displaying it on additional I/O nodes. Other than that, though, it’s not really editable – you can only move nodes around, and resize them. You cannot change links, create new nodes, or delete old nodes.

The background text is just some temporary debugging log for me to find out whether the patch is executing as it should.

There’s also a lot of CPU overhead on this version – it’s actually re-rendering all nodes and all links at every frame, as well as not caching node values – and the links are represented as just a single, symbolic, rough line. It’s a prototype, and from now on the task will be as much to develop a better, more mature framework, as to actually start testing node types and seeing what works and what doesn’t.