Since a while, VL comes with the idea that you can organize node and type definitions in your VL document.
We have one “Wheel” definition, independent of how many we need in the end
But now, we want to give you back another, alternative way to look at things - an organization structure, which is more intuitive and also well known from vvvv beta: The application side of things…
See how one wheel instance is rotated and the others are not
And also, we did this in reaction to the feedback we got from Link festival:
You want to be able to navigate the running object graph, where it’s about the instances of patches, not about their definitions. You want to be able to navigate into a running patch and see the values that flow in this instance, not in another instance of the same patch…
Also, typically you approach your project top-down and just add more details to it since this is the basic idea of rapid prototyping: patching a running system that you incrementally grow and modify.
So we took the chance to shift the focus a bit so that in VL you again get confronted with the application side of things first.
The Application Side of Things
This is what you know from vvvv beta: a patch can contain a sub-patch - you navigate into it and inspect the values flowing. You go outwards - to the caller - via “Ctrl-^”. With the ^-Key we actually refer to a key at a certain position on the keyboard.
On your keyboard it may be labeled differently
In VL this now is just exactly the same. Navigating into a process node shows you the right values. Ctrl-^ brings you back to the caller. So you are basically navigating the living node tree of the application. In VL it’s been hard to think in these terms, but now it’s the default. We also made sure that this works when navigating between vvvv beta and embedded VL nodes.
Also, try to use the back and forth mouse buttons if you happen to have a 5-button mouse. Ctrl-MouseBack will bring you to the calling patch and Ctrl-MouseForth will travel back into where-ever you were coming from.
Every VL document comes with an Application patch, which will open by default. You can start patching right away. A bit as it is like in vvvv beta.
Patching top-down never has been easier. Creating an Ape simulation from scratch:
Clicking Node will create a new process definition, name it and instantiate the node once
You can run many applications at the same time, e.g. several example patches in addition to your project app. The application menu lists all documents that actually make use of the application patch.
The Definition Side of Things
Definitions in vvvv beta basically correspond to the .v4p files, in VL you can have more of them per document.
Library developers or more advanced users will of course still want to organize types and nodes and approach them from the definition side. This is like saying “There is one idea of a wheel, but if you feel like you can instantiate three of them”.
For an overview of the definitions, each document comes with a separate Definitions patch - basically what’s been the document patch.
Here you see what happened during patching top-down: on the definition side, we now have two Processes.
The Definitions patch gives you an overview of your document structure
That’s where you would from now on also place your Classes, Records…
Navigation within the current document structure works with Ctrl-Shift-^, Ctrl-Shift-MouseBack, Ctrl-Shift-MouseForth.
When navigating into a patch like that you will see some instance of the patch or maybe none, if none is instantiated or currently running. In this case, you will not be able to see any values.
If the patch is not yet inspecting a particular instance it will wait for the moment an instance gets executed and then attach to this particular instance.
Some more minor cleanup
We took the chance to clean up some bits in the node browser and the patch explorer as well. The application patch e.g. now doesn’t offer confusing options, but basically only shows the properties stemming from pads, the Process Node Definition now is called that way (was “Order”), Process Nodes in the node browser look a bit like process nodes in the patch, choices like “Input”, “Node” appear at the top of the list of choices in the node browser…
That should be it for now! Thanks, yours devvvs
Comments:
Comments are no longer accepted for this post.
totally forgot about the following:
Alt-P : Application Patch Alt-Shift-P : Definitions Patch Ctrl-P : Create Node At Cursor (Application + Definition on the fly) Ctrl-Shift-P : Create the Definition only
so basically. for all the mentioned shortcuts (including those in the blog post) work with the same idea:
Shift + SameShortCut -> Similar command on the definition side
@mburk: also working on other things that we were certain are basic ingredients for an authoring env.
so yes, the feedback from link is still guiding us in prioritization and focus.
very cool.
can you add a call stack breadcrumb trail as well, so we don’t need to go up and down the patch hierarchy just to find out which instance we are actually dealing with at any given moment?
as a clarifying use case: imagine having not only your ape, but also a ModelT and a 4x4, all relying on the same definition of wheel. when looking at any wheel, you would want to know which car’s wheel you are actually dealing with. as of now, this information is only accessible by actually navigating up and drilling down again, instead of getting that info straight.
sure. this was just the first most important step. note however that a breadcrumb ``` ape->wheel->rubber
ape->front wheel->rubber