VL for vvvv users

Over the years people have been using vvvv to realize more and more complex projects, often maxing out its capabilities. New programming concepts and techniques had to be introduced to keep it up to date with today’s user requirements.

At some point we came to the conclusion that the quantity and scope of such changes would create a lot of overhead in development. Chances were that implementing these changes would compromise performance and stability and disappoint users because they would have to adjust their workflows to new paradigms. So instead we decided to start from scratch, and build vl as a new, completely independent visual language. This gave us much more freedom and flexibility in creating vl in its own pace, rather than having to build new features into the already proven vvvv.

Creating vl, our mission has always been to incorporate as much of the good stuff from vvvv as possible and add new features to solve problems that people get stuck on when using vvvv. Ultimately we want all vvvv users to feel at home in vl while also introducing new audiences to and convincing skeptics of the wonders of visual programming.

With the integration of vl into vvvv, users are able to keep their patching habbits while exploring the features of vl bit by bit, as needed. When you hit the limits using vvvv, we now recommend that you check to see if vl might be able to resolve these issues. The following is a non-exhaustive list of common issues that are/will be solved by vl:

When to use vl

Your huge patch has become quite a mess over time and you find it hard to read and maintain it

vvvv does not have much of an idea about the structure of a patch. The only way to structure things are subpatches but even those are only useful for us humans, vvvv actually ignores them and sees just one big patch. The fact that vvvv doesn’t offer better ways to organize your patches makes it hard to use vvvv to build big, well structured programs. vl has many features built-in to tackle exaclty that problem: Documents can explicitly reference each other, you can create custom datatypes and operations (think object-oriented programming). All these help you improve readability and maintainability of your programs.

Parts of your patch need to only run once to initialize or need to be initialized only at a later point during runtime

To initialize parts of your patch once on startup, in vvvv you’d send a bang to certain parts to evaluate them once. Even when not evaluated though, those parts are part of the vvvv program and waste at least some of your precious CPU cycles and memory. vl allows you to more cleary run parts only once (using constructors in datatype patches) and more clearly run whole parts of a patch only on demand.

You want to offload parts of your patch to separate threads

Large patches can become computationally expensive and vvvv does not allow you to use the full power of your PC by being inherently single-threaded. Using vl you can define regions of your program that you want to run asynchronously to the main patch thus using multiple CPUs in parallel.

You need to react asynchronously to an input device

External input devices often send their data at a higher or lower rate than the framerate you want your patch to run at. vvvv has only one mainloop and any data coming in first has to be matched to that before being able to handle it. With timing critical-devices this can cause problems where your only chance so far was to write a c# plugin. In vl all external input comes via "observables" that are executed asynchronously and allow you to deal with incoming data at their rate before synching it to the mainloop.

You need to use an external .net library

Using any .NET library is already possible in vvvv by writing a c# plugin. This requires you to change to text-programming and follow the vvvv plugin-interface which introduces a bit of overhead both in development-time and computation. Using vl, chances are that you can access the same .NET library directly, without any such overhead and still keep programming visually all the way.

Main differences between vvvv and vl

At first glance VL looks rather familiar to vvvv users: There are gray nodes, links and IOBoxes. Patching works similar in both. The most obvious differences a regular vvvv user will stumble upon are:

  • LOOPS: there is no automatic spreading. instead, vl only has explicit loops (for now)

  • TYPES: vl is more picky about types which also leads to more flexibility

  • PADS: instead of FrameDelay nodes in vl you can use named pads to denote the handing of state from one frame to the next

  • NODEBROWSER: vl has different kinds of nodes which makes it a bit different to navigate the nodebrowser

These are only the most striking differences that former vvvv users will detect, vl has many more features to be disovered and applied as needed. More details about these and some more of the things that will look and sound familiar to vvvv users can be found in the following chapters.

results matching ""

    No results matching ""