hola,
here is the final in a series of blogposts about our forthcoming nextbigthing that we still call vvvv50 (50). If you haven’t already done so please first read the previous issues with the titles:
With little more than a week till keynode you might assume that by now we have a pretty good idea of what the initial release of 50 will look like. Well…of course. Sadly we also now know which parts we’ll have to leave out because we’re just not satisfied with it yet. We’ve definitely hoped for more but we’re confident there is enough for you to get started and by the time you get bored we drop the next feature to keep you entertained. Think carrot.. on a stick.. in front of your eyes..
The past two weeks we got external testers support from bjoernuser and woeiuser. They were hardly able to hide their disappointment after the first hours of working with 50 because there were just too many problems to deal with still. So we were very grateful for their patient bug-reporting and after two weeks we were quite happy with what they’ve achieved. Tons of fixed bugs later we believe to now have something we can call an alpha-candidate.
So let’s recap what you will get to play with on April 29th:
Language
With 50 we are giving the world a new programming language. Its name is “VL”, which in good programming language trivia also denotes the file ending of documents written in the language. ie. you’ll work with files like: callmenames.vl
VL initially will allow you to:
- define operations with (generic) input and output parameters
- define datatypes with properties and operations
- collect instances of your datatypes in spreads
- run operations for-each slice in a spread
- define delegates aka anonymous functions
- use delegates as parameters of operations
- observables..
We have a list of more language features still to come. Those are only the ones that made it to the first release.
User Interface
Did you notice we haven’t spoken about the UI at all yet? The reason being that a lot of the UI design depends on the language design and as we’ve pointed out repeatedly thats where our focus mostly was in the past months. Thats the part of the UI that is inside the patch.
The other part of the UI is everything around the patch and is mostly related to document handling or navigating the structure of a project. Regarding this, here are some fresh news for you:
A typical simple VL project will consist only of a single VL document since now a single document can hold any number of patches. Of course at any point you can decide to create multiple documents and reference one from another, but by default you won’t have to deal with multiple files.
So how is that related to the UI? Well, navigating a projects documents and patches is something the UI allows you to do and is what you’ll do a lot while working on projects. A treeview would be the obvious choice here but since we’re not best known for obvious, we have gone a bit experimental in that respect hoping to provide a faster access for most usecases (with the treeview only as a fallback for now). We’ll see how that works out..
Navigation Menu
Library
Also not much library talk so far. And here you’ll probably see your biggest disappointment with the initial release: There aren’t many nodes yet. Certainly none that do any drawing or even a renderer of any kind yet. Instead we hope to get you covered with the basics for math, string, color and spread handling so you’re able to get used to the new paradigms.
Still here some more library news: We created a tool that allows us to import datatypes and operations from any managed library out there and have them available as nodes in VL within just a few clicks. Thats quite crazy in theory. And yes, even in praxis. Only in praxis it also means that while we’ll save years of time writing library-code we have to invest some time in curating libraries and make them work properly and intuitively within the VL world of thinking. Can you have that tool to import stuff for your self? Not now. Later? Of course!
Deployment
As we already demoed at node13 VL is a compiled language meaning that with any change you do to a patch, 50 in the background creates a new executable and instantly runs it. And really that should be none of your concern unless of course you’re interested in running your creations standalone, ie. without the need for 50 being around.
Because thats what “compiled” also means: Create standalone executables from a project with a single click. And if one uses only dependencies to cross-platform libraries in a project, the executable will even run cross-platform. Only: Not with the initial release.
Also we demoed having 50 itself running on other platforms, which according to the survvvvey 39% of vvvv users are waiting for.. Anyway..not happening either. Not now.
Bummer..so with all that “not now” is there actually anything left to look forward to? Eeei god hasn’t created the world in one release…
Still interested in a map of the road ahead? Don’t miss the keynode where we’ll try to lay it all out.
Appreciate what you just read? We appreciate a click: /downloads|vvvv.
Looking fwd to seeing you all at node!
Comments:
Comments are no longer accepted for this post.
i guess everybody was very excited about the bold promise “can compile” and “is multiplatform” , consequently might do openGl and dx11…and now none of this is there and it can’t even draw anything (while this what you mainly want to do with vvvv)
santa node is bringing a bycicle without wheels
Unfortunately won’t be at Node but looking forward to get to try 50/VL.
Personally I find a visual programming language/environment for CLR/.Net more interesting than an incremental/feature upgrade of vvvv45.
50 may very well come to appeal to a much broader range of developers than vvvv has so far while it might initially disspoint parts of the existing vvvv user base due to missing features as well as splitting developer attention between support of the old and the new.
Will there be networking nodes? Or is there a way we can have a VL plugin for vvvv so we can do the logic in VL and render in vvvv?
Guessing the reason for not releasing a renderer with VL is the same bug as vvvv’s crazy GUI. If I could write logic in a super clean UI with VL and send it to vvvv for rendering that would be awesome!
@ggml well in theory that’s what IDEs like visual studio or SharpDevelop do by default. our importer tool opens a library in a very similar way. you can browse it, decide which types and methods you want to import and most importantly adjust category/node/pin names if they are not to your liking. this is how we currently work on the basic library of nodes we want to ship with VL.
Once we have proper documentation and guidelines we will release it and users can import whatever they need for their project.
+1 h99
I’m mostly using vvvv for other field than computer art and rendering stuff, I face some limit with big v4 patch, 50/vl is a real future for me.
So I more than support you dear devvv team :)! Even if the baby is not able to walk and speak yet.
For the transition period : It’s true that running vvvv patch into 50/vl or the opposite would be super great…
Well it might rather be an assembly kit for a super trendy ‘Mono’-cycle – rather than an ordinary bicyle which santa can buy off the shelf and put it under the cosy xmas tree.
C’mon guys, can we have some support please. We have to assume that the boys take some time to consider the fundamentals properly and not rush something out prematurely and disappoint us in the long run.
true rogerlette,
huge complex patches with zillions of links, framedelays, dynamic created/deleted objects with sifting id, plugins with dictionarys to keep track of the state etc, etc are just a pain in the ass to build atm, not talking about maintain them later. i hope VL helps with all this issues!
@u7: this problems cannot really be solved by just writing plugins unless you keep everything in one huge plugin or divide it to several plugins with custom datatypes (like in box 2d). but thats not really elegant im my opinion.
hey ele, i didn’t say at any occassion that vl is a bad idea, right! just hoped and hoping for advances in different areas of v4 than the language. and i prefer a more gradual development style with a smooth transition rather than rewriting everything and then having a long phase of bug finding and fixing.
proof me wrong but with this rewrite it will take a long time until this can be used in production.
lieber eno, i rather have something that works than being trendy ;) i’m allowed to say that i’m disappointed that most features promised at node13 are not here. i don’t really care much for a “visual c#” since i’m fine with writing code when it suits the purpose.
to make this clear, i’m well aware that creating a new language paradigm is some crazy bit of work, which eats time for breakfast. on the other hand, some people would have liked to see other feature/improvements first.
but i’m sure it’s all coming together at some point. 2017 ? ;)
angel, don’t understood your text.
vvvv guys making a nice project, it is really hard work to make it in right design, because nobody do it before. It growing long time, but I see the basis is complete.
may be I’m sort of fan, but I really like v4 and already like new vl.
<3
and i’m a fan too and have bought quite an amount of licenses hence support the development.
that doesn’t neccessarly mean i have to be happy with everything (read development emphasis).
IMO this is exactly the right way to go - focusing on laying the foundations for others to add more functionality/nodes. Spending lots of time getting DX rendering stuff to work would likely have taken away precious development time from much more important things - i.e. making vvvv50 usable at all and finally getting an alpha out.
For my personal purposes this is absolutely great news, given that I rarely use DX rendering stuff (I’m dealing mostly with lighting installations) - that DX stuff was mainly causing problems for me in the past (think cross-platform). I’m confident that once these basic foundations have settled, new functionality will land rather quickly - likely with help from the community if possible. Who says the rendering stuff needs to be developed by the language core developers anyway?
For the time being, you can still use the “old” vvvv for your DX rendering stuff, while starting to play around with the concept of the new one :)
I am optimistic that it will go in the right way. But I feel also some turbulent time ahead and reshuffling of existing power (force) structures in the realm of data flow programming. VL can be a great future but as always with fundamental change it could be too much and split everything appart. So that we have in the end VL only used by mac users and vvvvjs ruling the world of mobile devices and the heavily mutated DX12 vvvv, now let by u7angel and vux, keep dominating windows, with a dark futuristic UI
However, thanks for keeping us updated, realy exciting!