VL Interface

vvvv beta question
1

Hello Devs,

i tried to use VL recently and actually failed.
It is a great piece of software that enables lots of possibilities, but the joy of patching in VL becomes frustration due to the – to me – not understandable interface.

I haven’t figured out now, how to really close a patch in VL. Middleclick works, but when clicking the left button those patches reappear again – whats the reason behind that. Why is there a drop down menu next to the left arrow, that shows me vl-documents of which i closed the patches recently?
And how do i actually close a VL Document? The menu just offers me to save it but not to close.
Furthermore is the “Quad Menu” is missing a quit entry?
That patches are shown right to the arrows, that are not part of the VL-Document, that is written left to the arrows seems confusing.

I haven’t understand the Dependency section yet. When clicking on the Menu (Not the Quad Menu) i can chose the Dependency entry to link Dependencies but there are already some Dependencies shown in the lower part of the menu. I can right click them, then i can save them – what do i save? – why are they there. I don’t understand. The Graybook does not offer the answers.

In general there is no real distinction between interface elements and patching environment which might be okay but leads to confusion too.

But the most frustration thing is the Node-Browser. The Node Browser is a core element to the patching workflow and honestly yet for me seems very difficult to use.

  • Why is it possible to scroll further than the last node?
  • Everything is in the same color, which reduces the readability.
  • So many new symbols and icons, that are explained nowhere.
  • Lots of submenus inside the node browser which make it very hard to navigate.
  • The transparency is nice but irritates when there are lots of nodes in the background.
  • The text is cropped sometimes.
  • Everything is in the same font style – would increase readability if in the description, node names would be bold and the description regular, or something like this.
  • There are dependencies shown, that disappear after they get clicked – is this a bug (for example LEAP etc. they have a crossed icon before them)?

As i understand the Node browser only shows nodes from the linked dependencies, but the big convenience of VVVV was that everything is available at every time and i never had to think about what i need for a project beside the packs and contributions.
I appreciate the mechanism, but i seems that such an approach needs a proper project managing tool, where you can set the dependencies already at the beginning and define templates etc.

I haven’t understood the “mouse interaction” in a patch yet. Sometimes a middle-click opens a menu which offers layout options but most of the time this menu does not pop up.
I’am missing the double right-click to be honest.

Adding the VL blogposts to the graybook could be useful at the moment, cause i think all the new link colors - that i haven’t understood - where described there once., if i remember it correctly.

Dont get me wrong, VL is a great tool which i actually would really like to use at the moment and integrate it into my project but i just dont understand how to patch in it. The Graybook at the moment describes lots of the functionality but lacks, where it is about the workflow of the software.

A video of how to start a basic VL-Project would already be massively helpful.

Best
d0t

1 Like
2

hei d0t,

thanks for your time investigating vl and reporting on your findings. sounds like all valid points that can be explained/improved one by one.

as mentioned in the release blog we are still (and will always be) working on UI consistency and understandability. things evolve, new features that may change workflows, will be added and need adaptions. the nodebrowser is indeed an incredibly central and complex part that i’m quite sure will need a few iterations until we get it right. hope you can bare with us.

videos on individual topics and more answers to your questions will follow. am on mobile atm. stay tuned!

1 Like
3

same situation here

4

Hi Joreg,

thanks for your reply.
My only concern at the moment is, that i think that VL introduced quite an amount of complexity into the well known, convenient VVVV patching environment.
This complexity has to find its counterpart in a well designed, easy, supportive and helpful interface to handle those complex tasks. Otherwise, one of the big benefits that VVVV offered to “non-programmers” seems to vanish.

But yes i’m sure you are aware of those issues and i will stay tuned, as always.

Cheers for viers
d0t

1 Like
5

I have to also raise some concern, you use some new terms, that probably makes sense if you come from a programming background, but is a little confusing for outsiders, to start you might want to over explain terms until we all become more clear of what the mean.
Also it would be good to know what kind of things vl should be used for that are better than doing in patches, I can already see, that dynamic things like multitouch should be much easier, but a rough guide of when to consider using vl over vvvv would be great. In vvvv I can start a patch and simply sketch something then refine it, whereas proper programming tend to be a more decide what your doing before you start. I’m also missing the inspector, if only for seeing data flowing through the pins, what the pins are, and a description of what the node does, also multiple patch windows, I’d like to be able to see a sub vl patch at the same time as the patch I’m working in, so I can visualise whats happening inside those parts too.
Good news is I opened a monster patch and it all worked, and ran slightly faster, so happy days :)

1 Like
6

of course check the introducing VL section here: vvvv_50beta35 | vvvv

basically whenever you are running into bin size/index mayhem is a basic rule. for example if you want to keep data of multiple spreads together in one package (data type). where slices can be deleted or created on any place in the spread.

and naturally, if you want to make entities that can be created and deleted, have a certain ‘intelligence’ and can do stuff on their own. a quick youtube search gave me this 5 min video which explains the basic principles of object orientation very well without going into any specific language. there might be hundreds of such videos, most use the term ‘method’ instead of the VL term ‘operation’.

having a data inspector is not a trivial task because what you are actually patching is the blueprint or definition of an instance, as the video explains with class vs. object/instance. as soon as you create multiple instances the question arises which instance do you want to observe? so there needs to be a way to choose that. if you only have one instance running its easy and you can use IO boxes to help you out for now.

7

hehe, so basically my monster patch should be remade… Well that’s going to take a little while! But is vl by default less processor intensive when doing this, or am I going to have to compare and contrast, currently I have a lot of evalutates and or’s to get when data has changed
The inspector could have an index pin?
I’m sure I’ll get used to it all, just going to take some time when I’m not deep in projects…

8

yes, definitely vl is much faster. the .NET JIT compiler can do all it’s optimization magic on a VL program and if you don’t call operations they will take 0 CPU power. so you can build huge patches that do not use any CPU at all if nothing is called. check right click menu → configure → ‘Show Apply’ to expose the pins to enable/disable an operation.

if there is only one spread of the instances yes, but in theory there can be instances all over the program. so its actually more a tree like structure where one instance or one spread of instances are special cases of it.

9

regarding the inspektor - instance problem: i had a similar problem with automataUI when spreaded. VL could also show the values of an instance selected by index. this would be quite useful to debug things.

10

ouright, let me try to clear a few things up:

a patch is closed by a middleclick (or the middle-click alternative: ALT+leftclick) on its tab (just like you would close a tab in a browser). since VL distinguishes between patch and document, this does not close the document. closing a document is not yet possible and shouldn’t be so relevant really. for now if a .vl document is not referenced, it will not be loaded on next startup of vvvv. regarding “Quit”: just like the hlsl- and c#-editors, the VL-editor is an integral subsystem of vvvv and as such can not be quit. In order to close the editor simply use CTRL+W as with any other vvvv window.

with “left button” i assume you’re referring to the “back” button of the Navigation Menu which lets you navigate back and forth between the tabs you activated. the pulldown of the back-button shows the history of tabs you had activated and allows you to jump to a tab directly. and yes, closed patches are still part of that history by design. once you’re used to navigating back/forth between tabs you’ll understand that this is the desired behavior.

what you refer to as “dependencies shown in the lower part of the menu” are in fact not dependencies! the submenu “Dependencies” is where dependencies are. the documents you refer to are in fact simply other documents that are loaded at the moment. we’re aware of the confusion this is causing and will rework that listing… anyway you can click any of those documents to open its document patch, if you want to work on it, or inspect it… a rightclick->save will simply save that actual document. no strings attached.

regarding the NodeBrowser: all valid points, still needs a lot of fine-tuning. only one thing regarding your last point “dependencies”: the entries with “crossed icons” (like VL.Devices.Leap,…) are packages/nugets. selecting e.g. the LEAP nuget does in fact set a reference to that nuget as you can check by navigating to: Document Menu > Dependencies > Nugets where you’ll see it now as “checked”. and yes, a referenced nuget does no longer appear in the nodebrowser because you now have access to the nodes it brings you. if you want to get rid of the leap nodes again you can uncheck the nuget in the dependencies.

just a general link for now. all mouse/keyboard interaction is collected here: Keyboard Shortcuts | vvvv gamma documentation

hope this helps a bit. still more to come…

11

Hi Joreg,

thank you for your detailed answer.
Still, i think that you can’t close a vl-document is quite confusing. Because even though if you close the vvvv patch, which contained nodes from a vl-document, it does not remove the vl-document and patches from the vl editor. This leads to quite an amount of not used vl-patches in the vl-editor what will accumulate over time i think. At least thats what i experienced.

Sure the vl-editor can’t be closed but a way to remove unused patches of vl-documents from the history would be good i think. But maybe i haven’t understood the usage properly yet.

12

Given the missing inspector, I think we could do with more human tool tips for nodes rather than simply their code.reference.something like a quick description of what the library does, or where to find info about it. Currently I feel like its too early to simply start trying to learn VL as it feels like you need knowledge that isn’t currently available outside of your office, otherwise it will just be an endless series of forum questions of how to do the most basic things, and then wait for a reply, which is a bit long winded.
eg I’ve just opened MenuDemo, and I’m lost just looking at it, hover on a node, and I’m none the wiser of what is going on!
A weekly video tutorial maybe?

13

yes please

14

tooltips are indeed partly a mess but i can encourage you to still try because some nodes already display some actual help-text.

please don’t stop those, they are really helpful to understand what we need to prioritize in documentation.

and regarding tutorials please watch this space: tutorials - Forum

15

please check with latest alpha, which has the mentioned change in the menu in place. note how the long list of open documents is now hidden under Quad > Documents. this is mostly for completness and you’ll rarely want to go there. in the document-menu you now only see other documents that have open tabs.

and still: yes, at some later point you’ll of course be able to close/unload vl documents. it is just not yet very high priority… hope that makes more sense now.

1 Like
16

basic tutorial on interface for vl, types of regions and data types would be super cool, for instance I want to make a bang and I didn’t found any way doing it ;)

17

absolutely. more tutorials are coming. meanwhile: middleclick an iobox set its type to Boolean and then you’ll see the option to switch it between being a toggle, bang or press…

18

guess it’s on the alpha all see here is this:

19

ah, what i meant only works for IOBoxes so far. i’m afraid you cannot yet set the subtype of an input to bang or press. still to come…

20

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.