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


new post

Blog-posts are sorted by the tags you see below. You can filter the listing by checking/unchecking individual tags. Doubleclick or Shift-click a tag to see only its entries. For more informations see: About the Blog.

  reset tags

addon-release core-release date devvvv gallery news screenshot stuff
delicious flickr vimeo
Order by post date popularity

Pretty early in its devvvvelopment vvvv introduced an automatic patch conversion system that allowed us devvvvelopers to change nodes' behaviours, namings and defaults under the hood, while converting users' patches in a way that no damage is done to old patches.

The diffff.xml file in vvvvs lib folder has all the info of changes between the different versions.
In many cases we ship legacy nodes with the unchanged behaviour but now change their name to reflect that they are legacy. The diffff.xml then only needs to convert the old patches in a way that the legacy node is taken and not the node with the new behaviour...

Since we now also have pretty huge packs, managed by external devvvvelopers, we now also introduce versioning per pack.
Packs from now on may ship a version.info file and a diffff.xml file.
When vvvv starts up it figures out which packs are loaded and stores the versioning infos of all packs into the patches to be able to convert them later on.

If you are an author of a pack or just want to learn more about pack versioning, please have a look here:
This folder shows you some ideas about conversion and also back conversion.

If you feel like it, you could temporarily move this folder into your packs folder to have a try.

Read the diffff.xml for further info. You might want to use this as your starting point when creating your own diffff.xml.

have ffffun!!

gregsn, Sunday, Feb 9th 2014 Digg | Tweet | Delicious 0 comments  


recently we made a few (partly long requested) changes to vvvv that were finally necessary with the advent of win8.1 which caused some things to break. so here we are:


vvvv is now fully dpiAware meaning you can finally use it at any OS zoom level which you can set via:

 Control Panel\Appearance and Personalization\Display 

fonts will stay crisp and nodes/pins will sit at their right place.


in order to be able to basically operate vvvv on windows tablets we introduced simple touch support. as you're used to from your favorite OS think: rightclick = double-tap (or windows standard: index-longpress) and middleclick = index-press + middle-tap. so in other words:

  • Two finger pan = Canvas pan
  • Press and Tab = Middle Mouse Click
  • Two Finger Tab = Right Mouse Click (not shown in this video)
  • Long Press = Right Mouse Click
  • Long Press + Drag = Right Drag

that should do for a start..


we've now turned on the /dx9ex switch by default on win>=vista. if for some reason you still need the old version you can now fallback by using /dx9 as a commandline parameter.

the only reason i can think of that you'd want to switch back to /dx9 would be that you need to use Text (EX9.Geometry) or Flash (EX9) which are the only 2 nodes that will no longer work with dx9ex.


also crack.exe is now checking for .net4.5 on win>=vista to make sure plugins possibly written in .net4.5 don't ruin everything. win8 comes with .net4.5 anyway so this will only be an issue for Vista and 7. and since the vvvv core does not yet make any use of .net4.5 features running on winXP (which cannot install .net4.5) is still possible, see also: plugins-targeting-.net-4.5

for even more fixes also check the Change Log.
and so before we make those all into a beta we'd like to ask everyone to take the latest alpha for a spin and report related issues in the alpha forum. the simplest test would be to just open your current project and see if everything behaves as expected. this is your last chance to complain for before beta32.

have a good patch.

joreg, Monday, Feb 3rd 2014 Digg | Tweet | Delicious 5 comments  

there has been quite some confusion in the past whether or not it is possible to write plugins for vvvv targeting the .net 4.5 framework.

.net 4.5 is an in-place update to .net 4.0, which means that as soon as you install .net 4.5, your 4.0 installation will be replaced and you'll be able to write plugins targeting 4.5.
as it is an in-place update the assembly version (like System.Core of the .net class library will stay the same, whether you target 4.0, 4.5 or 4.5.1 - so don't get confused by that.

  • if you're using vvvvs built-in CodeEditor you can simply use 4.5 features. note however that our code editor doesn't do proper syntax highlighting and code completion for 4.5 features yet.
  • if you're using VisualStudio or SharpDevelop to write your plugin you need to set the target framework to .net 4.5 in the project settings of your plugin. this needs to be done because VisualStudio and SharpDevelop use the MSbuild tool chain resolving referenced assemblies at compile time using a .net sdk installation, of which you can have several, for each individual .net release. our code editor uses CodeDOM for resolving references using the currently loaded .net runtime and therefore this step is not required.
if you do target the .net 4.5 framework or use features of 4.5 in a dynamic plugin, the target machine where your patch will be running on needs to have a .net 4.5 installation, which is only available on windows vista and later versions.

for more details regaring .net framework versioning see http://msdn.microsoft.com/en-us/library/bb822049.aspx

Elias, Thursday, Jan 23rd 2014 Digg | Tweet | Delicious 1 comments  

As promised a year ago there are no more vvvv releases on the 24th of december.

But that does not stop any of us to release stuff on the 25th of december.
With great pleasure the first alpha preview of the new vvvv audio engine is here in the beloved vvvv-pack format. The focus of the engine was not so much DSP programming but flexible signal routing for large scale installations and VST support: vvvv.audio-pack-alpha

But that's not all, the latest addonpack contains all of bjoerns combinatorics nodes. They should give you quite some fun when working with indices.

And here is a little x-mas amateur demo video of the audio engine:

Have some nice holidays with the new toys!

And be aware, its windows only!


tonfilm, Tuesday, Dec 24th 2013 Digg | Tweet | Delicious 13 comments  

There's been another update to the mouse and keyboard nodes before but that turned out to still cause troubles:

  • key presses could still be missed (think: typing too fast on typewriter)
  • global keyboard didn't work properly with all applications
  • mousewheel didn't work globally
  • no nodes to deal with touch devices (2013! hellooo!)

Now there've been notable contributions to work around some of those issues, like windowstouch, global-keyhook and directinput-(devices) but those being really basic things we thought we'd give it another shot.

So here is what you get:

  • Keyboard and Mouse nodes in variants: Desktop (was: Global) and Windows
  • where Keyboard and Mouse (Desktop) are spreadable (ie. understanding multiple keyboards/mice attached. quite nerdy, what you think?)
  • a new Touch (Devices Window) node
  • all those nodes come with a Queue Mode to distinguish Enqueue (don't miss anything) and Discard (just take the latest) modes
  • KeyStates, MouseStates and TouchStates split-nodes (for comfortable use in subpatches)
  • KeyEvents, MouseEvents and TouchEvents split-nodes (allowing for advanced ... stuff)
  • join-nodes for some of them

like so:

Device type Source nodes Sink nodes
Keyboard Keyboard (Devices Window)
Keyboard (Devices Desktop)
KeyEvents (Keyboard Join)
KeyEvents (Keyboard Split)
KeyStates (Keyboard Split)
Mouse Mouse (Devices Window)
Mouse (Devices Desktop)
MouseEvents (Mouse Join)
MouseStates (Mouse Join)
MouseEvents (Mouse Split)
MouseStates (Mouse Split)
Touch Touch (Devices) TouchEvents (Touch Split)
TouchStates (Touch Split)
As you can see from the table not all possible combinations have been implemented. We concentrated on those which we felt had a good use case.

For the plugin-developer:

  • Plugins that are using the (now) legacy "KeyboardState" and "MouseState" datatype don't need to be modified - vvvv is gracefully taking care of this with an auto-wrapper.
  • The new "Device" datatype merely is a wrapper around a push based sequence of Device notifications. See KeyboardNodes.cs for an example of how to use it in your new developments.

all available now for testing with the latest alpha builds

Elias, Tuesday, Dec 10th 2013 Digg | Tweet | Delicious 13 comments  

Due to our recent build server change, we accidentally broke the fetch-binaries script, which gets called by various post merge/checkout hooks installed by the init script and so in turn we managed to break the whole checkout/pull procedure :/

Sorry for that.

We decided to get rid of all these post merge/checkout hooks entirely and let the user decide when to invoke the fetch-binaries script for the following reasons:
The init script was used in the past to install post merge/checkout hooks to your local .git folder. These hooks did stuff like updating symbolic links or downloading a matching vvvv.exe from our build server. We got rid of the symbolic links about a year ago and the automatic download of a new vvvv.exe everytime you switched a branch started to get cumbersome.

Now in order to get everything running again you'll first need to delete those broken post merge/checkout hooks installed in your local .git folder.
Navigate to vvvv-sdk\.git\hooks and delete all non-sample files like this:

You can now do the usual

 git pull upstream develop

And after ensuring that powershell 3.0 is installed (installed by default on windows 8) you can fetch a matching vvvv.exe (32 bit) with


Or in case for a 64 bit version do a

 scripts/fetch-binaries x64

We've also updated the vvvv sdk page to reflect these latest changes.

Elias, Monday, Dec 9th 2013 Digg | Tweet | Delicious 3 comments  

When writing a plugin for vvvv the developer needs to at least add a reference to the VVVV.PluginInterfaces assembly. In order to do so there've been two choices up till now:

  1. Reference the assembly directly (e.g. from a vvvv-release)
  2. Reference the VVVV.PluginInterfaces project from the vvvv-sdk

Both of these choices have drawbacks. Referencing directly requires the developer to update the assemblies manually with every new vvvv release, referencing the project enforced the inclusion of the whole vvvv-sdk which is quite large and sometimes tiresome to build.

Thanks to NuGet (a package manager for the windows development platform) and TeamCity (a build and NuGet server) a third choice emerged without the drawbacks mentioned above: referencing the assembly via a NuGet package.

Everytime our build server builds a new version of vvvv, it will also create a bunch of NuGet packages (VVVV.PluginInterfaces, VVVV.Utils, etc.) with the appropriate version information. When doing an alpha build those packages will be considered as a so called pre-release package by NuGet, when doing a beta build those packages will be considered as a stable release.

All packages prefixed with VVVV. are intended to be used for plugin development only and will therefor install all references in a way so that they won't get copied to the output folder (Copy Local set to false). This was done to avoid assembly conflicts at runtime.

Now in order to create a plugin for vvvv by using NuGet, the developer has to:

  1. Ensure the project is targeting at least .NET Framework 4.6.1 and is configured with the platforms x86 and x64.
  2. Add http://teamcity.vvvv.org/guestAuth/app/nuget/v1/FeedService.svc/ as a NuGet package source in the settings of the NuGet package manager shipped with either Visual Studio or Sharp Develop.
  3. Select the VVVV.PluginInterfaces package and click install.

NuGet will now download and add all the necessary dependencies to the project file and whenever a new version of vvvv is available, the NuGet package manager will ask whether or not to update the installed packages.

When installing the packages it might happen that the IDE won't find the referenced assemblies immediately (putting a warning sign on it, or not even showing them). In such a case ensure that the solution build configuration is setup properly (most of the VVVV.* packages are only available for x86 and x64, not AnyCPU) and/or reload the whole solution.

As of version 34.101 the packages should work in AnyCPU - for details see here

As of beta35 the official vvvv packages on nuget.org contain the AnyCPU configuration. no need for 'pre-release' setting or special nuget server anymore, unless you need features that are only available in the current alpha releases.
Elias, Thursday, Nov 28th 2013 Digg | Tweet | Delicious 18 comments  

This was long overdue. While patching with vectors it happens quite often that you have to convert from 2d to 3d or vice versa. Until now you had to create the appropriate vector join/split nodes and connect the components with each other. this is history. the new swizzle nodes should cover 90% of those cases.

And while at it, the vector join/split nodes got a rewrite and are now 4-5 times faster.

Try it out in the latest alpha build and report the bugs as usual.


tonfilm, Thursday, Oct 31st 2013 Digg | Tweet | Delicious 3 comments  

Announcing a random new feature: ctrl+F10 to toggle debugging spreadcounts

A link can have any of 4 styles:

  • dotted: when carrying ø
  • normal: when carrying 1 slice
  • thin: when carrying a slicecount less than half of the patchs maximum spreadcount
  • thick: when carrying a slicecount greater then half of the patchs maximum spreadcount
  • fat: when carrying the patchs maximum spreadcount

We hope this to be specifically usefull when teaching beginners about spreads or hunting for large spreads or ø.

Available now in latest alpha builds

joreg, Tuesday, Oct 22nd 2013 Digg | Tweet | Delicious 6 comments  


this is to update you on some recent fixes on boygrouping. As has been pointed at in this thread boygroup-(critical)-bugs there've been some unresolved buggers after the transition to a new networking library vvvv had to undergo with the all the unicode/64bit updates for beta29.

Here's whats fixed:

  • clients/server can again be started in any order and will find each other
  • clients again try to reconnect periodically when they lost connection
  • a memory leak that kept a copy of each graph-dump for each client is closed

There is a thing though that may cause troubles but has to be solved patchwise: By default vvvv sends value-changes in the graph via udp but switches to sending via tcp if a message is too large (ie. a spreadcount too high). Please read the updated section boygrouping basics#warnings to understand how to detect those bottlenecks and how to deal with them.

Those fixes should get your boys back n'sync.
Please check the latest alpha builds for those changes.

joreg, Thursday, Oct 10th 2013 Digg | Tweet | Delicious 2 comments  

anonymous user login


~3d ago

skyliner: wanna do drone shows or applications? then check this super cool project of our man e1n

~7d ago

NoseBleedIndustries: Thanks Joreg! The few minutes I was able to see, very good workshops!

~7d ago

joreg: @NoseBleedIndustries please give us some days, we'll have an announcement soon...

~7d ago

NoseBleedIndustries: I could not assist the Node20 (workshops ) Any Idea when we will have access to the links of the recordings?

~9d ago

bjoern: unity has c# bindings for usd, under apache license: https://github.com/Unity-Technologies/usd-unity-sdk

~17d ago

ravazquez: @synth yes they are being recorded and will be available for future consumption

~17d ago

synth: Another stupid question: Are all #NODE20 sessions recorded and accessible for later viewing in case someone missed something?

~19d ago

joreg: Get a fresh drink and some snacks: Live in 45 minutes: #NODE20 opening: https://youtu.be/SlKKyEUihhY