Hi all,
I’m very confused about the difference beteween class, process and a class with process “ticked”. I’ve put together a vey basic example to try to figure out the difference. There are operations in the process and class that don’t get executed and I don’t understand why.
If you could help to shed some light to a beginner, that would be much appreciated.
Thank you.
2026_2D Particle System.vl (64.6 KB)
before answering your question, let me point you to some documentation on the topic:
please come back here after consulting the above and let us know whether you can answer the questions now.
Hi Joreg,
Thanks for the prompt reply. Proabbly I didn’t word my post properly, I had some specific questions listed in the patch, more than looking for a overall definition.
I did watch those tutorials, but there is no reference to processes in those. I didn’t find the help patch particularly helpful, as all the class/record/process componenets are assigned to the create operation, while I think it would help to show a set of operations and when/where inputs need to be passed into the class for the operation or components to work ( which was one of the bugs that got me confused). I appreciate that a lot of work went into the making of the example, I’m just trying to give the point of view of someone who is learning the ropes and gets lost quickly.
I found this tutorial particularly helpful though, if anyone bumps into this post for the same reason:
To me it looks like a process node, or a class with the process node enabled in the patch explorer, are more or less the same thing, except that the class/process can act as both, so I can for example express the class operation in the main patch as independent blocks, which is something I can’t do with the process node alone. It looks like the guy in the tutorial gets more or less to the same conclusion…but then why use the process node if I can use the class+process then?
I eventually found some bugs in the patch I posted, which was probably the reason why I couldn’t understand the mechanincs of some of it. I attached the fixed version below.
Sorry for the wordy post and thanks for the help.
Paolo
2026_2D Particle System_03.vl (73.6 KB)
Yes, if you enable the Process Node on a class, it will give you a process node that, when created, runs the Create operation of your class, then runs Update if the surrounding patch is calling update, and call Dispose when the process node is deleted. If you also enable State Output, that process node will return a single instance of that class. You could then store that instance in a pad and call functions on it.
Exactly.
I see “normal” process nodes as a way to make re-usable small utilities, or delimit a clear scope for a patch. Like, if I have a part of my patch that just deals with visuals, I’d create a Visuals process node and throw stuff there. I don’t care about operations, properties or whatever, I just want to put all visuals-related stuff in there so that it’s in the same spot. You could also make it a Class and then enable the Process node on it, that would have the same result, but that would be redundant.
You can try this threads it explains what happening quite extensively Shared logic for multiple Process nodes - #8 by antokhio
I have tried a while ago to sum up key differences between Processes, Records and Classes in this thread: When to pick a Process, a Record or a Class
@antokhio That thread goes pretty deep into edge cases and advanced architecture. For someone just starting out with the topic, it’s likely overwhelming.
It is important to understand that VVVV Gamma is a real IDE and allows you to program in different paradigms using different programming patterns. This often raises questions among ‘newbies’; these are fundamental questions that concern anyone who is starting their journey in computer science in general and programming in particular.
VL cannot give a clear answer as you would like to receive it because in different situations, any of the paradigms represented by the conceptual division ‘class / record / process’ can be applied. The answer will always be: it depends on the task, the goal, the strategy. In systems with less freedom of choice, there are often fewer such questions because the system itself suggests how to solve the problem, while in the case of VL, the choice of strategy lies in understanding programming patterns and general principles of computer science.
We could talk at length about how one differs from the other, when and what to use, but in my opinion, it would be a thousand times more useful to give a broader perspective. Class is the essence of OOP, Record is about immutability, Process is the ability to use classes and records within VVVV Gamma as full members of the visual architecture. If there were no processes, you would have to program exclusively through the creation and evaluation of objects, which in some cases, by the way, is very appropriate and which you will often see as necessary when connecting third-party and not-vl libraries via nuget.
Imagine that Process does not exist. You would have to manage the creation of the object yourself, perform operations on it, and make sure that the object itself is saved and cached somewhere. I would like to omit the details about mutability and immutability here (I think you can figure that out on your own), but the ability to include a ‘process node’ in Record and Class is simply inherent in VL’s architecture — nodes can be created at runtime, automatically triggering an update during execution. It’s something like a contract between objects and the environment where you use them: you can always abandon this contract in favour of some other strategy, but in visual programming it is often convenient to link nodes together.
However, I want to emphasise that behind this simple explanation lie many small technical details that cannot be explained without specific computer science terminology. And often, in such explanations, the level of the listener is more important.
By the way, I opened your initial patch.
What I can see is that none of the classes in which you would like to use the ProcessNode functionality with ‘State Output’ have a ‘process’ (or ‘function’, if you prefer) called ‘Update’.
In other words, one of the main elements of the contract between the node and the runtime is simply not being used. In the ‘ParticleClassWProcess’ class, nothing actually changes the position or radius, which are only updated during node creation.
In the example inside the patch where you use Create in foreach, you create an object EVERY FRAME, which puts a significant load on the Garbage Collector (but again, that’s mostly a computer science issue). Thus, ProcessNode allows you to execute Create ONLY ONCE when loading the patch (It can be recognised by its white inputs). You then need to use Update to ensure execution every frame. You can ‘expose’ other ‘functions’ or ‘operations’ so that they are called at runtime. However, please note that as soon as you disconnect everything from them, their inputs and outputs turn grey, showing that the ‘operation’ is not being executed.
2026_2D Particle System_DoneRight.vl (78.6 KB)
Most likely, you wanted something like this. I will also mention again that the ‘Update’ operation has been added and is being used (‘Operation’ is similar to ‘Function’ in OOP).
Thanks all for the replies, a very educational Thread :).
@yar thank you for the review of the patch, I did post a second version that caught the majority of the bugs you highlighted. @antokhio thanks for the reference to your previous thread…it’s a bit too deep for me at this stage, but I’ll come back to it in the future for sure.
