This post is to discuss possible usability-related changes to VVVV, spawned off of this thread: https://discourse.vvvv.org/.
VVVV’s user interface and general structure is minimalist as a matter of principle. This itself is a good thing (to me, anyway). However, there are a number of changes and additions which could be made to improve the usability of the application, particularly with regard to editing patches. Many of these have been discussed in scattered posts and comments on the forum, so this thread can be a place to bring them all together in one place for discussion.
Categories:
Configurability
Patch/asset management
Patching shortcuts
General UI enhancements
Configurability
This sort of thing is an important part of how I use development tools in general. In some ways you can currently do this sort of thing by putting nodes in your root patch an tweaking their pin values (such as VVVV (VVVV) and the other nodes in that category). However, this is somewhat limited, and doesn’t work well if you use separate root patches for different projects.
Configurable keyboard shortcuts. This tends to be fairly simple to implement, but can provide users with a much greater sense of control over the application. This will also allow users confused by some of the non-traditional keyboard shortcuts (ctrl+N = new node browser?) to change them to fit their own expectations.
Configurable defaults for newly created nodes, including things like setting default pin values and default visibility of pins (I usually don’t need the _ Epsilon_ pin of = (Value) ), etc.
Patch/asset management
Almost all of the work that I do in VVVV is organized into projects. These are usually each stored in their own directory, with a single “main” patch and a bunch of modules, data files, effects, etc. Adding some basic file management features, and direct support for the concept of “projects” would make this all much easier. The ProjectExplorer (VVVV) node is definitely a step in the right direction, but it is focused on effects and plugin/visual studio projects.
{new} Collect files / save project. You could address the issue of dynamically loaded assets by having a project file where you explicitly define which files/directories are part of the project. That way you could just say “include everything in awesomeimages/”.
Patching stuff
Some sort of UI for a customizable list of common snippets of patches
** {new} QuickNodes appears to provide this functionality in a basic sense (and I really need to start using that). It would be nice to be able to provide it with more than just a list of node names, and to be able to have it include groups of nodes. For example, inserting a RandomSpread hooked up to an LFO, etc. Maybe that could be accomplished by telling QuickNodes that an entry in its list is to have a modules contents inserted and not just a node that references the module.
** {new} It may be possible to implement this in a patch using the windows Clipboard nodes.
Node linking shortcuts, such as “connect the first output of the selected node on top to the first input of each of the selected nodes on the bottom”, and so on. Users of Max/MSP may be familiar with the Max Toolbox (http://code.google.com/p/maxtoolbox/), which implements many of these sort of behaviors.
more configuration of the application in general… maybe including the ability to enable/disable window close buttons, etc
{new} Anonymous (within another patch) sub-patches. My person approach to this tends to be to use namespacing like myproject.scene1.calculations.v4p for modules that are only used within the myproject.scene1.v4p patch (I tend to use non-standard naming conventions for my project-specific stuff, which also helps differentiate it from shared modules).
{new} Pull the selected nodes into a sub-patch or module without breaking their connections to other things… this could be implemented for normal file-based modules by popping open a save dialog for the sub-module when you do it.
{new} Grouping nodes.
** Yes. We need this… or at least some way to visually indicate it like the panel idea. Having the nodes actually be stuck with each other would be much more useful than just having a colored panel behind an area of a patch. (but having both features would be even better!)
** see also: https://discourse.vvvv.org/t/8412
** possibly other kinds of visual cues to indicate groupings
{new} Ctrl+tabbing in full-screen to show renderers etc while editing in fullscreen mode (may currently be possible using ctrl+T to stay on top, etc)
General UI enhancements
Zooming (which I know supposedly exists, but I’ve never seen it work)… possibly with ctrl+mouse wheel? … or configurable?
Specialized, persistent non-patch windows, menus, etc. I have customized the root patch that I use to always have a Inspektor (VVVV) on the top right of my screen, and a log display patch that I made (which is somewhat buggy) on the bottom right. If the project/file management window discussed were added, I would probably want to have one of those open almost all the time as well. The current concept of “everything visible is either a patch or a detached render” is really really useful when running patches/performing, but not so much when editing.
IOBox label transparency / configurability (show on top vs bottom, etc)
Panels with borders and background colors that can be placed in patches to visually group together areas of a large patch.
{new} Larger (or configurable?) mouse snapping area for selecting/connecting links/pins.
{new} Optional snapping of node placement to a grid. I really like to have this option in any kind of diagramming/patching software.
So, that’s just what I’ve come up with and what I’ve encountered in the forums, but there’s probably a lot more. The past few releases have been focused on the performance and reliability of the engine, and the addition of new nodes, etc. This has been excellent. Perhaps the next releases can take a break from optimization to make some of these improvements.
Here is my first go at the moment, will come back later if i get some more idea :)
into Patch/asset management
Collect files - It would be great to have a feature to collect all the files used in a patch to save into directory, this leads to constant folder structure for all patches/project + wont be any missing files/sub patches even by accident.
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.
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 https://discourse.vvvv.org/t/8412, 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
Quicknodes
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 :)
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.
@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.
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…
