» 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

Update: The latest preview version is here: http://visualprogramming.net

Moments later,...

...we're announcing the immediate availability of the vvvv gamma 2019.2 series of previews, finally including one of the more anticipated features in vvvv history: Executable Export.

This means we are now in the final stage of the preview leading up to a proper initial release after the waves introduced by the new features in this series have been smoothed out.

Her majesty... at your service.

What's new compared to the vvvv beta series


  • Trivial installation via an installer
  • The overall performance is much improved
  • Projects can be exported as executables
  • All your work is automatically backuped
  • A help browser: press F1 without any node selected
  • Helppatches opening when pressing F1 with a node selected
  • You have quick access to your recent sketches
  • By default projects are now handled in one file
  • There are central settings per user, overridable per project
  • You can pause and step your patches frame by frame
  • Extensibility: Write plain C# to extend vvvv with custom nodes
  • Simply use almost any .NET library available e.g. on nuget.org
  • Proper scope and dependency handling
  • Structured documentation for your patches. Add summary, remarks, help to elements
  • Being close to C# allows for VL help to be found on msdn/stackoverflow


  • Patches are now zoomable
  • You can use frames to structure your patches visually
  • UI runs in its own thread
  • Tooltips show help and errors
  • IOBoxes allow for much faster configuration
  • You can doubleclick a link to insert a node or finish a link with a doubleclick to create a node
  • Patch your own pingroups
  • The color theme is now customizable and defaults to dark


Besides staying true to its nature of being a an easy to use and quick prototyping environment, vvvv is also a proper programming language with modern features, combining concepts of dataflow and object oriented programming:

  • Define your own datatypes (Classes and Records)
  • Composed Datatypes (Spread of Spread,..)
  • No more binsizes needed!1!!
  • Loops to iterate within one frame
  • Recursive patches
  • Generics
  • Delegates
  • Reactive programming
  • Async data processing (multi-threading)
  • Easy caching of expensive operations

Node Library

While for now the number of libraries we ship is limited, the fact that you can essentially use any .NET libary directly mitigates this problem at least a bit. Besides there is already quite some user contributions available in the wip forum and here is what we ship:

  • A thorough core library for all your basic needs
  • State of the art 2d drawing with VL.Skia
  • Effortless computervision via VL.OpenCV
  • Support for Midi, OSC, ArtNet, Serial,...

Tutorials and HowTos

A growing number of video tutorials is available on youtube.


We've announced the pricing model of vvvv gamma in a separate post. Until further notice, the previews of vvvv gamma are free of charge but due to its preview-nature we don't recommend using it in commercial scenarios yet.


Here you go: vvvv gamma 2019.2 preview 321



321 04 03 20

  • Fixed copy-paste of output pins not merging correctly into target patch
  • Fixed patch pins not always being synced to nodes with the "Connect to Signature" flag
  • Do not create empty regions (nodes without a patch) when syncing to a node definition which lost its delegate input
  • Should an incremental compilation of a project fail, try from scratch before giving up.
  • Fixed implicitly inserted CreateDefault node not being tracked in dependency graph - fixes backend crash when modifying it
  • Fixed assembly initializers being called far too often leading to long hotswap times in bigger projects
  • Fixed regression that enums don't have System.Enum as super type anymore (was for example breaking VL.Devices.Kinect2)
  • Fixed vvvv.exe becoming a ghost process when crashing on startup
  • Fixed disposable interface being added twice when VL.CoreLib was missing - caused subsequent emit crash
  • Only load project assembly from cache if all its dependencies have also been loaded from cache - fixes emit error when dependent project was modified
  • Backend will now unload not needed project states
  • Faster RGBA to RGB conversion (IImage to SKImage)
  • Fixed cast exception triggered by node browser when browsing through nodes from assemblies
  • Fixed various crashes when opening a completely broken document structure (missing assemblies, missing documents etc.)
  • Fixed file/string readers not eliminating BOM
  • New nodes Loop [Observable], Subscribe (Provider) [Observable], Using (Provider) [Observable] and moved PollData, PollResource from Resources to Observable category
    • New region Loop [Observable] managing internal state as well as giving access to cancellation and observer to optionally push data
    • Subscribe [Observable] returning a provider which manages the lifetime of the upstream observable sequence
    • PollData and PollResource now stateful internally thanks to making use of new Loop
  • Removed recently introduced TryOpen/Retry/RunOn [Resources] nodes as they turned out as hard to use (deadlock) and not necessary
  • Added new struct ArrayBuilder used by two new nodes:
    • StoreSequence [Collections.MutableArray] to efficiently either grab an upstream array from a sequence or copy its content into an internal array which will then get exposed.
    • HoldLatestCopy [Collections] to efficiently copy data pushed from a background thread into the main thread
  • Bunch of minor performance improvements to VL.Skia by making use of methods provided by the System.Runtime.CompilerServices.Unsafe class and calling SKCanvas.SetMatrix in Transform nodes, not rendering nodes
  • Fixed allocation issues of Points [Skia.Layers] by exposing internally used DrawPoints via ReadOnlySpan
  • Fixed assignment of higher order regions not being carried over to expanded patch
  • Ensure names of emitted assemblies are unique even after reloading a document
  • Type Unification got even more robust and versatile. Better type renderings and type error messages.
    • generic node applications with generic pins (like "a Asset") previously just lead to type "Asset" for the generic pin for as long as the pin was still unconnected. This way you often had to force connections. Now these type parameters stick around leading to not calling the node until to the point where you actually connect to something.
    • types can look like this: "a Asset". This is a short rendering for a constrained type parameter "T1 where T1: Asset". F# also has an abbreviation for types like this. They call it flexible types.
    • types can look like this: "Sequence (Ungeneric) & IReadOnlyList<T>" which is a beautified rendering for "T1 where T1: IEnumerable, IReadOnlyList<T>"
    • if necessary (like on recursive types) the type parameter will not get hidden. "T1: IReadOnlyTree<T1>" is not hiding the T1 behind an "a IReadOnlyTree<T1>" in order to make clear that it references itself.
    • invalid type annotations (those where the type arguments of the user break the constraints of the type parameters) lead to proper error messages.
    • quite less emit problems due to more robust type unification
  • Added RemoveAll for Spread and SpreadBuilder
  • Fixed Random node not being thread safe
  • Fixed ForEachParallel crashing with input count of zero and modified it so it returns a spread builder instead of a spread to avoid allocations

236 18 02 20

  • added ShowOrigin setting
  • More type inference fixes
  • Fixed primitive types not having any super types like IComparable (was reported in chat by sebl)
  • Fixed type constraints on higher order region with one single patch not properly generated should the name of the inner patch have changed
  • Fixed "auto connect to signature" of patches like CreateDefault which have a fixed set of pins
  • Fixed output pin groups of type Dictionary<string, obj> not working anymore when pin on application side was annotated
  • Fixed compiler crash when having a generic type annotation in a patch
  • Fixed CLR array types not being mapped to type symbols
  • Removed Spread.Pin/Unpin - same functionality is available through much safer TryGetMemory/Pin -> MemoryHandle.Dispose path
  • Fixed pixel format being swapped from R8G8B8 to B8G8R8A by SKImage.FromImage node
  • Fixed null pointer when trying to navigate into patches of completely broken documents
  • Fixed higher order regions not working when definition added an inner pin
  • Added a few convenience nodes for resource providers useful when opening and polling devices. Even though not yet released they already look promising for devices like Kinect or Astra.
  • Fixed minimal changes on solution made by compiler getting discarded (pin order somtimes not updating on application side)
  • Fixed pin group builder (ModifyPinGroup) changing the model when it shouldn't
  • Fixed repeat loop not working on inputs of type T where T : IReadOnlyList

211 07 02 20

  • Don't use BOM in UTF8Encoding
  • Backend generates new lines on its own without having to rely on super heavy NormalizeWhitespace function. This should get rid of very long compile times when traversing deeper into a library. Debugging the generated C# code with Visual Studio will only work properly when running with -debug and -nocache flags
  • improved type unification cleverness and stability
  • Helpbrowser: chat language buttons added
  • AppExporter "Export" button gives immediate feeedback

0193 31 01 20

  • fixed pin-reordering in signatures as reported here: https://discourse.vvvv.org/t/2019-2-0081-pin-reordering-buggy-behavior/18132
  • Removed private flags between our package dependencies as it caused msbuild to skip copying certain assemblies coming from VL.CoreLib as well as making our packages smaller.
  • Fixed parts of patches being grayed out and when traversing inside becoming all good - compiler was missing one iteration in recursive blobs -https://discourse.vvvv.org/t/lazy-type-inference/18066
  • improved support for helppatches
  • Reworked error handling of CreateDefault and RegisterServices operations
  • Extended the general renaming code path to handle all cases and removed obsolete rename commands
  • The Micorsoft Build Tools 2019 are now optional. If not installed the Export menu entry will be disabled
  • Removed the .vl suffix on generated executable and fixed Run button

0169 22 01 20

0140 09 01 20

  • Fixed ToObservable (Switch Factory) - used by many reactive nodes - not calling the factory after the element type changed due to a hotswap
  • Added HighDPI awareness to App.config for exported apps
  • Fixed stack overflow when patching a CreateDefault - system will now generate an error as long as the output is not connected
  • The default value of a record will again be cached in a static field
  • Fixed serializer serializing auto-generated fields
  • OSCMessage (Split) now returns timetag
  • CTRL+Shift+F now also finds interfaces
  • updated VL.OpenCV to 0.2.133
  • fixed problem with pin-editor for serializable types like Rectangle
  • Splash screen shows up in taskbar and has proper icon
  • Counter Clamp/Wrap/Mirror reset under/overflow correctly
  • NodeBrowser now has a TextBox that can select/copy/paste
  • Fixed regression that bang and press IO boxes would sometimes stick to true

0081 16 12 19

0026 10 12 19

0015 06 12 19

  • Patch drawing is antialiased and icons are showing again
  • Fix for drawing transparent PNGs
  • Fixed regression that delegate regions wouldn't create their pins anymore
  • Emit exception will show first error now as it's message
  • Fixed specialized operations not being marked as unused if there containing type was - seehttps://discourse.vvvv.org/t/gamma-x-2-breaking-not-opening-old-patches/18036

Compared to the 2019.1 series

  • Export to executable
  • Faster startup and less memory consumption due to precompiled libs
  • Recursive operations and datatypes
  • Runtime errors: marked node is now always correct
  • Generated C# code can be debugged using Visual Studio
  • Help patches (where available) open when pressing F1 on a selected node
Breaking Changes

Unfortunately this preview introduces some breaking changes. This means that projects that were working fine with 2019.1 previews may no longer work correctly with 2019.2 previews! If you encounter such a situation and cannot resolve it on your own, please get in touch via forum or chat! Here is a list of possible problems you may encounter:

  • Existing patches may need additional type annotations due to changes in the type unification
  • Execution order of nodes may be different if it wasn't explicitly expressed before
  • Generic type parameters in an interface patch will now always belong to that defined interface (and not any of its operations)
  • Not really breaking, still a change: Runtime errors: no values in tooltips when in pause state

For technical details please see the blog post about the New Roslyn based backend.

We'll update this blogpost with new preview-releases regularly. Please check back often and report your findings in the chat, forum or a comment below!

Yours truely,

joreg, Wednesday, Mar 4th 2020 Digg | Tweet | Delicious 1 comments  

Previously on vvvv: vvvvhat happened in January 2020

Bonjour from paris,

where I was happy to witness a short AV performance by dottore which he developed as part of a residency with us. vvvv gamma + VL.Xenko used to its finest...

Still by Natan Sinigaglia

Right after we had a nice vvvv meetup in a local bar and talked Xenko and timelines till late. Up next are workshops on Tuesday and Thursday and a presentation at Ircam on Friday.

Meanwhile back on vvvv.org we opened a new store and our call for creative coder in residency is still going till March 8!

With vvvv gamma we're getting closer to a release-candidate phase. We still have a few known issues we want to sort out before, but no more show stoppers. Please follow our progress and fetch latest previews from here.


An update:

And there's been quite some action in the work-in-progress section on the forum:


readme and Max about "Beathoven" at the last vvvv meetup in Berlin


That was it for February. Anything to add? Please do so in the comments!

joreg, Tuesday, Mar 3rd 2020 Digg | Tweet | Delicious 1 comments  

Helo shopaholics!

This is to announce vvvv's new License Store.

When logged in with your vvvv.org credentials you can see an overview of all your orders, which should look something like this:

Please compare this listing to your previous order listing. In case you're missing an order in this view, let us know via licensing@vvvv.org. We've tried our best to import old orders but there is a chance that some may not be correctly assigned to your account yet.

This is also a great moment to check your current licensing situation: Please make sure all your commercial use is covered. If not, we're looking forward to your new orders. Try it, it is now more fun than ever to buy vvvv licenses! And also check the price-drop on the dongles: From 125€ to 80€ per piece. What a bargain!

Next Steps

We know everyone is waiting to finally be able to buy vvvv gamma licenses. Just in time with the upcoming first official 2020.1 release, we'll have those in stock. These will initially come without the promised subscription options, but the plan is to have those added just in time so that any order can be converted to a subscription before its first update.

Then, obviously this new store was also built with the idea in mind that it can one day sell user contributions. We cannot promise anything at this point, but at least we have the technical infrastructure in place now...

Happy shopping!

joreg, Wednesday, Feb 26th 2020 Digg | Tweet | Delicious 0 comments  

Previously on vvvv: vvvvhat happened in December 2019


work continues as per the usual on our quest to release a smooth vvvv gamma 2020.1 within Q1. Previews are coming out about once a week now. Most recently we introduced another improvement for help patches.

We have a progress report on VL.Xenko out and in parallel, we're also working on a ContributionManager for vvvv beta, which is ready for a test-drive now.

Into numerology? You may be interested in last year's numbers and figures.

And if you're up for meeting your fellow patchers in real-life, make sure not to miss our upcoming intro workshops, meetups and patching circles in Berlin. Here is the stream of our most recent meetup where we heard news from ur-patcher sunep.


A new one:

An update:

And there's been some action in the work-in-progress section on the forum:


Refik Anadol: “Latent Being” - Trailer

And also make sure to check out this little gem by Juan Hurle: Fractal Armor


Some more on dasauge.de

That was it for January. Anything to add? Please do so in the comments!

joreg, Thursday, Feb 6th 2020 Digg | Tweet | Delicious 0 comments  


One of the most requested features for VL ever since was the support for help-patches. Obviously they had to come back, but it took us a while to figure out how exactly. One of the brainstorming sessions at LINK was especially helpful to sort out the details. Thanks everyone for your input...

Help Patches

So for the user it is just as before: Press F1 on a node that you need help for. Now what happens is:

  • If a help-patch is found, it is opened and a bubble indicates the node you were looking for
  • If no help-patch was found, a bubble indicates that no help-patch was found
Help patch was found...
No help patch available...

In both cases, you can now optionally opt-in for more help: Click the bubble to open the help browser showing the nodes Node Info.

Node Info

Shows some info about the node plus 3 lists of how-to patches this node is used in:

  • most relevant (the dedicated help-patch)
  • still relevant
  • list of other patches using this node (automatically generated)

This should increase the chance of finding good info about how a node can be used in different scenarios.

When "follow mode" is active, you can click around in the patch and always get the node info to the last selected node.

Help Flags

Creators of libraries who want to provide help patches now use help flags to indicate relevance for a node. Read all about using help flags in the graybook.

Available for testing in latest previews!

joreg, Friday, Jan 31st 2020 Digg | Tweet | Delicious 2 comments  


is probably not exactly the word you'd use to describe vvvv's 2019 numbers. If you can't handle bumpy roads, please set your Damper to ~2s before reading on... Not sure what this is all about? Check out last year's numbers of 2018 to make yourself familiar with this vvvvery tradition. Then pull yourself together:


While we still don't have any new numbers from vvvv.org itself we do have what the forum tracks. It shows us different statistics regarding user engagement over time that are generally, how can I put this... not improving recently. The most uplifting I found was this:

DAU/MAU - daily divided by monthly active users

According to the description of the graph, this indicates your stickiness in % and 30% is to be aimed at. Even though overall fewer things are happening on the forum you keep sticking around. Who could blame you, after all, it is rather cozy around here. Here is another one that doesn't look all too bad:

Page Views

Ignore the red ones (crawlers) but see the rather constant number of logged-in users (dark blue) and the curious spikes at the end of December from anonymous users (light blue). Are these already the harbingers of numbers to expect when we finally will have an official 1.0 of vvvv gamma out? (hums) Dreams are my reality...

Not really numbers, but still interesting, here is a listing of top forum search terms in order of your priority:

realsense, kinect, image compare, orbbec, dx11, ndi, kinect2, arduino, opencv, zgl, osc, gamma, particles, dmx, addflow, superphysical, midi, /logstartup, fbx, audio, face, skia, touch, dds, projector, text, scroll bar, firmata, fieldtrip, ilda, linux, leap, point cloud, camera, csv, yolo, artnet, tracking, html, mac, fluid, svg, texture, laser, leap motion, contour, gif, websocket


2010 2011 2012 2013* 2014* 2015* 2016* 2017* 2018* 2019*
vvvv beta releases 4 3 5 5 5 4 1 4 8 1
core 45.700 32.100 36.000 45.000 42.500 38.000 29.300 32.600 61.700 22.000
addons 10.700 14.400 18.800 29.000 28.500 25.200 19.400 21.400 38.800 11.000

* x86 and x64 combined

What can we say? Only 1 release was really lame. But was it? Ok, yes, it was, but the way I'd like to whitewash these numbers a bit is that they are only reflecting vvvv beta, when obviously most of our work (to some of your's concern) went into VL and vvvv gamma. And inconveniently we don't have any numbers for vvvv gamma downloads at all. But then again those wouldn't be high numbers also because as you know we're still keeping a rather low profile with vvvv gamma, mostly advertising it to you as long as it is still in preview. So anyway, nothing to be particularly proud of here. Moving on...


vvvv.org income through licenses and dongles sold

Phew, not as bad as the declining number of downloads would have suggested. Certainly not an upwards trend but still the 4th best result so far. So let's see what this number is composed of:

2011 2012 2013 2014 2015 2016 2017 2018 2019
countries 19 18 17 17 21 19 22 19 17
companies 52 61 69 81 102 90 80 77 63

Mkay, so according to the number of individual commercial users we're basically thrown back to 2012. Quite a bummer but to be expected when you put most of your resources into R&D for the shiny new product that just still isn't there yet to make its own money. We were certainly hoping to keep a few more of you with our advances in VL but we know that before making any new friends, VL needs to grow out of vvvv beta and get a 3d engine...

That was it? Far from! This year we held by far the largest number of workshops for onboarding new users. These included a series of 8 free introductory workshops and 8 full-day workshops on various topics in Berlin. Further, we toured Kiel, Linz, Timișoara and Moscow. Also, we held 10 meetups and 3 patching circles in Berlin, one meetup in Hamburg and one in Moscow. Finally, we even held a dedicated Teaching Patching mini-conference to better understand the needs for vvvv in education.

All these activities will see a continuation in 2020 and culminate in NODE20 in October. Until then, the road to NODE is filled with some precious gemstones:

  • The first official release of vvvv gamma that you can finally own for money, already available for preview
  • Initial release of 3d engine for vvvv gamma, still work-in-progress
  • Polished libraries to support your basic needs
  • More workshops and learning opportunities

Is 2020 finally the year of the future of visual programming or is the world not ready for VL yet? Stay tuned, spread the word and become part of a truly wonderful new numbers blog post next year! You know what to do...

We wish you what!

joreg, Thursday, Jan 23rd 2020 Digg | Tweet | Delicious 0 comments  

Helo evvvveryone,

We're starting into 2020 with a couple of activities, culminating in the recently announced NODE2020 happening in October. So leading up to that, here is what we got for you in the first quarter of this year:

Intro vvvv gamma workshops

Every fourth Tuesday a month we're running a vvvv gamma intro workshop for total beginners. It goes for 2 hours and gives participants an idea of how it feels to work with vvvv gamma. Here you learn the fundamentals that you need to be able to follow further workshops or take the next steps on your own, continuing with online learning resources. Spread the word, send your friends and family!

Available dates:

  • January 28, 6-8pm
  • February 25, 6-8pm
  • March 24, 6-8pm
  • April 28, 6-8pm

The workshop costs 5€ and you can sign up here.


Right after every intro workshop, meaning also every fourth Tuesday a month, starting 8pm, we're running a vvvv meetup. Here we count on you: Have a project, demo or new library to show? Just come with your laptop and present. Low profile, no pressure. Doesn't need to be polished, rough around the edges is very welcome! Or just grab a drink and lean back...

Patching Circles

The patching circle is a vvvv support group. Once a month, every second thursday, we're meeting to help each other out and find collaborators for our projects. So please join us for patching and drinks if you...

  • are stuck in your patches and could use some advice
  • want to help others with your experience
  • just want to click yourself away in a patch-friendly atmosphere

If you feel like coming to a meetup or patching circle, please announce your participation in our getogether events.

All the above are happening at the cozy NODE Institute, Wipperstrase 13 in 12055 Berlin/Germany. If you're running a similar event, be sure to also post an announcement here in the blog to get the attention of your local vvvvriends.

joreg, Thursday, Jan 16th 2020 Digg | Tweet | Delicious 1 comments  
Update: This is now publicly available at: http://visualprogramming.net

Happy new year, evvvveryone! Welcome back and we hope you had some fine holidays. More than one year has passed since the last report. An update is well overdue. This post sums up last year’s (2019) progress on our upcoming 3d engine for vvvv gamma.

Xenko’s codebase is huge and even after one year, we are still in explorer mode. But help is near! As you might have read, Xenko’s lead developer Virgile Bello aka xen2 is now with us in Berlin. While his main focus is maintaining Xenko and building a community around it, he also helps us to achieve our goals faster by answering questions and fixing bugs that we encounter.

As it is still early, for each technology we work on, we try to focus on creating only the basic nodes required to get a working prototype. Because if we have to change something fundamentally, every node has to be adapted. Nevertheless, there are tons of nodes already.

The videos and screenshots in this blog post are mostly early development captures. Things will change and improve over time.

Besides many little things, here are the main topics we worked on:

Scene Graph

The scene graph is the fundamental data structure of the 3d engine. It contains the entities and scenes of your application. Most engines use a tree view to visualize and work with it. In vvvv, we have “Group” nodes to build the parent-child relations of entities.

For convenience, every group and entity got a transformation and name input. The name becomes handy for finding and accessing certain entities later programmatically or just for getting an overview. It also shows up in the tooltip.

Scene Graph Explorer

The scene graph can become large and complex quite quickly. Especially when you are a brave patcher and you use sub-patches to stay organized. Sometimes you want an overview of the whole tree structure and see basic properties (at runtime, of course!). Luckily there was an older project for Xenko that traverses the entity tree and visualizes its components and properties.

We updated it to the latest Xenko version and imported it as a debug helper.


If you look at the options and properties of a material in Xenko it’s quite complex and some features require expert knowledge. To make things quick and easy, we made a few simple nodes to cover the basics.

We’ll also add texture-based versions of them and for more complex setups, you can always design the material in Game Studio and import it.

Runtime Asset Loading

For almost every project you have to import content. Be it images, videos, models or just text files. This sounds trivial at first, but as you come closer to deployment, it gets more tricky to have everything at the right place. Even more so, with the new executable export in vvvv gamma.

Game engines usually solve it like this: Resource files like models, textures, etc. get imported via the editor and compiled to runtime assets. These asset files get placed next to the executable on compilation. This works well for static assets, but for rapid prototyping and changes at runtime, we need something more flexible. So we took the Xenko asset builder and adapted it to work at runtime. This allows for importing and building assets while the application is running.

File Assets

Load single resource files directly from disk, aka FileTexture. Good thing is, this works together with Xenko’s asset database and caches already loaded files. So everything is pooled by default.

Load Project

That’s a nice one, you can create a Xenko project in Game Studio, work on Assets, Scenes, Prefabs, etc and import everything at once with the LoadProject node. It even updates on save!

Modify Imported Entities

Since we work directly with Xenko’s data types, imported entities are in no way different from patched ones. You can access and modify them in the same way:


vvvv is known for treating shaders first class. The Xenko team seemed to have a similar attitude. They created their own shader language called XKSL. It is a superset of HLSL, so you can paste shader code from vvvv into an xksl file.

However, there is much more. They added quite unique features that make writing shaders easy, fast and clean. If that wasn’t enough, you can compose shaders with other shaders at runtime and avoid an explosion of shader permutations.


The well known TextureFX node-set in vvvv beta makes working with textures easy and fun. Of course, we want to have the same experience in vvvv gamma. But, with preview in the tooltip! There you go:

ShaderFX + FieldTrip

Visual shader programming with nodes? Yes, please! The composition feature of XKSL makes this easier than expected. Turns out, the Xenko team was working on something similar which made it relatively easy to build a node-set around it.

To test these nodes, we had the pleasure to have Kyle McLean in our office for some days and worked with him on porting FieldTrip nodes to VL.Xenko.

FieldTrip is a modular shader library Kyle McLean created for vvvv beta. It includes raymarching and general tools to work with scalar fields and vector fields on the GPU.

We ended up with a working prototype, as you can see in this video from the vvvv berlin meetup:

StreamOut Instancer

Since Xenko has no native instancing for their material shaders yet, we tried to use stream out aka transform feedback to transform a mesh multiple times and build one big vertex buffer that works with the Xenko material pipeline. The node works nicely and takes a Mesh, a material, and the instance transformations. You can easily draw a few thousand instances with it. The header image was mostly done with it.


The bigger your project gets, the more important it is to know how well your shaders perform. Thanks to Xenko’s profiler infrastructure we can give every shader a profiler key and see it listed in the GPU page:

Next Up

There are still some topics left in order to make VL.Xenko as convenient as we like it to be.

Multiple Windows

One major feature that vvvv beta does exceptionally well is working with multiple windows. Games are usually focused on one output window. In order to get this to work, we have to find a solid way to instantiate multiple windows in Xenko and render content into them. This requires some coding behind the scenes. We are planning to get this done by early 2020.

One-Click Installation

At the moment one still needs Visual Studio to set up a VL.Xenko project. This should, of course, be just a one-click package installation as we have it with other VL libraries. Initial tests went well and we are confident that this will work out just fine.

Rename to Stride

Because of legal reasons about the trademark, Xenko has to do a re-branding and will be called Stride soon. We'll of course follow along and will rename the library to VL.Stride.

As much as we want everyone to try it, it won’t make much sense to share the library in its current state. The setup process needs developer knowledge and a few main features are still missing. But stay tuned for more on that!

If you want to know more about something specific or have any remarks or requests, don't hesitate to leave a comment below.

That’s it for now, looking forward to NODE20 and more exciting patches in 2020.


tonfilm, Monday, Jan 6th 2020 Digg | Tweet | Delicious 5 comments  

Previously on vvvv: vvvvhat happened in November 2019


still no bigfat vvvv gamma release but we're now really getting close. See what we've just released last month:

This means we're now basically feature complete and are planning for an initial release in Q1.2020! More tweaks and fixes will happen for the export and we'll do some more work on the help browser to make it even more useful. Meanwhile please keep reporting your buggers and help us make this a solid first release.

Documentation-wise there've been three updates: A new Section on IOBoxes in the gray book and two new how to videos:

And the biggest news of all: NODE20 is happening! Just in time so that we'll have 3d-support in vvvv gamma and hopefully finally match most features of vvvv beta. Ideally we'll have at least a first version of VL.Xenko out before, so that some of you can even already prepare workshops with it... Curious about our progress there? Expect a separate blogpost with a wrap-up of latest developments shortly.


A few updates:

woei opensourced two of his contributions:

And there's been some action in the work-in-progress section on the forum:


And some more fresh from the vimeo group:


That was it for December. Anything to add? Please do so in the comments!

joreg, Saturday, Jan 4th 2020 Digg | Tweet | Delicious 0 comments  
This is an updated revision of the blog post we've previously published, incorporating some more user feedback. Many thanks to those who listened and engaged in a discussion with us!

A summary of the main changes in respect to the previous blog post:
1) Indie is now up to 50k€ revenue
2) We removed the idea of a product license, meaning you don't need to license devices that run an executable exported from vvvv!
3) There are now only 2 types of licenses that are needed to run vvvv itself: Developer and Device (See below for details)
4) We simplified monthly payment

Helo everyone,

We recently released a new preview of vvvv gamma, including executable export. This makes it feature-complete for our first official release in early 2020. We're now only ironing out bugs and tweaking the help/onboarding experience a bit further. So what you see now is what you'll get, when you buy a license to use it commercially. Therefore now is the time to inform you about the licensing options we have planned for it. Note: This does not mention any discounts that we're still planning to apply for early adopters.

Trust me, when I tell you that this is the most rewritten blog-post we ever published. Creating a suitable licensing model seems far more complex than creating the software itself.

Continuing the T.R.U.S.T model

Foremost it is important for us to keep our (pattern pending) T.R.U.S.T model, which means:

  • No copy-protection
  • No feature limitations
  • No mandatory registration
  • We trust you to declare your commercial use of vvvv correctly.

That's the world we want to live in and we hope you too! We don't believe in any form of copy-protection or artificial feature limitations that usually only restrict honest users. Others will always find a way around such restrictions and thus not be bothered anyway. We're all grown-ups here. If vvvv helps you make a living, then help us make a living by providing vvvv for you. How simple is that?!

Education must be free

Same as above, this is what we believe in. In the end, everything always comes down to education and equal access to it. We don't want to be responsible for anyone to not have the pleasure of learning vvvv.

There are commercial educational institutions that could make us a lot of money indeed. But also we're smart businessmen and know how to cash in on the free drugs we hand out now, later.

Further, it is in the interest of any professional user of vvvv to quasi support the free educational use as this keeps the flow of new talents steady. WinWinWin.

Gamma over beta

So why not simply keep the existing licensing model? Indeed, to make this clear: The licensing for vvvv beta will not change! As long as you're not interested in vvvv gamma, everything stays exactly the same for you (except you're missing out quite a bit! Just sayin...).

But then, regarding vvvv gamma, there are a couple of reasons to adapt the licensing model:

  • The vvvv beta licensing model is simple to explain, but just does not fit well to different use-cases. We've heard of people not using vvvv for certain smaller tasks because they didn't justify a whole license
  • With its possibility to export executables, vvvv gamma becomes a different type of product. It allows you to distribute and run your projects as self-contained programs without the need to install and run vvvv on every machine. Like this, vvvv becomes closer to more traditional development environments where it makes sense to charge per developer seat rather than per executable that was created with it
  • By still offering the edit-while-running workflow, vvvv gamma at the same time stays the same product and needs to keep existing licensing options
  • Too often we heard the phrase "I told the client to buy the license" as an excuse and even partly as a complaint that it would be our fault that we don't have means (dongle, ...) for the client to understand they need a license. But this was never our intention. We're doing business with you, not your clients!

So bottom line up front: vvvv gamma is more and therefore requires a more defined licensing model.

Types of vvvv gamma licenses

We'll want you to declare your use of vvvv gamma using the following options:

Free Use

  • Non-commercial use
  • Evaluation purposes
  • FOSS development
  • Contribution development
  • Student projects
  • Hobby projects
  • Educational Institutions when teaching with vvvv

Developer License

  • Per developer seat when working on commercial projects
  • Export and sell executables without extra charge
  • To be used by a single developer on 2 devices in parallel during development
  • If more devices are required during development, extra Device Licenses are needed

Device License

  • Development: Needed per device or virtual machine running the development environment vvvv that is not covered by a Developer License
  • Deployment: Needed per device or virtual machine running the development environment vvvv

Pricing per size of wallet

Another thing we wanted to improve over the beta licensing model is the fact that we understand that vvvv is used in quite diverse scenarios regarding the financing that is behind them. To accommodate all of those on an individual basis is not really feasible. But at least we thought we can add an option on either end of the default "professional" user. So depending on who pays for a license, there will be different prices:



Subscriptions are optional and will be available for both yearly and monthly options. If you sign up for a yearly subscription, we thank you for that with a 30% discount from the second year on. Otherwise, subscriptions simply offer the convenience that you don't have to think about the validity of your license all the time.

Of course you can cancel a subscription at any time and if you had a yearly subscription (or a monthly subscription for more than 12 months) you then own the last version of vvvv that was available within your subscription period and you can keep using that version commercially indefinitely. A subscription that was canceled cannot be continued/updated at a later point. This means if you need an update to your license after you cancel the subscription you need to buy a full new license or start a new subscription.


Accommodating the various requirements of all types of users and use-cases is a tricky task. This paired with trying not to completely disregard the pricing politics of "the competition" but also adding our own ideas and still balancing an economically viable solution didn't make it any easier. We still hope that we found a way that can be sustainable for all of us.

We are aware that the above may leave some questions open and we are ready to further refine the fine print and add examples to make it easier for everyone to declare their licenses. Please help us do so by asking your questions in the comments below, so we can understand where we need to get more specific.


If my installation/show is running from an executable, do I need a Device License in addition to my Developer License?

Can I use my Developer license to run vvvv on a device in a museum?
No, the two Device licenses your Developer license covers can only be used during development. Device licenses for deployment need to be acquired separately.

My project (a server and 5 clients) is running at a trade show for one week. I don't want to run them as executables because I need to be able to change things on the fly during the week. I am one developer and it takes me 2 months to develop the project. What licensing applies?
For deployment you'll need 6 monthly device licenses to cover the 6 devices running vvvv for one week. For the 2 month development time you have 2 PCs covered by your developer license. Assuming you're only using exactly the 6 PCs during development that means you'll need 4 additional device licenses for the 2 months of development.

We're two developers working on an installation distributed over 10 machines that will eventually only run an executable. But for development, we have vvvv running on our laptops and all 10 machines for convenient debugging.
You need two developer licenses, which cover 4 running instances of vvvv. You therefore need 6 additional device licenses for the time of development.

My commercial installation is running with a Device License. Does the maintainer of the installation need a Developer License?
Yes, to keep things unambiguous, every developer needs to be covered by a development license when working on or maintaining a commercial vvvv project.

Can a single Developer License be shared by multiple developers?
Yes, but only as long as they are not working at the same time. Even though a single developer license covers two Device licenses it only covers one developer at a time!

I am a freelancer with less than 50k € gross annual revenue. Do I still have to buy a Professional license?
The key to your decision here is whether you consider yourself a professional freelancer. If you are working mostly for professional companies who clearly have to buy professional licenses, then you also buy a professional license or make sure the company covers you. You don't want to be just a cheaper option for those companies by buying an indy license and then working professionally for them.

Aren't software subscriptions a bad thing?
Not if done right, meaning that you can keep the last version once you stop paying if paid for some time (see above). And remember: they are optional.

joreg, Thursday, Dec 19th 2019 Digg | Tweet | Delicious 7 comments  

anonymous user login


~10h ago

schlonzo: also a nice way to hide jitter

~10h ago

schlonzo: I really dig the alpha fade on texture previews in 2021.4

~17d ago

yar: And now it's opertaional. It's just a concept, bugs expected

~17d ago

yar: sorry, one moment it's broken

~17d ago

yar: concept of genrative telegram bot: t.me/arktkbot