It is obvious that Grouping nodes (old beta way) is absolutely needful +1m here
2 Likes
+2^MaxInt
2 Likes
6 Likes
+2^MaxInt+1
3 Likes
Por favor!
Bump. I would also like the option to group those nodes into a static operation, so a sub-menu looking like:
Extract to ›
Process Node
Operation
3 Likes
Another refactoring session, another bump :-]
Pleaseplease thanks!
EDIT: and yes, picking whether to extract to Process Node or Operation would be massively handy!
6 Likes
Check latest preview - Ctrl+G packs selection into process, Ctrl+Alt+G packs it into operation. Feel free to report any issues you encounter.
10 Likes
that feels so good again, thank you!!
a thing that might appear funny or counter-intuitive is that - because the pin names are derived from the connection outside - input pins will oftenly named output and output pins input
Indeed - while developing I had it the other way round and also ran into confusing cases. Maybe a stupid heuristic like don’t call an input output and vice versa should be added. Or when trying to infer the name just don’t take those generic names into account at all.
Update: Yes that feels better, coming up.
5 Likes
First off, massive thanks for implementing that one, that will ease refactor sessions for sure :-)
For anyone using the Google Drive application: by default, the app steals the CTRL + ALT + G shortcut. Pressing that key combination in vvvv with the Drive app open in the system tray will open Google Drive’s search overlay thing (that I did not even know existed btw) and vvvv will only “see” a CTRL + G. You have to go to the Google Drive settings and disable the Search thing (or set a new key combination if you actually use that feature) :
Then you’ll be able to pack to operations :-)
Thanks again!
EDIT little OCD question: why does it break node alignment when I pack to operation? :D
Just kidding, no big deal there of course, I actually like aligning nodes and see them snap.
1 Like
Really great, thanks!!
The only thing I’d like to suggest, is that the Process appears on the Definitions of the document.
1 Like
I’m not sure about this.
I think it makes more sense to get track of this easily, and the most convenient way is to create the Process or Operation in the same view, then the user can place them wherever needed.
+1 !
I’d prefer the current behavior as it does not assume anything and lets me move the definition wherever I want to.
Seeing instantly where the node definition lands feels “snappier” to me than having to go back to definitions of the current document to move it somewhere else.
1 Like
Whaaaat? I did not expect these reactions at all. When discussing this we should always take into account how to introduce new people to principles, and I thought it should be obvious what the correct way of doing this is? Correct as in - definitions go to the “Definitions”? Putting a definition on the Application side is not correct, is it?
1 Like
And also the “Node” entry in the node browser does the same thing…
A setting maybe? My personal preference is also to place it right into the canvas I’m working in. Being able to refactor and only then move everything where it’s supposed to be feels nice. And sometimes such refactorings might also have a rather private nature - such operations / nodes might be used only in that one patch, so why move them out? Ideally I could even mark them private so they wouldn’t bother me in the node browser later at all when outside of that patch.
If we make a setting question will be what it defaults to ;)
I’m personally not so rigid about that. Yes, most of the time I’d put definitions in the Definitions, but
- I also often put static operations in class definitions
- Also often putting definitions in a separate document that’s not the document I’m currently patching in
- In ImGUI patches I often put sub-patches definitions in the UI patch itself
Of course newcomers should know about the Definitions part of a Document, but I also don’t necessarily consider it a bad pattern to put definitions elsewhere, especially if they’re internal and not meant to be shared/used elsewhere.
That’s my take on it, but I think the lesson learned should not be “strictly do this or that”, but rather understand when it makes sense to put stuff in the Definitions part of a document and when it’s not necessary/more handy to have it elsewhere.
Sometimes vvvv can feel too flexible because it lets you do anything, and having important/core Definitions scattered all over the place is of course a terrible pattern. But at the same time feeling forced to put everything in Definitions just “because” feels counter-productive to me.
This is exactly why I never use that feature 🙃
3 Likes
Also not a big fan of creating “Nodes” in definition, and I never use it.
It feels better having a visual feedback in the same window we are working on, mostly when the system does something for us, like creating Processes or Operations.
In other words, what @sebescudie @Elias say.
If the devvvvs decide to make an option for it, I would say that the default behavior should be the easiest to track, creating the Node close to the action in the same window.
I would propose the exact opposite. It depends on what you want people to know from the beginning. I think letting people know that the Definitions side are where this should be stored normally is very good.
I am actually also a fan of the thought to not let process or record definitions to be stored on the Application side at all… it just does not fit the concept IMO. It should be taught that this is not where this should be stored to, because otherwise people won’t learn where to find that stuff in more complex patches of other people.