The program looks great however whenever I use a node based editor(blenders comes to mind) I can't help but wish there was a better way. I am not a fan of the spaghetti and meatballs programing model.
The best I could come up with was to put the nodes in a list, that is, make it 1d. with virtual lists to the left(to show sources) and the the right(to show drains). then it would be sortable and well ordered. but I am not a very good front end programmer, so have not made a mockup to see if it is any better.
The next thing that comes to mind is that as a programmer we deal with graphs all the time in the form of source code. That might be a better interface. I for one gain all sorts of utility from my code being in text form. Plus you would now be able to add logic to your processing graph... I am not sure whether or not this would be a mark for or against a code based system.
Having said that, there would need to be a fair amount of care put into designing a programing language for building video edit pipelines. I don't know exactly what it needs. but I have tried to use ffmpeg in this role... and the best that can be said is that it is very awkward.
A nice alternative to spaghetti nodes is brick stack, as first developed by demogroup farbrausch in their tool werkkzeug. You stack the bricks on top of each other and it flows from top to bottom. When one brick can have more than one input, you just extend it horizontally and have several bricks on top of it, read from left to right like arguments to a function. Editing the properties of the bricks is done in a different window as bricks must have the same height. Tooll then extended the concept by allowing spaghetti and brick together, making it easier to have loops. https://www.youtube.com/watch?v=B-GU4I5Xv_g
afterfx is the king of layers, and that gets impenetrable pretty quick.
The best way to deal with the spaghetti is to group and route. In Nuke, you can group a bunch of nodes into lump with defined input/outputs. This means that you can hide the complexity underneath and limit the amount of "wire spread"
Node based systems are really good for hooking things up and testing/altering. It also quickly, clearly and obviously shows data flow.
Not all node displays are created equal. Anything that has bendy lines is a non starter (there is a reason Printed Circuit Boards rarely use curvy lines) Anything that doesn't have a group & hide function is also doomed. Its like having a programming language that doesn't have a functions, only goto.
If you want to edit video in a programmatic way you should look into AviSynth and the more recent VapourSynth.
Maybe also into using GEGL filters in a GStreamer graph but I do not know if a tool that does this was ever developed. There used to be plans to create an editor (I think it was node based) based on GEGL.
for those wondering, this is an opensource version of Nuke from the foundry. Think of it as photoshop, but for movies/TV. This is the Gimp to Photoshop, or Blender to Maya
I once made a basic video editor using Apple's Quartz Composer because I couldn't find a free tool to do what I wanted.
I really liked QC, but it's slowly wasting away. It helped me get started writing my own apps, I used to build huge compositions for projection mapping. It eventually prompted me to learn openGL, and I program everything now, but it was a great stepping stone.
I think video, texturing and/or FX is one of the good use cases of using node-based or visual programming user interfaces. Many have attempt to reflect workflows, form design, state sets and such with a similar approach but somehow it always gets too complex and difficult to view
13 comments
[ 3.2 ms ] story [ 39.0 ms ] threadThe best I could come up with was to put the nodes in a list, that is, make it 1d. with virtual lists to the left(to show sources) and the the right(to show drains). then it would be sortable and well ordered. but I am not a very good front end programmer, so have not made a mockup to see if it is any better.
The next thing that comes to mind is that as a programmer we deal with graphs all the time in the form of source code. That might be a better interface. I for one gain all sorts of utility from my code being in text form. Plus you would now be able to add logic to your processing graph... I am not sure whether or not this would be a mark for or against a code based system.
Having said that, there would need to be a fair amount of care put into designing a programing language for building video edit pipelines. I don't know exactly what it needs. but I have tried to use ffmpeg in this role... and the best that can be said is that it is very awkward.
That said, I love nodes in Blender, Twine, Sunvox, Shadergraph, etc, but every node-based programming system I saw so far was torture.
afterfx is the king of layers, and that gets impenetrable pretty quick.
The best way to deal with the spaghetti is to group and route. In Nuke, you can group a bunch of nodes into lump with defined input/outputs. This means that you can hide the complexity underneath and limit the amount of "wire spread"
Node based systems are really good for hooking things up and testing/altering. It also quickly, clearly and obviously shows data flow.
Not all node displays are created equal. Anything that has bendy lines is a non starter (there is a reason Printed Circuit Boards rarely use curvy lines) Anything that doesn't have a group & hide function is also doomed. Its like having a programming language that doesn't have a functions, only goto.
Maybe also into using GEGL filters in a GStreamer graph but I do not know if a tool that does this was ever developed. There used to be plans to create an editor (I think it was node based) based on GEGL.
Screenshots, feature lists, downloads, etc.
Node-based systems for this task are an industry standard that has emerged over the first twenty years (~1980--2000) of CGI for VFX.[1]
The only alternative for this kind of work may indeed be a text (code) based system.
You can export node graphs as text files in many such apps. But no one edits them.
The majority of users are artist types who will not touch anything that looks like code with a ten foot pole.
[1] I'm an ex VFX industry professional. You can take my word for it.