Hey! As it came up yesterday in the chat: I think the shortcut from beta to group nodes into a subpatch or rather a Process (like it’s called these days) is badly missed.
The UX is pretty straight-forward here I think - select nodes, Ctrl+G and then a process with all inputs and outputs is created on the definitions of the document.
In my opinion it is also a great narrative to introduce the definitions side, by explaining where the process has gone after grouping nodes.
Bumping that request :)
Lacking this feature makes refactoring ImGUI patches a uselessly massive pain.
I join the choir chanting for this to happen
Yes, missing a lot this Ctrl+G shortcut from Beta.
As well as the ability to Evaluate or not a subpatch/process.
You can already do that on process nodes, per-operation.
Here the Toggle is enabling/disabling the
Update operation inside the process that just logs an LFO to the console.
If you create an operation in a Process Node that does not have input pins, vvvv will give you this
bool input that you can enable or disable from the outside to run the operation or not.
If you create an operation that has input pins, you have to right-click/configure the node to show the bool that controls whether the operation runs or not.
LogSomeString operation inside the process node. It has an input pin, so soon as I connect something to it it starts running.
But I can also enable the boolean input that allows to control whether the operation runs or not from the outside, as can see there :
Great, thank you for the explanation!
As you mention it, you have access to this Update bool input only if the node doesn’t have any Input/Output pin.
Is it possible to keep the Update pin somehow when using an input/output pins?
Yes, it’s this
Show Apply ___ optional pin I was mentioning.
You can enable it with a Right Click/Configure like for any other operation.
That works with Input pins, but as soon as I create Output pins the Show Apply Update disappears:
Ah, yes I guess that does not work anymore because if something is connected downstream then disabling this operation could have side effects…
I would suggest writing the result to a pad and create an operation that just reads from that pad. Like that you can disable the operation that writes to it, but the result would still exist if someone needs to consume it downstream.
For such a case I would surround the node with either a
ManageProcess region, an
If region, or a
Ah yeh, why complicating things? :)