“The Humble Quad Bundle” by #vvvv serves 4 computer classics implemented using the stilltocome #visualprogramming language codenamed #vvvv50 (hint: the above are exactly 140 characters)
The bundle comes with a reissue of the hit games Pong (1972), Frogger (1981), Worms (1995) and Asteroids (1979) all realized using the patternpending Quad render-engine. Something for the whole family.
Download Now!beta-contribution
huh,
we just had a look at the calender and noticed it’s been already over a year since we told you about our next big thing. those who were there at the node13 keynode event already got a glimpse but since then we kept a low profile on that thing again. we’re now slowly coming to a point where things start working and we feel we can start sharing some more infos about what is to expect.
we’re currently in the process of testing patching convenience and the usability of certain language features and paradigms. all with vvvvs traditional focus on ease of use.
the games above are the result of our first round of applying the new language to some actual problemsolving. specifically we picked one very common problem for a start that is managing the life-time of objects. And the term “object” is key here. where in vvvv45 you need to manually synchronise several spreads representing the properties of your objects, in vvvv50 you can comfortably (on a high-level) think in actual objects that have data and operations that act on that data. so eg. when the spaceship shoots we can create a list of rockets that have a position and speed and and ask them to check if they hit one of the asteroids. and when they do, we can remove them from the list of rockets and tell the asteroid to explode…
here is a screenshot of the asteroids root patch. have a look around and see if you can read it. don’t worry, it took us a while ourselves as well.
(click image for a sharper version)
now here is a little vvvv50 faq: will it run on mac/linux? probably. it is all written in pure c#/.net which runs cross-platform via mono. we haven’t done extensive testing on this yet but are halfway optimistic.
will it run on devices? probably, see above answer.
when will it be available? rumours are there will be a node15…
can i alpha-test? don’t call us, we call you. we’ll slowly start reaching out to testers when we feel it makes sense.
will it be faster than vvvv45? yes.
will the first version be as amazing as vvv45 is now? nope. but in a good way.
thats it for the first treat. expect more posts introducing some of the new features in detail in the coming months. but now next up is the release of beta32 scheduled for late april.
Comments:
Comments are no longer accepted for this post.
Nice!
Great news joreg! If there’s one thing I dislike about vvvv it is the difficulty to patch something ‘object-like’ when working on a more complex project/logic - even more because OOP is such a common programming paradigm. I mean, yes - there are tricks and tweaks but it can be really tedious sometimes. Anyway I’m really looking forward to see how you guys will implement this new functionality in the real-time patching flow of vvvv and I can’t wait to get my hands on that and test it out!
Keep up the good work!
waited long time for this. thanks devvvvs!
I totally agree with the clear cut approach! ..I guess you got rid of doubles now eheheh.. ?
I can’t wait to know more and give it a try.
great
Wow! As this looks very interesting indeed, i see the slope of the learning curve for beginners going up with some sharp (hehe… #) edges. i agree with u7angeluser on that. If i am not mistaken this borrows concepts from reactive programming techniques? with some base of “more object oriented approach” as the current node approach for a graph is like!? compressed down to a 2d representation. we will not loose the patch and i really respect the work concerning that representation regarding different lifetimes and “connecting” these lifes with cords. having objects with a longer lifetime is something i’ll be definitely looking forward to, but, sorry, it just doesn’t read well in the patch with the “invisible tardis cords”. … yes, maybe codename it Tardis ;)
Nevertheless too questions to read it better:
Ditto Lecloneur.
Fascinating, and I’m especially looking forward seeing to how you’re handling library integration.
LLVM too?
Am I completely wrong, or this is something like how the physics plugins work ?
Two more questions:
This leap is going to make retro-compatibility completely impossible ?
What about the Graphic engine?
ah one question.
In a multi platform version…
Will it be OpenGL based?
Do I need to write the shaders in something else then HLSL?
Fresh!
@teckor: good one. and what about dx11? I’m still a bit confused about dx9/dx11 ways..
“we are working more on the language, runtime and patching features than on the library.”
does it means dx11 will remain unsuported by devvvvs?
let me briefly comment on just the language topics regarding the shown patch:
i would like to reserve the term “reactive” for the push based dataflow programming model (like seen in vuo), where values get pushed from node to node over a link. typically in reactive programming the data source is not interested in any answers from the subscriber/sink. it is based on the idea that the values just get pushed downstream causing zero-to-many reactions. (we are investigating this model but it is not part of the demo above)
what is shown above is a bit different: think of the CreateAndReset, LiveAndLetDie and YouOnlyLiveTwice as incomplete operations - their job is to do the life time management for you, but you still need to tell them when and how to create a new object, or when to discard it (so they need some answers from you). you can complete this operation by
quote:jens.a.e:
quote:jens.a.e:
Basically the message would be: “you can have many Get nodes. But you don’t have to.” With these Get nodes you basically move some output pin(s) to a separate node, which can be quite nice, but not necessary in general.
thx @gregsn for further details!
i like the idea of subpatches being something like factories (one can subscribe to). this indeed introduces a more dynamic way of handling object collections (formerly spreads?).
from the language perspective i am starting to like it :)
i guess this is still a bit away, but how will the plugin interface change, or will it actually convert to just a “node API”?
i really like the concepts and features
@jens.a.e
the ‘factories’ that you see are right now called regions which are in fact higher order functions which are defined in another patch, something every patcher can do. these are just examples of this very powerful feature.
the plugin interface will not be necessary anymore, its all just code. so the only thing you would have to do is basically write a method and it will appear as a node.
joreg talks a bit about this after about 17 minutes in this video:
Joreg about vvvv50 at Resonate
there was also this discussion on facebook which could be interesting for everyone:
quote:sunep: it’s always scary to need to learn to think in a new way.
to me it seems like it will end up being a lot closer to “conventional” programming and to me relatively deep into “old” vvvv thinking it seems like I need to be quite a bit more abstract when patching. It’s probably super cool once we all get into it, but the whole linear spread and cross thinking to make a checkerboard will become more complex… or?
quote:bjoern: VVVV is the foundation of most of my current work, I make a living from it. Now something new is introduced and I like what I’ve seen so far. But a big part of information is left out. There is no roadmap for the development of 50 (I know of). No insight on what your plans are with 45 once 50 has been officially released and so on. This introduces a lot of uncertainties which could have a big impact on my (work)life…
Also think of potential new users. Like joreg said in the video you have to wrap your head around one paradigm (spreads) and then (in a not so distant future) you can forget about it and start learning something that is vastly different from scratch. So why bother.
quote:microdee: @scared people: as i understood spreads won’t disappear but most of the stuff you’d do in plugins you can do that now in patch! i mean what i do most of the time nowadays is just creating objects in plugins and when i finished sorting and mangling with them i will convert those to basic spreads. doing that in patch would be superawesome.
however my question is that how we should imagine the library importing function? what portion of a namespace will be represented as a node?
quote:milo: but on the other hand.. it sounds all so …kind of plausible especially if i think of all the great plugins which already make use of oop for quite a while now.
for instance i would never try to make complex list operations out of spreads anymore as there is the possibility to just make the use of dictionaries right now
but i agree with björn about the roadmap for the future of 45.
thanks everyone for your feedback. as mentioned above we’ll address individual topics in the coming months with more detailed blogposts.
so please don’t be alarmed too much yet by things you can’t understand from the sparse information we’ve provided so far. we’re still very much in a process of understanding things ourselves and figuring out the best way to make a transition for everyone as plausible as possible. spreads will be in our hearts forever but we have this suspicion that at some point noone will really ask for them anymore..
The direction you are (or seem to be) taking with vvvv50 is very interesting and I’m looking forward to see what the future holds.
The biggest challenge/risk and what I can’t really tell from what’s shown so far seem to be how well the GUI metaphors will work. Get that right and it will be awesome and probably interesting for a whole lot more people outside the current vvvv users.
@manuel: the physics plugins also need to manage objects and in this regard there are similarities, but in a twisted way. internally they undoubtedly work in an object oriented way, managing lifetime and interaction of objects for you. on the patching surface you have the possibilities to interfere with that system. with the language features shown above you can do that system and the objects it manages by yourself, whith object access that doesn’t need workarounds like ids.
other question 1. retro compatibility) we designed this system from the ground. it is our opinion that taking the chance to design things differently with the idea of eliminating limitations of the current system is only possible with a clear cut. there will be a period of time where shifting strategies will be of interest. and we will do our best to support transitioners for a real long period of time. anyway, this is not the time yet.
other question 2. graphics engine) the new system will offer ways to import nodes that make it easier to integrate whole libraries. so up to now we are working more on the language, runtime and patching features than on the library. we’ll see. but probably there won’t be just one graphics library.
Thank you for posting an update, this looks like a really exciting development. The fact that vvvv will (most likely) be able to live on many platforms and devices will certainly draw in a larger a crowd of users.
Best of luck vvvv krew!
without some details about dotted lines, black dots with and without connections, the absence of graphic nodes (i.e. quad), lots of unknown nodes like getGeometry etc. its hard to make sense of it(screenshot) and contradicts (for now) with
@u7angel: of course you’re right. it can’t be read properly without further detailed explanations. for now just look at it as a fragile puzzle. the nodes, their naming and also some of the graphic notations are still subject to change. anyway here some pointers: