Dear pointmovers,

from now on you can translate, rotate and scale way more faster.
There is a Gizmo for that.
And every Editor in our EditingFramework has it inside.

• Press 'g' to turn a Gizmo On/Off
• Pick and drag its handles to transform the points
• Hold 'Shift' for uniform scaling
• Nudge points with arrow keys

The Gizmo is working in both DX9 and DX11 worlds.
See Editor's helppatches.

Nothing more to say.
Easy.

Available in the latest Alphas.

Here is something really great. The new Reactive category gives you tools to handle asynchronous events, background calculations and even enables you to build your own mainloop that runs on a different CPU core. But let's start with a pragmatic explanation of what it is:

Since a while VVVV and VL use these so called Observables to handle external events (i.e. mouse, keyboard etc.) and asynchronous data. This was mostly under the hood and the actual operations for observables are hidden in the VL.DevLib. The reason is that out of the box the operations do not go well together with the frame based Update concept of VL because they are intended to be called only once or when something has changed. But as of now we have wrapper nodes for the most common observable operations that do exactly that, listen for change and only rebuild the observables when necessary.

Processing events

The go to node for handling events is definitely ForEach Region (was Region (Stateful) in earlier versions) in the category Reactive. This region allows you to place any node inside and can also remember any data between two events. There is also one with version Keep that can filter out events using a boolean output. This region is very similar to the ForEach region for spreads, only that its input and output is event values in time instead of slices of a spread.

You can switch or merge event sources:

There are also filtering options with OfType or Where:

Other nodes include Skip, Delay, Delay (Selector), Scan, Switch, ...

Receiving events

If you want to leave the observable world and pass event values to the mainloop use one of the 3 nodes HoldLatest, Sampler or S+H which all behave a little bit different. Depends on what you need:

Creating events

It's also pretty easy to generate event sources of your own:

As a general advice, only send values of type Record as event data because they are thread safe. If you send values of any Class type be sure that you know exactly what you are doing.

Observable<Observable<T>>

Yep, totally possible and has useful applications. But i am just gonna let this idea sink in for now...

Further reading

The above just scratches the surface of whats possible with the reactive framework. If you want to know more browse some of the following links:

The pragmatic Rx expert from the quote above:
2 minute introduction to Rx

Visual explanation of the observable operations:
Operator Reference with marble diagrams

Videos from the creator team. Note that IEnumerable is called Sequence in VL and Spread is also a Sequence:
Erik Meijer: Rx in 15 Minutes
Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 1
Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 2

For coders:
Introduction to Rx

ahoi,

one of the more basic things any programming library has to support is parsing and the creation of XML data-structures. since vl is based on .net we don't have to invent anything here but can make direct use of .nets XDocuments, XElements, XAttributes datatypes. so we're happy to announce that in cooperation with dominikKoller we added xml/json support for vl:

• read/write (async) XDocuments from/to disk
• parse an xml-string to XDocument
• convert an XDocument to an xml-string
• join/split XDocuments, XElements and XAttributes
• use XPath, XSLT
• check for validity against a given schema

plus:

• read (async) JSON files from and get and get them as handy XDocuments
• write (async) XDocuments to disk in form of a JSON string
• parse a json-strings to XDocument
• convert an XDocument to a json-string

so basically anything you could already do in vvvv plus some more. and this is only what we brought to the surface for you. using the underlying .net datatypes (XDocuments, ...) directly, a pro-user will (later) easily be able to use the whole range of functions that those datatypes provide for more advanced use-cases.

so, once again, something for the whole family..available in latest alphas now.
gut patch!

previously on devvvvlopment: vl-networking-and-async

With beta35 (including VL) out in the wild and people apparently starting to use it (see forum threads about it) we're quite happy with the feedback so far. We know of people already including VL in their daily patching and getting the hang of it. Others are still more cautious and are waiting for better documentation or are hoping for node17 to open their eyes. All fair enough, no pressure.. in any case the question is of course:

What next?

One of the many aspects that vl will be different when compared to vvvv is its node-library. In vvvv we have a closed-source base-library (written in delphi and closely bound to the vvvv core) plus a wide range of open-source nodes including community contributions (written in c# via a plugin-interface). For vl we'll still distinguish between a base-library and the rest, but all libraries will work the same way, ie not be bound to the core. And not even need a plugininterface. And be open-source.

So from the beginning in vl we separated core from libraries and already have a git-repository including all of VLs libraries organized in neat packages (as you can basically already see in your beta35\lib\packs) that we're ready to open. Why haven't we done so already? Well, by releasing library source-code we're kind of committing to a style that everyone should be able to use to write nodes for vl. Therefore this is really a crucial part that we simply wanted to give a second look.

Remember when at node15 we teased how to define nodes for vl? Everything already felt fairly simple indeed. The typeimporter, a breeze. As mentioned in previous blog-posts we've been continuously importing libraries ourselves since then and noted a few things that we needed to improve to make the workflow for future library developers even more convenient.

So this is what we're reworking at the moment and what we hope to be releasing soon:

• the complete vl node library as open-source
• documentation on how to import/write your own nodes/libraries for vl
• documentation on how to package your libraries for consistent distribution

This will reduce the barrier for developers enormously because everything they have to do to contribute to the vl nodelibrary, will be very little vl-specific and very close to what any c#/.net developer is doing anyway.

Other than that our focus until node17 will continue to be the integration of vl with vvvv, improving documentation and adding the one or other smaller feature. So, that at node17 we have a strong foundation to teach on and hopefully even already some new, contributed libraries..

Until the next update,
good patch!