» Blog
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.


new post

  reset tags

addon-release core-release date devvvv gallery news screenshot shout stuff
delicious flickr vimeo youtube

Click to toggle, doubleclick or Shift+click to solo a tag

Order by post date popularity


here is the fifth 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:

  1. 50: That Next Big Thing. An Overview.
  2. 50: Colors
  3. 50: Properties
  4. 50: Generics
All information given here is still preliminary and subject to change.

Now please fasten your seat belt because this is a big one. Probably the single least asked for feature that could still become 50s unique selling point: Custom Datatypes.

There is a chance that for some of you it will now be enough to explain this in one sentence: In 50 a patch defines a datatype, horray! If that makes sense to you already, then cheers. There isn't much more to learn in this article.

Glad you're still reading. So you belong to the other group of people who are probably afraid that this may be the moment you're loosing it. It being your understanding of how it will be like to patch in the future? Fear not! "Custom Datatypes" only sounds abstract but is actually a very basic and intuitive concept. You'll understand and be happy to have them around soon, read on.

But before demonstrating how custom datatypes make our patchings easier with 50, lets first establish a problem in 45 to pave the road for the hype:

The demo scenario:

  • when the left mousebutton is pressed, particles (with random velocities) are added
  • when a particle reaches y < -1 it is being removed

In good old modular fashion here is how you could approach this:

A patch in 45 is merely a visual clue for the user

Step 1) A single particle

  • Create a patch called Particle that has a "Start Position" (2d), a "Velocity" (2d) and an "Initialize" input
  • Create a node of this Particle-patch, attach it to Mouse and Renderer and voila: A single particle moves as you click in the renderer
Left: the Particle patch that holds and manipulates the particles data in a framedelay loop. Right: a patch utilizing the Particle patch.
Click to enlarge.

Step 2) Multiple particles

  • Want multiple particles? Just spread them, right?. But how? If we'd just put a static randomspread to the Particles velocity input we'd get multiple moving particles, yes, but we'd not be able to remove individual ones once their y < -1
  • Intuitively we'd want to somehow create particles and put them into a spread as such. Only we don't really get hold of the particle itself. What we can get access to is its position and velocity properties. So lets put those in a spread
  • In order to be able to manage (ie. add/remove) individual particles we have to move the framedelay from inside the Particle patch (where we'd actually want it) to its parent patch. Now the Particle patch is degraded to a hull with the name "Particle" but it no longer holds the actual particla-data. That is bad.
Left: the Particle no longer holds the data. Right: the parent patch manages the particles data via InsertSlice and Select within a framedelay loop.
Click to enlarge.

The framedelay together with an InsertSlice and a Select allow us to easily (well,..) add and remove slices dynamically.

So far so 45. See the fact that we needed 2 framedelays here? One for Position and one for Velocity? Oh you can zip those two parameters into one spread, of course. But next you blink the boss demands the particle to have a Color and a Name and you already need 3 framedelays... See where this is going?

The general problem here is that, as mentioned in 50: That Next Big Thing. An Overview., 45 does not really understand subpatches. For 45 everything is just one big patch and when you carefully modularize the Particle patch, 45 does not get any of this. So Position, Velocity and any other parameters are just laying there but 45 does not understand that they all describe properties of a particle and actually belong together.

This is where in 45 we'd advise you to create dynamic plugins to join/split your custom datatype. Thats fine for a start, only it requires you to code. Also there are three contributions that I won't go into detail here but are worth mentioning in that respect: Message by velcrome, VObject by microdee and VVVV.Struct by woei & tonfilm.

So while you see there are ways in 45 to tackle such (still rather simplified) situations, they are all workarounds to that aforementioned inherent problem of 45 not knowing about subpatches. And we need you to be really frustrated about that, not about a missing grid or close-button in the UI. This is where we need you to chant in unison: "Go release the cat, we can't work like that".

Well, here we go:

A patch in 50 defines a datatype

What you really want to express when putting multiple properties in one patch is to wrap up all those properties into one entity that you can operate with. Which is exactly what happens in 50.

So just to make sure we got our terms straight, a quick recap:
Value, String, Color, Transform,... are all primitive datatypes we're used to.
Now when we create our own datatype we can think of it as a compound of multiple primitive ones. So for example our Particle could be a compound of:

  • Position (of type Vector2d)
  • Velocity (of type Vector2d)
  • Color (of type Color)
  • Name (of type String)

In other words: Those 4 properties (each of which has their own primitive datatype) together in a patch make our custom datatype called Particle. And of course this can be taken further. Think of a custom datatype called "Firework" that has a Spread<Particle> (meaning a spread of particles) and so on. So yes, datatypes can be compound and cascaded in any way. Apart from properties, datatypes also usually have one or more operations. Therefore the terms "patch" and "datatype" can be used synonymously.

To the point. We could of course exactly replicate Step 1) from above in 50 but we'll leave that up to your imagination and skip it here (as it would look exactly the same minus the framedelay). Instead we jump right into the definition of our custom datatype, which in its most simple form could look like this in 50:

Reading the patch:
In the (still rather rudimentary) listing on the left side you see that this patch has two properties called "Position" and "Velocity" and it has two operations called "create" and "update".

We've mentioned operations before, they are sections in a patch that can be independently executed. In 45 every patch has only one operation, therefore we never gave it a name, but think of it like "update" or "evaluate", ie. the operation that is called once every frame. In 50 a patch can have any amount of operations that can be executed any amount of times per frame (just dropping that here...more on it in a later posting).

So here the "create" operation is used to set initial values for a particles Position and Velocity properties. In further executions of "update" the velocity is always added to the position and the result is again stored in the "Position" property for the computation of the next frame. Also the result is being returned to the caller of the "update" operation as you can see via the little quad in the bar labeled "update".

Next: How do we create an instance?

Instantiating a custom datatype

ad step 1)
Lets again start with placing just a single particle in the patch:

By simply creating a "Particle" node in a patch, what actually happens in 50 is that we create a static instance of the type "Particle". Static meaning that it is instantiated when the program starts. The particle executes its "create" operation once and then repeats executing the "update" operation every frame until we delete the node or stop the program. We can of course create multiple Particle nodes next to each other and have multiple static instances.

Give it a velocity and it moves..done.

Creating dynamic instances

ad step 2)
The challenge now is to create multiple instances of Particles dynamically. But don't think 45 style SetPatch (VVVV), where you'd tell vvvv to actually create a Particle node and place it in a patch... no. This is where the 50 magic chimes in:

Instead of placing the "Particle" node as such in a patch we can also just call individual of its operations. Booom. In the patch below notice the "* Particle" node. This one is short for Particle.Create(), ie. calling the particles "create" operation to create and return a single instance. And then spot the double-decker ".update Particle" which is (not so short) for Particle.Update() that is called in the "For Each" region, ie. it is called once for each particle in the list.

Reading the patch:
When the left mouse button is pressed a new particle is added to the spread with the current mouse position as start position and a random velocity. Remember from the last posting about generics that the ".add Spread" is not specific to the particle! Then for each particle in the spread the update-operation is called so the particles move. Also for each particle a circle is created. The select node only takes particles that are still alive (ie. have an y < 500) and writes them back to the spread of particles. Finally all the circles are drawn in the renderer.

If you now once more compare the 45 and 50 approaches here is what you should note:

  • in 45 the data of the particle is mixed together in a patch with the parts that manage the particlesystem (ie. add/remove particles). That works ok-ish in this simple example but is hell in larger scenarios.
  • in 50 the data and functionality of the particle are conveniently wrapped inside a particle patch and another patch around the particle, which we could call ParticleSystem, simply manages multiple instances of particles. So when changing functionality in the particle nothing has to be changed in the ParticleSystem. This is big!

You still here?
yawnsmiley... let us digest this information for a while. I think it is enough for this time. Still more to come..

Appreciate what you just read? We appreciate a click: .

joreg, Sunday, Mar 1st 2015 Digg | Tweet | Delicious 9 comments  

Here we go,

turns out it is quite a hassle to get 48 workshops run by 58 hosts in 5 days in 7 rooms under a single hat. You see the gorgeous result above and can get the .pdf here. Now it is on you to find your personal path of interest through the week and get your ticket. Full workshop descriptions and booking of individual seats will be available by next week!

Here is an alternative view on the workshops sorted by some vague categories:

Patching & Coding

  • vvvv for newbies/für Anfänger
  • BYOP - Bring Your Own Patch
  • vvvv50 snail/rabbit introduction
  • Object Oriented Patching with VObjects and Messages
  • Git for vvvv Projects
  • vvvv.js: Extending your Patching Skills to the Web
  • Multiscreen Setups & Boygrouping,
  • Dynamic Plugins,
  • Plugin Development with Thirdparty SDKs

Animation & Graphics

  • Basic DirectX11 Shading
  • Advanced DirectX11 Shading
  • DirectCompute: A Multipurpose Shader
  • Generative Design Algorithms
  • Oculus Basics
  • Box2D Physics in vvvv
  • Realtime Physics in 3D
  • Shading Pointclouds
  • GPU Particles
  • Transformations
  • Emeshe: An Advanced Rendering Technique in DX11
  • Video Effects and Compositing

Hardware & IO

  • Arduino & VVVVirmata
  • Soft Sensors for Soft Bodies
  • Bodysensors
  • 3D Printing - vvvv and OpenSCAD
  • vvvv meets G-Code
  • Cutting & vvvvolding Paper
  • Grasshopper & vvvv
  • The World is our Canvas! Projection Mapping with vvvv
  • Knitting with vvvv
  • Ways of Seeing (with Computers)


  • Kinect Basics
  • Kinect Interactions with DX11 - Pointcloud
  • Machine Learning with vvvv
  • Kinect & Oculus
  • Recording and Annotating Movements
  • Interacting with Choreographic Installations
  • Connecting Things to the Internet of Things


  • Interfacing Reaktor and vvvv
  • SonicPI
  • VAudio

You have no idea how much we are looking forward to this! Roughly 9 weeks time to prepare for the rush everyone. Back to coding...

joreg, Friday, Feb 20th 2015 Digg | Tweet | Delicious 6 comments  

For the Third Edition of GLOWFestival we decided to give an even bigger and more exciting edition of Festival also because 2015 was proclaimed by the UNESCO International Year of Light . And the GLOWFestival was recognized by the IYL (International Year of Light)! with the patronage and moral support! Many news this year about the use of light in artistic form in GLOWFestival, like:

° The video mapping Open call, with the choice of one of three locations;

° Mapping4kids Open Call! May participate kids of all ages. We ask them to to reinterpret the path of Locations that we will provide and to create an image based on it. Imagination is the limit! So if selected, they will see their drawing projected on one of the three locations of video mapping;

° 3D Official Gadget Festival Open Call, create the 3d model of gadget and see it printed in limited editions;

° outdoor installations open call with theme of light;

° BYOB (Bring Your Own Beamer Ostuni - in the historic center of Ostuni) The GLOWFestival offers you a chance to let everyone see what you can do with your projector and computer!

° Talks on Digital Media during the days of GLOWFestival;


gloWArp.com, Tuesday, Feb 17th 2015 Digg | Tweet | Delicious 1 comments  

Who Ventolinmono
When Thu, Mar 12th 2015 - 20:00 until Thu, Jun 4th 2015 - 22:00
Where Local de Arte, Unión 221-B, Col. Escandón., Mexico City, Mexico

Imagen Digital Interactiva con VVVV

El objetivo del taller es iniciar a los asistentes en programación con VVVV y demostrar sus posibilidades creativas. El taller hará énfasis en la experimentación con imágenes digitales y la interacción con estas imágenes en tiempo real.

El taller va dirigido a artistas y/o diseñadores que les interesa el arte electrónico y quieren empezar a programar. No es necesario que tengan experiencia en programación, sólo conocimientos básicos de computación.

Más información acá:http://www.localdearte.com/talleres03/vvvv-1

ventolinmono, Friday, Feb 13th 2015 Digg | Tweet | Delicious 0 comments  

We are a design studio based in Milan working on a huge multi-projection realtime dataviz.

We are looking for a vvvv pro patcher with this appreciated skills:

  • dataviz previous experience
  • particles system expert
  • c# plugin programming
  • good graphic taste

Period: form last week of February for 2/3 weeks
Working place: studio dotdotdot.it in Milano

For any further information please do not hesitate to contact me: alessandro(at)dotdotdot.it

Thank you!

ales9000, Monday, Feb 9th 2015 Digg | Tweet | Delicious 1 comments  

Hey guys,

due to my Master-Thesis, I developed a new textbook with a bunch of tutorials using vvvv & Arduino with smell. Big thanks to westbam, 2nz and sorik, who helped me with the technical part here: http://iurl.no/263e4

Next step is to prepare it for the public. But this will take a bit time due to finding nice possibilities and licensement issues. Feel free to follow this project on my other socialweb platforms! Hope you like it. ;)


"Smelling Data – Translating data into scents with Arduino & vvvv"

There is no sensory perception that holds so many unanswered questions as the smell. Every day we smell thousands of different odors, making it the essential companion in our everyday life. But can we design smell? Or design with smell? If so, what possibilities do we have to get creative with smell?

With the textbook "Smelling Data" a practical introduction to the world of creative usage of olfaction is offered. It aims to provide designers a first approach to design with odors in combination with analog and digital media – and this may raises us an awareness of odors.

A basic knowledge on the subject of "smell" as well as the programming environments "vvvv" and "Arduino" are mediated. In addition, a variety of odor scenarios are discussed exemplarily on the basis of 10 instructions. Starting from simple scent-emitters to an odor-printer to interactive prototypes with which you can convert any code into odors.

Info: http://www.marklukas.de/smellingdata/
Facebook: http://www.facebook.com/smellingdata
Twitter: http://www.twitter.com/smellingdata

markusch, Saturday, Feb 7th 2015 Digg | Tweet | Delicious 2 comments  

2015.1.24 Japan meetup vol.3

We held vvvv Japan meetup every month.
We have a workshop and information exchange.

Japan Meetup vol.1https://atnd.org/events/59112http://junky-inc.blogspot.jp/2014/11/vvvvvvvv.html

Japan Meetup vol.2https://atnd.org/events/59754http://qiita.com/yhy_jp/items/29102ebea94fba729b16

1.For Beginner: Basic Operation
2.About Spread
3.vvvv and difference in another language(Max/msp/jitter, Pd, Touch Designer...and so on)
4.Lightning Talk

Japan meet up vol.3

Spread Sample Patch is here.https://drive.google.com/open?id=0B-aWXftvAHSxMURuQ2twMkpjczg&authuser=0

Junki Yoshioka

Junky_Inc, Thursday, Feb 5th 2015 Digg | Tweet | Delicious 0 comments  

Who Tebjan Halm
When Sat, Jan 31st 2015 - 17:00 until Sat, Jan 31st 2015 - 17:00
Where RCA Kensington, 2-6 Jay Mews, SW7 2EP, London , United Kingdom

It is a pleasure to invite all vvvv interested people in London to a replay of the vvvv50 intorduction talk from scope sessions at the RCA Kensington in the Stevens Building.

It is on very short notice, but I hope that a few patchers can make it. So spread the word!

Big ups to hadasi who managed to find the date.

In the past few years we’ve been eagerly working on a complete rewrite of vvvv which lead to a new visual programming language in combination with a development and runtime environment. Tebjan Halm (tonfilm ) will give a short introduction into the key features of this new language we’re internally calling "50".

tonfilm, Saturday, Jan 31st 2015 Digg | Tweet | Delicious 3 comments  

helo patchers,

here is the fourth 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:

  1. 50: That-Next-Big-Thing.-An-Overview.
  2. 50: Colors
  3. 50: Properties
All information given here is still preliminary and subject to change.

So "Generics", uff, sounds so serious, I know. Still we have to mention them now because it will help you understand things further down the road. And you'll be surprised how easy the concept is to grasp. Promised.

No generics in 45

In vvvv45 (45) we don't have generic nodes. What we have instead is a lot of identical nodes like eg. "Zip" available for different datatypes. There is a Zip (Value), a Zip (String), a Zip (Color)... and the nodebrowser is full of such duplicates for a lot of nodes, like GetSlice, Select, Queue,... all of which are nodes where the operation they do for us is actually independent of the datatype they handle. We can call such operations "generic" in the sense that if for example you think of the functionality of a Zip it is not really important to know whether it zips slices of a spread of strings or a spread of colors. Easy? Yep.

In a 45 patch nodes like Zip already look generic because precious screen-space is saved by leaving out information that would not help in understanding the functionality of a patch. Still the nodebrowser is full of duplicates you have to explicitly choose between.

Only recently we've introduced a way for plugin developers to easily create duplicates of those generic nodes for their own datatypes but that is really only a workaround to the fact that we don't have support for generics built right into 45. Still better than nothing, see: generic-nodes.

Generics in 50

Now when we say 50 has support for generics we can advertise that in two ways:

For the casual patcher

First, the nodebrowser will have less nodes to choose from because it can leave out many duplicates (well, it will have many more other nodes but at least no datatype-duplicates). If you want a Zip you don't have to decide for which type you want it. Just place it in the patch, connect anything to it and you're done. 50 will figure out what you mean.

In a 50 patch a zip is a zip is a zip and you can connect any datatype to it. So in this example the left zip is forced to operate on values and the right zip is forced to operate on colors only.

For the pro patcher

Secondly (and this is probably a bit more abstract to wrap your head around, but please try:) when you patch an operation you can be unspecific about the datatypes of its inputs and outputs. Sounds exciting? Here is an example: Consider someone patched the functionality of a Queue. This is what it could look like in 45 and 50:

Queue (Value) in 45 vs. Queue (Generic) in 50

Reading those two patches:
The Inlets and Outlets (Item, Insert, ..) of both implementations are the same and the FrameDelay, as we've already learned, is replaced by a property (called "Items" here). And while both kind of look generic, in the 45 implementation we see the Item obviously is a value IOBox. Therefore we know that this is a specific implementation for values.

In the 50 implementation you see all the operations (clear, insert, take) are working on the generic collection type Spread, ie. they have not yet been forced to operate on a specific type like Spread of value or Spread of color. And you can easily identify pins, in- and outputs and the property that are generic as they are visualized in a different way (ie. only showing their contour). So here is a single implementation of a queue that works for any datatype at a time, even ones that you create yourself (more on that in the next post).

What you take away here is that 50 comes with a set of generic spread operations (insert, take, zip,...) for handling any kind of data and the problem you sometimes faced in 45 where individual spread operations were only available for specific datatypes, is no more.

And the best of it all which is really only a side-note here:
For all those basic generic spread operations we don't have to write a single line of code. In 50 we can magically make use of that functionality as it comes with the .net library. Besides the fact that this saves us a lot of time it also means those basic operations can be assumed virtually bug-free, not only because we didn't write them but also because Microsoft has been taking care of testing that code since years.

That just for a little soothing happynew50 update. Now fasten your seatbelts for the next issue with the blockbuster title "Custom Datatypes".

If what you just learned makes you feel like inserting coin, don't hesitate and click: .

joreg, Thursday, Jan 29th 2015 Digg | Tweet | Delicious 8 comments  

helo patcherpeople,

look what i found: openFrameworks 2013 survey results. that made for an interesting read so i thought we can rip that off and have our vvvvery own. you in?

what struck me though is that they only got 368 respondents, which doesn't seem a lot. can we get more? here is the URL to promote:

The 2015 Survvvvey

looking forward to getting a better idea of who we're dealing with here all the time.

joreg, Friday, Jan 23rd 2015 Digg | Tweet | Delicious 15 comments  

anonymous user login


~18h ago

rrrr: Timeliner curve editing, how to do it: https://twitter.com/iangeek/status/569810168969601024

~22h ago

StiX: i think i alredy used it once, but i might be just confusing constructing my own mesh with getting stuff out of a buffer

~23h ago

evvvvil: you mean like vertexbuffer dx9 node Stix? I would use a compute shader... you're saying there is a dx11 node that does this?

~1d ago

StiX: i think i went blind, i cant find a way how to get vertices positions from geometry buffer, can someone point me to the right node?

~3d ago

guest: @microdee wonder how they did it? https://github.com/mono/CppSharp

~3d ago

microdee: https://mono-ue.github.io/ C# in Unreal Engine 4 huzzah