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.

## NODE 2020

Who NODE 2020
When Fri, Oct 2nd 2020 - 13:36 until Thu, Oct 8th 2020
Where Mousonturm + other Venues, Frankfurt, Germany

## NODE 2020

### 2 - 8 October 2020 in Frankfurt.

#### Save that date, prepare your patches and start your travel arrangements.

Dear patchers.

2019 comes to an end and we are glad to be able to announce the next festival edition for 2020 just before this year ends. It is finally official. NODE Forum for Digital Arts will be happening in October 2020 in Frankfurt. We got the locations and the date. So please save that date and equip yourself with patches, projects, questions, presentations.

Within the next month, we will be developing the professional program together with you. As usual, we will focus on vvvv, but also invite other communities to plugin to the program to foster exchange and skills and support social and technical integrations from community to community and software to software. As soon as we have some open doors you will be informed..

Lets bring it to life again and create a festival from which we as a community as well as new users and curious minds can expect the finest and most relevant workshops and masterclasses to learn about creative patching techniques from experts and new talents from the international digital art and design scene.

Together with Mousonturm and other international partners, we are also developing the discursive and cultural program for you. We will soon release our next leitmotif that shall be reflected within the community program, exhibition, lectures, talks and labs – so stay tuned for the open call to contribute with your ideas and projects!

A word on whats beendiscussed at last link. There has been the idea to run a community summit separetly from the node festival. This is indeed something that has been discussed intensly with many people and relevant partners. For now we decided to keep things together and let NODE Forum for Digital Arts be our community gathering as it always was. With all the topics and discussion we need.

What should I do next?

You may starting to collect topics and workshops here on vvvv.org and contact us for urgent requests.
You may start making travel arrangements as the date is fixed. It makes sense to think of Thursday 1st or Friday 2nd as the arrival date and to plan your trip back home on October 9th earliest so we can have a final party on the 8th. We will be releasing the tickets soon.

In the meantime watch that video from the previous edition and get into the mood.

looking forward to see you all again.

david, Tuesday, Dec 31st 2019

## vvvv gamma licensing /2

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

• 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

• 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

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.

### Conclusion

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.

### FAQ

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

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

## VL: Getting you started

Alles neu!

With vvvv beta we clearly missed quite some opportunities by not providing a clear getting started path for newcomers. Only 15(!) years after launch we added a Getting Started page. Around the same time we added some built-in tutorials you'd see on startup plus some links to documentation, forum and chat. But those would be gone forever once you decided to hide the welcome-patch on startup.

So this time around, we wanna try something different...

The HelpBrowser: In your face as you open vvvv gamma for the first time.

The screenshot shows the current status of the helpbrowser as it comes with the latest previews of vvvv gamma 2019.2. It will open by default for every new user and offer a series of tutorials and example patches and encourage to explore the documentation. Obviously we now need to provide many more tutorials, examples and add more documentation, but this provides a structure to fill.

For now, the most useful pages of the documentation are HowTo and Shortcuts which are both searchable. And note that the content of the HowTo tab is dynamically sourced from all packages you have installed! Most other links in the browser go to external sources (youtube, graybook) but we're planning to someday include more content in the browser directly.

### Connect

The second tab is still rather dry for now but at least is supposed to give new users an overview of the most important entrypoints that are available to our univvvverse. Later we'll want to make this tab a bit more lively by e.g. showing some of the latest live content of those entrypoints. Think latest forum topics, news, screenshots of the day...

Connect and never miss a thing
joreg, Monday, Dec 16th 2019

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

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

# Shoutbox

~15h ago

catweasel: @evvvvil Awesome!

~17h ago

~1d ago

evvvvil: "pencilvester's orthodoodle" orthographic raymarching gets all the birds chirpsing. https://www.shadertoy.com/view/wlyfWK

~2d ago

dottore: Kairos webinar! don't miss it ;) https://bit.ly/3quag3D

~4d ago

christosk: @schlonzo Thank you.

~4d ago

schlonzo: use different filenames :P counter is your friend

~4d ago

christosk: How do I record a sequence of images without having them overwriting one another? I

~5d ago

~9d ago