dir lovvvvers of visual programming,
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.
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:
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:
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..
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:
And yes, much more to be done..
Also languagewise a few things have happened. Here are some of the highlights:
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:
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!
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).
how is the performance of VL patches comparable to c# plugins? have you made any tests ?
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.
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.
@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 ?
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!
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........)
@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.
"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.
anonymous user login