This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

VL summer update

dir lovvvvers of visual programming,

we've not talked about our progress on VL for a while. So here is what happened since its initial public release at the NODE15 keynode.

What the VL?

VL is our next generation visual programming language that (for now only) integrates with vvvv as you know it and allows you to patch plugins for vvvv making use of its object oriented language features. You can test it by using the latest alpha build and following the VL quick reference as an introduction. If you encounter any problems, please get in contact using the VL alpha forum.

In the future VL will be available in a standalone development environment with which you'll be able to deploy .net executables and .dlls that can be consumed by any other .net application.

What happened since node15

Library

A lot of work has been done in the library. We first tried to focus on getting the basics complete. And I'd say we're about 90% there. Here is an overview of what you can now use:

String/Char: more functionality than vvvv except a RegExpr node
Color: more functionality than vvvv
Math: more functionality than vvvv except an ExpressionParser node
2D: everything plus datatypes for Point, Size, Rect and Circle with all kinds of intersection utilities
3D: everything plus datatypes for Plane, Box, Sphere with all kinds of intersection utilities
Transform: about 90% of all nodes known from vvvv
DateTime nodes
Animation/Logic nodes: about 80% of all nodes known from vvvv
Serialization: nodes to de/serialize (if not too advanced) datatypes
Collections: more spreading functionality than known from vvvv plus other collection types, like e.g. a Dictionary

As a bonustrack: quite a bit of the above functionality is patched, meaning you can inspect/change its functionality if needed and since everything is compiled the fact that something is patched is not slowing it down. Only the most basic stuff is imported from .net libraries and close to none of the functionality has been written by our hands!

So what's missing is mostly:

Audio/Video/Graphics/Physics
IO (File, Networking, Rs232, specific devices...)
Databases

Those are arguably the big chunks indeed, but since we have plenty of those in vvvv already it should not be that big of a dealbreaker for a start. And anyway we're moving..

Specifically we're in the process of importing a bit larger .net libraries to learn how we can work with them. The first tests resulted in a patched node for the EyeTribe eyetracking and the 3dConnexion spacemouse devices, all open for you to inspect. This is how in the future you will integrate any device. More to come..

UI

UK, so now that we're getting confident with the library what we're also working on is patchability.

Here is the biggest recent changes:

a simple Typebrowser now assists you with annotating pads
nodes with dynamic pin-counts, like the + node are now adding a new pin automatically when it has no more input free.
use Ctrl+M to annotate your documents/types/operations. This info is used in both the vvvv and vl nodebrowsers.
renaming a patch or an operation will also update all nodes referencing it.

And yes, much more to be done..

Language

Also languagewise a few things have happened. Here are some of the highlights:

loops now understand a special "Alive" outlet. Should the "Alive" outlet evaluate to false the slice will not make it into the output spread...
if-regions now have inlets. They provide the region with the value connected to the default input.
the targetcode quality has been improved improving the overall runtime performance.

The road ahead

We're quite happy with what the integration of VL into vvvv brings us and therefore instead of the VL standalone we now first concentrate on making VL a first-class language inside vvvv, ie. combining the powers of the two. Therefore we're now working towards beta35 which will be the first vvvv release that officially includes VL, expected around new-year. So take this time to check out the latest alphas and feed us back with your thoughts. The main question being: Are you able to express yourself within VL? Show us your patches and lets discuss where you meet limits. You know where to find us: IRC? and alpha forum. We're very much looking forward to your input.

Then with beta35 we'll expect you to gradually incorporate VL into your projects. Implement parts of new projects in VL and still do the rendering parts in vvvv. While you'll be doing that we'll have some time to prepare the standalone release that at some point should finally convince you to completely move to the next generation of visual programming. But no need to rush it..one step at a time..

If you want to support our work we're happy about every single flattr:
/downloads|vvvv?

joreg, Tuesday, Sep 1st 2015 Digg | Tweet | Delicious 9 comments

microdee 01/09/2015 - 16:27

The problem with this "VL is part of old vvvv" that for what VL is capable of now it's way much faster to do the same thing in C# for me. And I will choose C# over VL for vvvv plugin development in most situations because obviously VL is more limiting in what i can do with it (it's not a comparison just a fact).
I know you guys want to make sure that VL is supersolid and superrelyable which is awesome but you're holding back a big portion of potential VL can have. The reason why I cared about VL is the potential to do a more lower level sharpdx implementation with total control of resources and execution (because what we have in vvvv is great but still very limiting and automagical at some points) but i can't have a look on that because that library importer is not public (tbh i have no idea why are you sitting on that too) or a proper api documentation (at least an autogenerated one from comments) is not there yet.
Anyways I love your work and I love your style guys I love vvvv too (after a project with UE4 i realised how awesome vvvv is actually) and I probably will love VL too when I'll be able to extend it to my needs. Unfortunately you spoiled so many major reasons why people was interested in VL holding back above mentioned features for at least half a year is not really helping. And I'm not even bitching about standalone/implementable version and compiling.

Btw while dealing with the voodoo non-sense of some game engines recently i realised VL can be the next UE4/unity sooo easily (in perspective obviously it would be a decent amount of time/work/resources) so guys pull yourselves together! Visualize money, bitches, drugs and rock-roll around VL!

joreg 02/09/2015 - 13:53

hei microdee, thanks for the flowers. regarding the release of type importer: the reason for not having it released yet is that we're only now in the process of really using/testing it ourselves. we need to understand it a bit better and document some default workflows before we release it to the public and everyone starts importing stuff like wild and gets dissapointed when we cannot answer questions about problems they will encounter. so yes, you'll get it when we are more confident about it. until then we'd be more interested in language feedback (as mentioned above).

u7angel 07/09/2015 - 11:58

how is the performance of VL patches comparable to c# plugins? have you made any tests ?

gregsn 09/09/2015 - 17:13

@u7angel:

this is very hard to answer in general. The reason is that you'd typically express yourself differently within VL. As an example: in C# you rarely use immutable data types, but in VL you typically do. What's good is that you have more than one way to solve a specific problem and when you discover that a working solution is too slow you can attack the problematic part later on and refactor if necessary.

Generally speaking:
In the end C# and VL both compile to the same "IL" code and access the same .NET libraries. By that we also benefit of the optimizations done by the JIT compiler as C# does. So basically there is just not that much of a difference, we share the same universe with C# in that regard. If you would patch the exact program in VL and C# there is hardly any significant difference.

So the only thing that really matters is how VL patches differ in expression style from C# code. We embrace readability first - especially the compatibility with the dataflow paradigm. But we support other styles (like working with mutable data) and therefore it is possible to tweak performance where needed. In the end performance depends really very much upon the patch and the use case and can't really be answered in such a general manner.

u7angel 27/11/2015 - 17:11

@gregsn, a late thank you for your elaboration

while having a look at VL here and there, i started wondering why you abandon the conciseness/simplicity of vvvv and introduce - i may say - this noisy language. and you have to admit its noisy. i guess sunep did a good example a while ago and the firmata VL is also a good example.

would it be thinkable to have a higher level patching style (i.e. old vvvv) as the default way and an advanced mode VL style living together in this new piece of software ?

or is this the plan anyway ?

tonfilm 27/11/2015 - 19:40

its all there, you can imagine vvvv patching as a special case of VL. you can only use 'process nodes' and other basic nodes and you would have the same patch as in vvvv, given the nodes exist, which they probably will in time... and of course the UX will also change in future. no worries!

gregsn 27/11/2015 - 19:45

@u7angel:
exactly. The plan is to stick with the high level vvvv and lower level VL combination for now. We put some work in that integration and i think that the combination really gives you a great toolchain (vvvv) to realize your projects, which now will come with a new integrated tool (vl) to solve some hard problems you stumble upon.

VL was born to solve problems that you can't solve with vvvv. It therefore starts from the other end of the spectrum. Over time we'll strive to get it easier to use and less noisy (which is hard if you still want all the language features, but we'll still try hard).

For the higher level project patches: we might end up with design patterns that favors only some few language features for those patches (like the use of process nodes) and disfavors others (which you only should use in lower level patches). We also had discussions about another higher level patch layer (that works different), but then again the incompatibilty between the different levels might get a pain. So this is only an option if there is no other way around it.

So for now we are happy with the combination of both systems vvvv & VL, since vvvv is strong for those higher level project patch. When VL becomes bigger and finally offers everything you need for your project, we'll definetly see how we can get the top-down high level easy to enter aspect back, but for now see it as a tool for people that want to solve a hard problem with a visual language that just can't be solved in vvvv directly. (since it is too high level for that problem........)

u7angel 30/11/2015 - 14:15

@gregsn, so we can teach design students the "easy" way of patching and the brainiacs can dive into "low level" programming. sounds good to me.

your way of developing the next gen vvvv makes absolutely sense, from complex to simple. i never really noticed this is the plan, it came accross differently or i wasn't listening carefully enough.

sunep 30/11/2015 - 17:59

"compile executables" "will run on anything that has .net" are little statements that instantly made a lot of people dream of running vvvv in OSX and on linux (I dreamt of running it on embedded systems) and that took focus away from it actually being a great way to refine and tweak the language without everyone starting out beind super disappointed the it still needs a lot of refinement.

I suspect there will be a new "statement" about the current state and direction, to set the expectations when beta35 comes out, probably in the not too distant future.