The three separate stages of Fnk development

By • Sep 25th, 2008 • Category: Developer diaries

Now that I’m concentrating my full time in this project, Fnk development has been progressing quite well. It’s not quite ready for prime time yet, but at least now I can show something to people when I explain to them what my project is about. This post is not for that, though, but to explain how things are being done.

Development in process is done in three fronts: the Patch execution engine, the Patch Editor, and the Node dictionary.

The Patch execution engine is the internal Fnk engine. It’s what processes every node available on every cycle and controls all of their dependencies, as well as keep all transformed data as it passes from one node to the other. This is the most important part of Fnk and the first actual part I’ve built during the project prototyping stages earlier this year. There’s a bit more about that in this post. It’s also pretty much done, except for some small features I’ll add later in development for performance.

The Patch editor is what I’m finally building right now – it’s the program interface, or what enables anyone to go and create a patch (by placing nodes and links from node to node) that does something. Up until now, I’ve created my test patches by creating a XML that describes all nodes and links used (see an example of a Fnk patch “source code” here); this works, but of course, it’s not very friendly. It’s actually a bit funny that I have been testing without an actual editor, as it’s a special sort of hell to test the execution and output of about a dozen nodes without seeing them or being able to edit them; this kind of dataflow-driven language is very dependent on visualizing the diagram you’re working with.

Having to work on the editor after the engine is done is like creating a new programming language by creating the compiler first, and only then creating an editor that actually allows you to write programs for the language. Which is the way it was supposed to be on this project – I had to make sure the internals worked before coming up with the interface – but still sort of weird. I guess I’ve been too used to a more concrete method of development – working on the visual shell first and foremost – but I’m glad I’ve taken a different route this time.

Anyway, the good news is that the editor is almost working – patches are sort of editable, although nodes and links cannot be created or deleted yet. As such, I’ve been uploading pictures of the Fnk’s interface, for archival purposes, to this Flickr set. I’ll hopefully be updating this when there are significant changes to the interface. And as usual, the online test version is always updated too (but again, it’s very alpha and not really usable). Why do I have these even online if they’re so early? Transparency, I guess. This is not a commercial product, so I can afford getting those online to show to a few friends or test from different computers.

And lastly but not least, the Node dictionary is Fnk’s actual language – it’s the list of available nodes and the kind of transformation they do on data. Right now, there’s only a few types of nodes – simple math and string calculations, some debugging nodes that generate data on their own, and things like that. These are just placeholders while I test the editor and the engine. As soon as the editor is done (or as soon as I can actually create new Patches), I’ll be adding new nodes to make the language useful. Of course I have an infinite list of planned nodes, from simple numeric and string transformation to graphics/sounds/video/external devices/etc, but I’m just not there yet. This will be the funnest part of the development process, and I can’t wait until I finally get there, but it’s just a shame that it’s also the latest.

Comments are closed.