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.
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.
- 1
anonymous user login
Shoutbox
~3d ago
~9d ago
~9d ago
~10d ago
~23d ago
~1mth ago
~1mth ago
~1mth ago
~1mth ago
~2mth ago
Eeek :O
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!
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?
exciting!
@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
Exeporting .exe files, eh ?
glad about nodes staying grey, yet colors are in use
@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:
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.
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
yeah, thanks the heads up on vvvv50!
wow, i'm excited to see where this is going! :)
really impressive and a hard tease. thanks a lot and keep going!
Just saw that I missed a call? No message left!! Please call back!
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:
color in patch ! finally we can have more than shades of grey for our programmed ideas to be readable. thanks
Ditto Lecloneur.
Fascinating, and I'm especially looking forward seeing to how you're handling library integration.
LLVM too?
"will it run on devices?" the environment or the exported "app-patch-thingy"?
@lecloneur: if it's not just debugging...
Power!
wow, i should re-write book ;)
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?
It would be very nice if #VVVV50 could be GNU General Public License, or other free software license.
@ desaxis - I think dx9, dx11, and openGL rendering will likely be libraries available to use on platforms that support them
why is create asteroids outside of the subpatch but create ship and bullets inside ?
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.
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.
damn MAC users.. :P +1 for vvvv50 !!!
https://www.google.com/search?q=yes&tbm=isch
let me briefly comment on just the language topics regarding the shown patch:
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
in other words: the small colorful patches within the region are callbacks that get called by the surrounding region.
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)
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.
we have modular approach that basically allows several compiler targets, but .NET is the one we focus upon.
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.
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:
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?
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
however my question is that how we should imagine the library importing function? what portion of a namespace will be represented as a node?
also 2nd question is that the dynamic plugin concept is dead too?
liked by ggml
liked by sunep
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..
Just to clarify: My main concern aren't spreads or the lack thereof but rather the transition from one version to the other.
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.