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

# Blog

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.

## Patching Circle - a vvvv support group

When Thu, Dec 12th 2019 - 20:00 until Thu, Dec 12th 2019 - 23:00
Where NODE Institute, Wipperstraße 13, Berlin, Germany

Once a month, every second thursday, we're hosting a "patching circle". Please join us for drinks and patches if you...

• ...are stuck somewhere with a project and could use some advice
• ...are just getting started and want to know what its all about
• ...just want to click yourself away in a patch-friendly atmosphere

vvvv devs and other members of the community will be there to help and share their experience.
Wipperstraße 13 is our new space - for asking questions, collaborating and keeping yourself on your personal level of superhuman programming skills!

remony, Wednesday, Dec 11th 2019

## vvvv gamma 2019.2 - preview

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.

### What's new compared to the vvvv beta series

#### General

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

#### Patching

• 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
• The color theme is now customizable and defaults to dark

#### Language

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)
• No more binsizes needed!1!!
• Loops to iterate within one frame
• Recursive patches
• Generics
• Delegates
• Reactive programming
• 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.

### Pricing

We've previously announced the upcoming pricing model for vvvv gamma, which we're currently refining and we'll update you on changes to it soon.

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 0026

### Changelog:

Upcoming

• Fixed crash in UI when trying to retrieve the default value of an imported generic typehttps://discourse.vvvv.org/t/2019-2-0026-cannot-create-iobox-tuple-t-t/18061
• Fixed apply node lifting being applied to nodes which already had an apply pin (like Console.WriteLine)
• Fixed crash when referencing an assembly like Bridge which tries to replace the whole mscorlibhttps://discourse.vvvv.org/t/gamma-x-2-nuget-import-error/18038
• Fixed regression that the "valid pins are ..." warning wouldn't show up when implementing an interface
• Type annotations on pads which point to a field will now truly be ignored and also cleared - was reported in chat by björn
• The version of the currently used package will now be written to disk. Allows to introduce converters for libraries at a later stage.

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

##### Features
• 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,
devvvvs.

joreg, Tuesday, Dec 10th 2019

## fullday gamma workshop (visual-programmi...

Who tonfilm, elias, david
When Fri, Dec 13th 2019 - 11:00 until Fri, Dec 13th 2019 - 18:00
Where NODE Institute, Wipperstr. 13, Berlin, Germany

For the spontanous who are in Berlin or can make it to Berlin..
This one might help to understand the deeper fundamentals of vvvv gamma..

https://nodeforum.org/announcements/fullday-workshop-visual-programming-for-coders/

You will learn how to:

• Write VL nodes in C#
• Extend your application with third-party libraries from the internet while it is running
• Convert textual code into visual code
• Use generics

Requirements:

• Bring a Windows laptop
• Bring a 3 button mouse
• No prior knowledge of vvvv needed
• You should be familiar with words like class, method, interface and generics and have a basic understanding of programming.
• Please come with Visual Studio 2019 installed as this takes a while
david, Tuesday, Dec 10th 2019

## vvvv_50beta39

Patcher People!

Once again later than we hoped for, but here it is: vvvv beta 39 in all its glory! Many thanks go to everyone who reported issues with the release-candidates! Here are the highlights:

What's new in vvvv beta 39

### General

• Finally we ship an installer! Just a few clicks and you should have vvvv beta running. Note how this also optionally installs the addonpack
• NOTE: By default it installs to C:\vvvv, because it won't work in C:\Program Files...
• The default patch-window size is increased
• By default new patches now save to %User%\Documents\vvvv\beta\Sketches. Like this you can quickly find your recently created patches via a new main menu entry: Recent Patches
• Show Installed Packs: opens explorer pointing to the \packs directory

### Features

• Control IOBoxes from any webbrowser (desktop of mobile) using RCP. See the helppatch of Rabbit (RCP) for details.
• Easy to use WebSocket (Network Client) node
• New fancy shader nodes: PBR (DX11.Effects), PBRInstanced (DX11.Effects), PBRTextured (DX11.Effects), PBRTexturedInstanced (DX11.Effects)

### New in VL

If you're also using VL already, good for you, because here you'll find even more goodies you will benefit from:

Besides those, it is important to understand that with VL you also have access to numerous more libraries that have been released recently. A lot of new packs these days come as nugets. For an overview, see VL packs on nuget.org and you can use them all in vvvv beta, via VL...

### Learn VL

This is a good moment to get started with VL. Note that everything you learn and do with VL can later be applied to the upcoming vvvv gamma since VL is what both vvvv beta and gamma share. If you haven't already, check out these Tutorials and HowTos!

Have a good patch,
Yours, vvvv

PS: People who liked this release also liked The vvvv Show-Off-Reel

joreg, Saturday, Dec 7th 2019

## vvvvhat happened in November 2019

Previously on vvvv: vvvvhat happened in October 2019

Finally,

as promised for some years now, we have shipped Executable Export with vvvv gamma 2019.2. Try it, it is just a click and you get a standalone program out of your patch, which you can run on any Windows 10 PC.

Wanna know how we do it? Read all about it in the article with the poetic title: New Roslyn based backend. And while we're techical, if you're so inclined you may also be interested in our talk at DotNextConf in which we presented vvvv to an audience of .NET developers who had never heard of us before.

To give them an easy way to explore vvvv we also created this preliminary new website with a focus on vvvv gamma: visualprogramming.net

But just before that we've also released the latest and greatest of the beta series: vvvv beta 39 which now comes with goodies like a WebSocket client node and PBR (physically based rendering) shaders and of course an up-to-date version of VL.

Aaaand if you're interested in our progress with Xenko (3d rendering for vvvv gamma), make sure to watch the live-stream of our last berlin meetup where tonfilm and everyoneishappy demonstrate the status of VL.Xenko ShaderFX.

### Upcoming dates

We're closing 2019 with the following events:

Two new things:

### Gallery

The vvvv Show-Off-Reel: A staff pick of projects realized by you

In addition there've been a few new projects reported:

joreg, Thursday, Dec 5th 2019

When Thu, Dec 5th 2019 - 20:00 until Fri, Dec 6th 2019 - 03:00
Where arkaoda, Karl-Marx Platz 16, Berlin, Germany

Europalia X arkaoda pres:

Alexander Arpeggio and Maria Balabas (live)
Bogdan Orbita (dj)

excerpt from fb event:

Born and raised in Bucharest, Romania and now residing in Berlin, Borusiade aka Miruna Boruzescu started dj-ing in 2002 as one of the only female DJs in the city's emerging alternative clubbing scene.
Influenced by a classical musical education and fascinated by raw electronic sounds Borusiade combined
these elements in the construction of her DJ sets and starting 2005 also in her music production.
After experimenting with different projects, Borusiade slowly crystallised a sound of her own, often dark, with poignant bass lines, obsessive themes and by all means melodic.
2015 she joined the label Cómeme and started the series "The Dreamcatcher" on Radio Cómeme.
Her DJ sets combine bold and obscure sounds and genres fluctuating mostly in the field of Dark Disco, Industrial and Tropical Weirdness, some House with an Acid touch.
The sound is gloomy and powerful, with beats that touch one’s deepest senses on the dance floor.
Borusiade’s live music will be accompanied by real time videos created by visual worker cote.ggml

ggml, Thursday, Dec 5th 2019

## VL: Exporting an Application

With the release of vvvv gamma 2019.2 preview it's now finally possible to create standalone applications out of any vvvv patch.

The steps to create an application are as simple as this:

2. Open the patch you wanna have as an executable
3. Open the application exporter by pressing F9
4. Press export and voila you have an executable which runs on any Windows 10 machine

To learn how to deal with referenced assets, read Exporting Applications in the gray book.

So please try it out with your projects and report any findings in the forums or the chat.

Elias, Wednesday, Dec 4th 2019

## VL: New Roslyn based backend

With the release of vvvv gamma 2019.2 we introduced a new backend compiling patches in real time using Roslyn. This blog post is primarily intended for a technical audience, if you're solely interested what new features it brings to the table have a look at the before mentioned blog post.

### Background

In the past VL (the language behind vvvv gamma) compiled in-memory directly to CIL using CCI. With the recent changes in the .NET ecosystem and CCI being superseded by Roslyn it became more and more apparent that at some point we'd also have to make the switch to keep up with the latest developments happening at Microsoft.

What finally pushed us into making the switch was two-folded:

1. An executable written by CCI wouldn't work at all the moment it referenced a library based on .NET standard. This was a major set back as nearly all future libraries would be targeting .NET standard and days of trying to find a workaround brought us nowhere. Making modifications to the already abandoned project CCI seemed like a very bad idea.
2. For a long time, we didn't know how to directly translate VL's adaptive nodes feature to CIL (or C# for that matter). For those who're not familiar with adaptive nodes, it allows one to build functions solely on their intent. For example, a LERP function can be expressed with a PLUS a MINUS a ONE and a SCALE node without having to specify what data will be provided in the end. The exact implementations will be looked up by the compiler when applying the function let's say on a float or a vector. This lookup is done from an entry point (like an executable) and while traversing from such an entry point all adaptive nodes will be replaced with their respective implementation. The emitted CIL code will then end up with two LERP functions, one for float and one for vector. This approach was working fine but it had a major drawback as it prevented us from pre-compiling our libraries and also it prevented any user to build a proper .NET library with VL.

Until this year in march @sebl came to the rescue by randomly dropping us a link in the chat pointing to a neat little "trick" which suddenly made it possible to translate our adaptive nodes feature directly.

After initial tests in March and April and having the patched tooltip feature still pending for the final release, we decided to let myself jump into the rabbit hole which I've finally crawled out of after more than half a year ;)

### The neat little "trick"

Let's go back to the example of the LERP node and let's further try to write it down in C#:

T LERP<T>(T a, T b, float s) => a * (1 - s) + b * s;

Looks neat but sadly won't work, C# will tell us that the operators +, - and * and the constant 1 are not available on T.
The trick to make it work is to outsource those operators to a so-called "witness" which in turn will provide the implementation when the LERP gets instantiated with say a vector. So let's see how the actual needed C# code is gonna look like:

T LERP<TWitness, T>(T a, T b, float s) where TWitness : struct, IPlus<T>, IScale<T>
{
var w = default(TWitness);
return w.Add(w.Scale(a, 1 - s), w.Scale(b, s));
}

with

interface IPlus<T> { T Add(T a, T b); }
interface IScale<T> { T Scale(T a, float s); }

and when applying it with say float we need to define a witness implementing the needed interfaces

struct MyWitness : IPlus<float>, IScale<float>
{
public float Add(float a, float b) => a + b;
public float Scale(float a, float s) => a * s;
}

which finally allows us to call

LERP<MyWitness, float>(5f, 10f, 0.5f)`

Fancy, no? The beauty is that when the JIT compiler hits such a code path it will be smart enough to inline all calls so in the end for the CPU the code to execute is the same as the initial naive attempt. But don't worry, this is all happening behind the scenes. In the patching world, it is as simple as it was before to patch generic numeric algorithms.

### The implications

So now that we're able to translate patches directly to C# what are the implications apart from being able to export an application?

#### Easier to maintain

Well for us as developers it will be much easier to bring in new language features, because the code we generate will be be checked by the C# compiler and more important, we can fully debug the generated code with Visual Studio. That by the way is not only restricted to us, anyone can now attach a debugger to vvvv (or the exported app) and debug the patches.

The generated C# code will make full use of .NET generics. So when building a generic patch the generated class will also be generic in the pure .NET world. As an example let's consider the Changed node, while in the CCI based backend a Changed class was emitted for each instantiation (Changed_Float, Changed_Vector, etc.), the new Roslyn based backend will only emit one Changed<T> class and it is left to the JIT compiler of .NET to create the different versions of the needed target code. This should lead to much less code the CPU needs to execute as the JIT compiler is much smarter on when to generate new code and when not.

But what's even more important is the fact that it opens up the world of compiling VL patches as pure .NET libraries. So we can finally pre-compile our libraries (like VL.CoreLib, VL.Skia, etc.) which in turn reduces the general overhead and leads to much quicker loading times and less memory usage. As an example loading the Elementa "All At Once" help patch takes ~15 seconds the first time (compared to ~33 seconds in the old backend) and thanks to caching to disk only ~8 seconds when opening at a later time.

#### Instantiate patches at runtime

Apart from better loading times, it also gives the patcher the ability to instantiate any VL patch during runtime. In the previous backend, one had to use a hack and put all possible instantiations into a non-executing if-region. This is not necessary anymore as all the patches get compiled. However, I should mention here that this is only true for non-generic patches. Generic patches usually require a witness which is not so straight forward to provide.

### The drawbacks

Sadly the new backend also required some major internal changes in the frontend so it wasn't possible to guarantee existing patches would work the same way as they did before. Here follows a list of potential breaking changes:

• The type unification algorithm had some flaws and therefore needed modifications. In general, it is "smarter" than before, so when starting a patch from scratch fewer annotations should be necessary. But for existing patches, it sometimes finds a different solution than the previous algorithm leading to red links on the application side of a patch. In those cases, one needs to set a type annotation in the patch definition.
• When pause on error is enabled the old backend was able to show computed values up to the point where a node was crashing, this feature is sadly not available anymore due to local variable scoping rules of C#. Whether we'll bring this feature back or not is not yet decided.
• Naming rules are more strict, so it's not allowed anymore to have for example an "Update" and and "Update (Internal)" operation as both are considered to have the same name. In general instance-operation overloading is not possible.
• Static operation overloading - having operations with the same name but different pins - is still allowed as long as the types of the pins differ. So different pin names alone are not ok.
• When defining a generic interface all type parameters of its operations get assigned to the interface itself. This is necessary due to how internals of the emitted C# code work.
• The cyclic graph detection wasn't correct. This can also lead to red links now but should be considered a good breaking change as it makes the patcher aware of undefined execution order.
• Patches, where the execution order wasn't defined, might behave differently now.
Elias, Wednesday, Dec 4th 2019

## vvvv at DotNextConf Moscow - Video

привет,

as mentioned previously, elias and me were at DotNextConf in early November where we talked vvvv to a whole different audience than you are. We titled our presentation "vvvv - Visualprogramming for .NET" hoping to get the benefits of what you all take for granted (that is "live, visual programming") across to people who are still stuck with an EDIT/COMPILE/RUN mode of development. And to hear if they could see some application of it in their fields.

The general feedback can be summed up as "Huh, this looks interesting, but I don't know what to do with it". Clearly our demonstrated use-cases didn't resonate with them. A few people came up to us after the talk and were interested in details about the state hot-reload and one guy told us he is working in aero-space engineering and he believes they could very well use it: When working together with physicists they often need to exchange code with them but they always deliver very bad code, he claimed. He saw vvvv as a perfect fit of a tool they could prepare some high-level nodes in, so that the physicists have a tool to experiment with, where they cannot make too many mistakes... Interesting take and in a sense exactly what we were hoping for. So let's see where this goes...

Now grab a drink and some snacks, this goes for 50 minutes:Watch on Youtube

joreg, Monday, Dec 2nd 2019

## visualprogramming.net

Meanwhile...

...since we're terribly behind schedule regarding the release of a new website for vvvv.org (and we know that it will still take a while), we've created a preliminary site at:

This is mostly so that we can provide people who are new to the world of vvvv with a simpler entry point to our universe. You'll see that the site focuses mostly on vvvv gamma, which makes most sense for new people to explore. Obviously the existing vvvv.org remains our main portal to share news and updates with everyone. We consider visualprogramming.net a temporary landing page for vvvv gamma.

### Nevvvvsletter

If you're old enough to remember, there is this thing called electronic mail (short: e-mail). In a classic retro-move we've also recently started an e-mail newsletter which you can sign up to from that page. Scroll to the bottom and find it in the left corner. Signing up will give you peace of mind to not miss any happenings around vvvv. Typically one mail per month.

joreg, Thursday, Nov 28th 2019

# Shoutbox

~1d ago

ravazquez: Just your regular hungarian folk dance shellsort: https://youtu.be/CmPA7zE8mx0

~2d ago

joreg: Reminder: This thursday in #berlin: free introductory workshop to the all new #vvvv gamma: https://nodeforum.org/announcements/series-of-free-2h-introduction-workshop-to-vvvv-gamma/ #visualprogramming

~4d ago

evvvvil: My refracted brutalism shader... Sucking sweet refracted milk off the tits of schlick fresneled reflections. https://www.shadertoy.com/view/wt33RN

~5d ago

io: @sinao build the cube in a 3d editor soft such as Blender and do the UV mapping there

~6d ago

sinao: one side

~6d ago

sinao: How to apply texture only on one of a cube?

~6d ago

tonfilm: Just updated the CraftLie rendering pack to latest: craftlie-dx11-drawing-for-vl

~10d ago

~10d ago

microdee: 2 seconds later: I asked before googling, but why do you need OS support for texture compression?