» 50: The Humble Quad Bundle
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

50: The Humble Quad Bundle

"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!


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?

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.

joreg, Tuesday, Apr 1st 2014 Digg | Tweet | Delicious 39 comments  
catweasel 02/04/2014 - 00:02

Eeek :O

dl-110 02/04/2014 - 01:10


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!

manuel 02/04/2014 - 01:36

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?

manolito 02/04/2014 - 02:32


gregsn 02/04/2014 - 02:43

@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.

Gareth.Griffiths 02/04/2014 - 13:35

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!

u7angel 02/04/2014 - 14:17

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

joreg said
all with vvvvs traditional focus on ease of use.
r4dian 02/04/2014 - 14:23

Exeporting .exe files, eh ?

ggml 02/04/2014 - 14:47

glad about nodes staying grey, yet colors are in use

gregsn 02/04/2014 - 14:55

@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:

  • there are 3 GetGeometry nodes, somehow patched for the custom Spaceship, Asteroid and Bullet types. so full name would be GetGeometry (Asteroid) (..) and those are subpatches. As most of the nodes you see here. we should have named them GetLayer though.
  • primitive values (like numbers and booleans) flow along solid links. asteroids and other "objects" flow on dotted links.
  • GetBulletParams belongs to the spaceship. the create node below belongs to the Bullet.

that said, i guess it will stay unreadable unless every single detail is explained which will do step by step with separate posts. for now just look at it from a top down perspective and try to ignore the details. it is really just meant to give you glimpse.

dottore 02/04/2014 - 15:07

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.


m4d 02/04/2014 - 16:36

yeah, thanks the heads up on vvvv50!

diki 02/04/2014 - 17:05

wow, i'm excited to see where this is going! :)

sebl 02/04/2014 - 17:29

really impressive and a hard tease. thanks a lot and keep going!

psybot 02/04/2014 - 21:19

Just saw that I missed a call? No message left!! Please call back!

jens.a.e 02/04/2014 - 21:34

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 u7angel 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:

  • will there be a lot of Get... nodes?
  • are the black dots something like sinks and sources?
lecloneur 03/04/2014 - 00:36

color in patch ! finally we can have more than shades of grey for our programmed ideas to be readable. thanks

Hadasi 03/04/2014 - 00:48

Ditto Lecloneur.

Fascinating, and I'm especially looking forward seeing to how you're handling library integration.

LLVM too?

microdee 03/04/2014 - 00:50

"will it run on devices?" the environment or the exported "app-patch-thingy"?

microdee 03/04/2014 - 00:52

@lecloneur: if it's not just debugging...

tekcor 03/04/2014 - 02:25


mino 03/04/2014 - 02:36

wow, i should re-write book ;)

tekcor 03/04/2014 - 16:31

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?

Desaxismundi 03/04/2014 - 17:03


@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?

ventolinmono 03/04/2014 - 17:09

It would be very nice if #VVVV50 could be GNU General Public License, or other free software license.

mrboni 03/04/2014 - 18:48

@ desaxis - I think dx9, dx11, and openGL rendering will likely be libraries available to use on platforms that support them

ggml 03/04/2014 - 19:01

why is create asteroids outside of the subpatch but create ship and bullets inside ?

gtoledo3 03/04/2014 - 19:12

Hey all, not trying to violate the "don't call us" rule, but wanted to throw out that I'm really interested in testing the OS X version of this. I've been a light VVVV user for years, and a very heavy QC/OpenGL user. You can contact me at gtoledo3 at gmail com. Thanks.

beyon 03/04/2014 - 19:29

tekcor: my memory might be fading but I believe they showed or mentioned patching shaders at Node (anyone else share my memories?) - if so same patches could compile to hlsl/glsl/whatever.

nissidis 04/04/2014 - 01:03

damn MAC users.. :P +1 for vvvv50 !!!

gregsn 04/04/2014 - 21:18

let me briefly comment on just the language topics regarding the shown patch:

jens.a.e said
If i am not mistaken this borrows concepts from reactive programming techniques?

a bit comparable, but let me just point out some small differences.

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

  • placing such an incomplete operation as a region into your patch and
  • then placing the missing parts right into that region.

in other words: the small colorful patches within the region are callbacks that get called by the surrounding region.

jens.a.e said
  • are the black dots something like sinks and sources?

a pair of read/write dots can be read as a feedback.
they let you read from or write to your private memory of the surrounding patch. (aka field)

jens.a.e said
  • will there be a lot of Get... nodes?

Depends. Actually we could have simplified the example to use less Get nodes. But then we wanted to test the object oriented way of thinking.

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.

Hadasi said
LLVM too?

we have modular approach that basically allows several compiler targets, but .NET is the one we focus upon.

ggml said
why is create asteroids outside of the subpatch but create ship and bullets inside ?

yeah. right. sorry. this white little "create" just to the left of the "YouOnlyLiveTwice" actually is a create (RandomGenerator) that is created once and then used by "FromOuterSpace", which is a subpatch that creates the asteroids (when q is pressed).
This visual glitch will get fixed, hands down.

jens.a.e 09/04/2014 - 07:08

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"?

sebl 09/04/2014 - 12:44

i really like the concepts and features

tonfilm 10/04/2014 - 17:33


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

tonfilm 11/04/2014 - 16:49

there was also this discussion on facebook which could be interesting for everyone:

bjoern said
fascinating but also scary
tonfilm said
some people said the same, but what might be scary about it?
sunep said
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?

bjoern said
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.

liked by sunep and vux

microdee said
@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?

hadasi said
Where you used to think spreads you could now think lists. I know its a little more complicated than that but when you're making an object it could be made from lists of data. And when you want a lot of objects you make a list of them too. Stuff can be added or removed from the list and the properties of the objects can be sifted rather than worrying about exactly which index you'll need. I think... Correct me if I'm wrong, David. I'm not exactly a C# junkie
microdee said
yeah you're correct, however the sifting part is done with dictionaries rather than lists. what i'm amazed about is that to create a dictionary you don't have to write a plugin for that, now you can do that entirely in patch. vvvv50 in fact will be a node based .NET development environment which is a HUGE thing even in the outer scope of vvvv community. it's a "microsoft will rise his eye-brow" huge thing!
also 2nd question is that the dynamic plugin concept is dead too?

liked by ggml

u7angel said
two hearts in my chest. i'm slightly sad that vvvv's different approach to programming (read spreads) is abandonend after 10 years. and i'm excited about the new concept. although i find the representation of OOP as graphical programming a little clumsy and hope there will be early community alpha testing to incorporate feedback

liked by sunep

ggml said
could there be a pixel datatype that works in the gpu?
milo said
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.

joreg 11/04/2014 - 17:55

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..

bjoern 11/04/2014 - 18:32

Just to clarify: My main concern aren't spreads or the lack thereof but rather the transition from one version to the other.

beyon 20/04/2014 - 12:51

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.

  • 1

anonymous user login


~5d ago

joreg: Workshop on 16 05: Introduction to Shaders. Signup here: https://thenodeinstitute.org/courses/ss24-vvvv-introduction-to-shaders-in-vvvv/

~6d ago

bjoern: hello, I am looking for a job / project starting june. get in touch via vvvv specialists available for hire

~12d ago

joreg: Workshop on 09 05: Deepdive into the Stride 3D Engine. Signup here: https://thenodeinstitute.org/courses/ss24-vvvv-advanced-3d-rendering-in-vvvv-with-stride/

~12d ago

tekcor: Dear vvvv community, I am leaving my personal fundraiser here because I know many of you personally, sending love https://t.ly/iV9l_

~13d ago

joreg: Rewatch the 24th vvvvorldwide meetup here: https://www.youtube.com/live/gNszIiRAjDo?si=0RXF0pW73EUaRqGk

~13d ago

joreg: LINK - the vvvv summer camp 2024 is announced: https://visualprogramming.net/blog/2024/link-the-vvvv-summer-camp-24/

~16d ago

joreg: Tonight, May 3, vvvv meetup in Berlin or via stream: https://visualprogramming.net/blog/2024/24.-vvvv-worldwide-meetup/

~19d ago

joreg: Workshop on 02 05: Intro to the Stride 3D Engine. Signup here: https://thenodeinstitute.org/courses/ss24-vvvv-intro-to-the-stride-3d-engine-in-vvvv/