VVVV Usability

A little bit in the same catgory, I have been thinking about ‘private’ subpatches, that are simply saved in the same file, but are usable as ‘functions’ in that file.

That way you wouldn’t need to create so many different files, where it often becomes unclear who/which patch uses them.

I think in software development, there are 2 reasons for creating functions. The first one, is to make code reusable. The second one, is making code more readable, so it would be great to be able to make very readable patches by having only a few nodes with a long and clear name and a few connections. But a lot of these would only be useful, within that patch.

Hope this makes sense. Since it’s all xml, it wouldn’t really matter if it were stored in a different file, or in the same file. Maybe a slight color variation of the node could make clear that it’s a ‘private’ node.

automatic file collection might work in programs like after effects but how is vvvv supposed to known if assets are not directly linked in a patch. imagine dynamic paths/filenames fed into filetextures…or asset paths coming from a database. the file collector cant be prepared for such cases

what would be helping is a central asset management tool, helping with preloading and unloading things. but then again, there are tasks which need special solutions in handling assets which a general asset management can’t provide. maybe the openness of vvvv does not go well together with some ease of use concepts.

My wish: The whole (G)UI rewritten as dynamic plugin(s), so every element can be customized to one´s personal needs from within vvvv itself, as seen here.

pfiou… what a result ( art work)!

Do you think grouping nodes can help in working faster and making cleaner patches? You group some nodes. And then if you move one you move the rest of the group.

into Patching shortcuts
When i choose to work full screen on vvvv it makes use of complete screen and i find it very convenient. Would be nice also to pop the render window using ctrl+tab in full screen mode so we don’t need to exit full screen mode and focus on patching.

into Patching shortcuts (let’s follow urbankind example!)

@ventolinmono I agree. I posted this request, but didn’t get much feedback on this. Anyways it would speed up the cleaning and the making-more-readable of the patch.

into General UI enhancements

This is a little one, what do you say of a bit larger link\pin snap area? Sometimes I’m really near, click on pin and then I found myself trying to link Inspektor window to the node.


  • i think at least some of the mentioned improvements are already there or can be achieved otherwise:

When i choose to work full screen on vvvv it makes use of complete screen and i find it very convenient. Would be nice also to pop the render window using ctrl+tab in full screen mode so we don’t need to exit full screen mode and focus on patching.

press CTRL+T (stay on top - indicated with a ° ) on your renderer, so your patch-window can go bigger and your renderer lies above

Some sort of UI for a customizable list of common snippets of patches


  • some things from the wishlist are kind of implemented, but “buggy” (e.g. zooming)

  • some things would be quite handy imo but surely need a while to be coded, tested and finally released. (e.g. collect files/assets) if i had to choose what the devvvvs do all the days, i’d let them implement new features…

  • some things rely on (very special) individual flavours (e.g. Node linking shortcuts) – the only way i see to solve those problems for “every” user would be bjoerns proposal that will bring some other benefits imo (e.g. more features like scaling/transparency/colouring, more controlable performance and perhaps more continous development because more people can code on that stuff)

so, i go with bjoern and would vote for a rewritten interface in c# – even if there are less features than today

into Patching shortcuts
@h99 : Regarding grouping nodes, we need some visual cue of link metaphor to identify the grouped nodes and i suppose that maybe not easy to implement.

I was thinking how about saving selection(selected nodes). Just like ctrl+tab pops explorer another shortcut assigned to show saved selection? we choose the desired group and bingo…pretty much same result of grouping visually :)

just a hint:

if you copy/paste a selection of nodes vvvv makes use of the windows clipboard.
using some (custom) clipboard manager you could save your favourite snippets and paste them into your patches.
using Clipboard (Windows String Get) and Clipboard (Windows String Set) you even can build your own snippet manager…

@@Urbankind Oh, I’d bet would be a hard piece of code. Then: visual cue could appear when hovering on a node of a NodeGang as color changing (pins, body, both).
Saving selection is (ah! You and your synthesis gift) what I’m looking for, but I think it would be more fast and useful if it has automatic behav (Hover -> Uh, I’ve already linked them -> Ok let’s drag up there \ instead of \ Combo -> Search for selection -> Do I have ganged them? -> Wait for visual cue - what happens if you don’t remember where is that specific NodeGang, or if this NodeGang is outside the screen? - -> Ok let’s drag up there).

Then to vanquish a NodeGang select just one of them and vvvvanquish.

I have updated the original post with ideas from the comments. Let me know if I misinterpreted your ideas and I’ll update the list.

@thezer0ist: Misinterpreted? No. I trust our folks appreciate your effort in writing this up as well :). It’s really a nice that you updated the original post, now it’s more clear than before.

into Patching stuff
Renderer doesn’t stay on top when i go full screen mode of the patch window. ctrl+T works as long as windows are in normal state. Alternatively we can Alt+2 to see the renderer docked inside patch but it would be just handy to pop the floating window of renderer popped on fullscreen mode as well.

How about presets for node parameters? Would make sense for modules/nodes with many input params (like IOBox (Value Advanced) for example)

I was thinking about something similar lately…like having a special inspektor for saving/loading presets…like in reaktor…but not sure if this make sense ;)

@unc : Presets for parameters of newly created nodes is part of what I meant for the “snippets UI” thing. So you could have a list of “snippets” some of which could just be single nodes with specific parameters.

@Desaxismundi : I think you’re talking about something slightly different, but still really useful. If I’m understanding you correctly, you mean being able to save sets of values for a bunch of IOBoxes in a patch and then load them up later. This is similar to the ‘preset’ and ‘pattr…’ objects in Max/MSP, or the preset feature in Reaktor. I have spent some time investigating what it would take to write a plugin to do that, and this is what concluded:

  • It would be really really really difficult if not impossible to do it in a plugin, given the current structure of the plugin APIs. I was unable to find a way in plugin code to set the value of a pin on another node. It’s possible that with some changes to the native core, this would be possible.
  • You could sort of do it using SetPatch (VVVV) , but it would be messy, inefficient, and error prone.
    … that said, I would really really like to have that feature. I think it would require changes to the native core… which maybe we can get the devvvvs to do…

That’s it! Nicely said:)

That’s why I said I didn’t know if this would make sense with the actual logic of vvvv to have this hardcored.


check this: patchlet-(vvvv)
save your favourite patchlets as patches in a specific folder.
this new module calls a filedialog which loads the content of the selected patch into the clipboard.
now just CTRL+V into any other patch.

I was wondering… why double right click for creating an IObox when we have a single right click with no dragging free? (although that would be part of the proposed suer defined shotsuts, it could even go for default)

you might want to check out vvvv-sdk PinServer branch: direct writing & reading pins.
and talk to vux and joreg since they are already writing something which might go into a similar direction.