helo patcherpeople,
here is the third in a series of blogposts about our forthcoming nextbigthing that we still call vvvv50 (50). If you haven’t already done so please first read the previous issues with the titles:
Here is a simple one in that there is not really much new. We’re basically trying to sell you an old idea from vvvv45 (45) under a new name, a better name. Together with a new visual representation this will make things easier to think and talk about: Properties (formerly ridiculously called FrameDelays)
45-style FrameDelay
45-style: whats going on here?
When in 45 we create a FrameDelay node and combine it with a link that goes back up the graph against the typical dataflow that wording and visualization describes very well whats going on internally. But do we care what vvvv is doing internally? Not really, so why make such a fuzz about it in the patch. Instead lets see how humans would think/talk about whats going on there.
50-style Properties
Obviously the patch has two properties best named “Velocity” and “Position” and there is an acceleration coming that influences the velocity which in turn influences the position. So instead of using the notion of “framedelay loops”, 50 puts emphasis on the fact that besides operations (Colors) we also have properties that name the data held in a patch. A property has a user-choosable name and of course a datatype (eg, value, color, string,..) and we can set (write data to) and get (read data from) it.
50-style: ah someone clearly computes a position from velocity and acceleration.
In order to get or set a property you need so called Getters or Setters, represented in 50 by circles that you can connect from and to. True, that looks a bit like 45-style Send/Receive nodes but it is something different. Remember that there is no frame delay between S/R nodes in 45. Here though it is always made sure that each frame first all Getters are read from and only then all Setters are written to (causing quasi a frame of delay but you don’t really have to think about it that way anymore).
Also note that by forcing you to choose a name for each property (if you’re not too lazy and just keep the defaults) 50 can render you a fancy human readable overview of all data in a patch. This overview doubles as a central place where you can manage (ie, add, remove, rename, …) all your properties.
So if someone asks, this is why you like properties:
- they are now first class patching citizens when in 45 they have been disguised behind framedelay loops potentially hidden all over a patch.
- they help you getting an overview of what data is actually part of a patch as opposed to data that only runs through a patch.
Thats already it for this episode. Liked what you learned? Insert coin: /downloads|vvvv.
Comments:
Comments are no longer accepted for this post.
@u7:
yes. all of this can be patched in one window. the concept of colors presented in the last blog post allows just that. note that in the example above we only see one “color”: dark gray (on pins and links) - compare that to the examples of the last blog post. it now should get obvious that this patch only operates on “update”. the “create” exists by default, but nothing is done here. i guess this was confusing, right? we’ll explain “create” and “update” in another blog post. just note for now: if there would be some “create” logic, it would exist in the same patch window.
getter and setter vs. framedelay. look at it this way: it is just a different style of visualization: ** getter & setter:** data flow within one frame ** vs. ** framedelay node:** data flow within one frame + data flow in between frames**
without framedelay a patch shows me which node depends on which data within one frame. it shows where the calculation ends and where the data will be picked up in the next frame. with framedelay i get a patch that visualizes both: the current frame and the connection between frames. by visualizing both, patches with framedelay blur away some useful information. as soon as you don’t follow the design pattern on how to properly use a framedelay, as soon as you start throwing framedelays in the middle of your patch, (in order to make a cyclic link), you lost your patch. your data in the one part of your patch might be framedelayed in comparison to some other part. if you now try to react on a bang or any critical frame precise information you might get into big trouble.
since vvvv is a frame based system. visualizing the frame is important. with setters and getters you finally can read your patch from top to bottom. this is what will happen in one frame.
@lecloneur,
yes, the UI is the same in terms of that there are nodes which have input and output pins which you can connect by links. but it uses another graphics library which is zoomable, so no problems in terms of space and faster navigation in patch.
what other GUI magic would you expect for better readability, cleaner patches and node alignment (besides ctrl+L)?
Looks pretty cool. But are all “setters” synchronized to being evaluated in one frame and all “getters” within the next?
If so, wouldn’t it be nice to being able to quantize the evaluation cycles independently from frames to a different pace, e.g. to create faster cycles for recursive functions? How about a “sync-to-frames or sync-to-clock” function? How about a numer of “user-clocks” for each patch? Just brainstorming..
@sven: i fear i have to make you wait for a blog post still to come, which will be about evaluation of patches like the one you see above. but good thinking!
the good news is that you can really break up your question into:
edit: soo, you basically can think in frames WITHIN your patch without knowing where those frames come from, in which frame rate or if there are different clocks. WITHIN the patch you just focus on the internals of one evaluation step (=update).
@tonfilm
It would be nice to have some kind of auto alignment to avoid random nodes positions while patching. VVVV is extremely powerful to program something very quick and even make huge project.
But then you have to spend the same amount of time to keep everything clean and readable (just in case you follow Meso’s advice about having 6 blocks on a patch, which works really well).
A snap would be also extremely useful as output and input pin are still really small. For me, it has always a little bit strange to see how organise and straight is the vvvv in the beginning. Grey square, straight line, top to bottom logic, but finally patch are always messy because it’s too much work to clean all of it.
CTRL+L somehow does the job, but now if you want to keep patch really clean you must use it all the time. And we can all agree that CTRL+L is definitely not the most “handy” shortcut :)
The “balance” between left hand on keyboard and right hand on mouse can also be greatly improved to make patching less stressful. Every actions now must start by a click on mouse, and if we want to change anything about that, it’s not possible.
Here is an example of what I’d love to make faster, avoiding line to cross too much. I spent 25 minutes to clean the camera softimage node (without making subpatches, which could improve readability) and almost no use of CTRL+L (because it align node but don’t make “straight” connection)
This “straight style” is really how I feel vvvv is by its GUI design but it’s a pain to achieve this for every patches… which I do because I’m crazy :)
hm, i think this module could be easily cleaned up using some modules. When those subpatches are named appropriate i think that improves readability a lot (more than using no subpatches at all).
to be honest, i don’t get the point, why you didn’t use subpatches here - though there’s this ’new’ CTRL+G feature. This is the same with curved lines. i use them often to make patches more readable.
imo this camera module is (in terms of programming) a rather complex thing, which in return means, that it couldn’t be represented in a really simple way. And if you’d try to code such a thing i.e. in c#, you’ll see, that this would be a much much more complex and maybe irritating thing than this patch.
i’m also a very straight patcher, when it comes to those ’layouting’ tasks. but i think it’s always worth the time to cleanup things and thereby walk through your patches with a birds view.
the only features i’m missing in current GUI is: zooming (announced) and some kind of snapToGrid (where the grid spacing should be the same as the pin spacing).
@sebl Here I didn’t use subpatches on purpose, as I didn’t really need to remake this camera module. This was just to show how it could be, and how hard it is to keep things clean and straight.
Here are some patches from C-MiX, all as clean as possible. You’re right about the complexity of a patch, but while I can align nodes, I can’t force straight lines (not talking about CTRL+Y), we could potentialy force orthographic patch for example.
I can’t choose the position of input pins on shaders, which sometimes force me to have line crossing each others. Also, the position of IOBox define the position of input or output pin of a module, but if I want to keep things tight all over the project, sometimes I must modify every IObox position from sub patche to sub sub patch etc…
When I’m teaching vvvv, at first and actually for quite a while, students only see grey lines… if I had colors for data type, I could explain the structure of the program first to anyone (especially non-programmers) and then, dive into the little function like LFO, Sift, etc… and show them how one part of it is working. In vvvv, everything is graphically equal, while it is definitely not from a technical point of view. The only thing who make difference betweens node is the amout of pins or the name, that’s for now the only parameters which change a node graphically.
you are not forced to use pairs, but if you think about it, with only a Getter you would never change the value of the property, so it would always have the default value. and if you only had a Setter, you would change the property value but no one will ever do anything with it.
this is of course only half of the story as we are talking about ‘inside’ the patch. things change as soon as other patches have access to the property from ‘outside’… but let’s discuss this case over a later blog post.
it is however interesting to contemplate a bit (while walking in the park on a sunny afternoon) about the possibilities when you have a Setter on one operation and a Getter on another…
@esnho: no, due to a limitation in the plugininterface those have a non-deterministic framedelay..
@u7: which of the information presented so far makes you seem so?