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

Blog

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

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

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

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
  • Patch your own pingroups
  • 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)
  • 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.

Pricing

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.

Download

Here you go: vvvv gamma 2019.2 preview 0169

Changelog:

Upcoming

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

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, Thursday, Jan 9th 2020 Digg | Tweet | Delicious 1 comments  

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.

Materials

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:

Shaders

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.

TextureFX

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.

Profiler

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.

yours,
devvvvs

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

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 Digg | Tweet | Delicious 3 comments  

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:

  1. Download and install vvvv gamma 2019.2 preview
  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 Digg | Tweet | Delicious 2 comments  

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.

Faster loading times

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 Digg | Tweet | Delicious 1 comments  

привет,

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 Digg | Tweet | Delicious 3 comments  

Just in time!

Only a whopping 6 years and one and an half months after its first mention during Keynode 13 and to the day exactly 5 years after the release of the The Humble Quad Bundle, you can finally hold it in your own hands. Not exactly as the full release we had planned but as a preview:

Her majesty... at your service.

To our own surpise we couldn't finish all the things we had planned to release today. Most notably the "windows executable export" didn't make it. We know this is a bummer, but we want to get this right and it just needs some more time.

Apart from that we figured there is no more need at this point, to keep it to ourselves. It is definitely good enough for a preview, definitely good enough to gather some feedback to incorporate into the final 1.0 release for which we take some more time to finish our plans. So let's have a look at what we got:

What's new compared to the vvvv beta series

General

  • Trivial installation via an installer
  • The overall performance is much improved
  • All your work is automatically backuped
  • A help browser: press F1! (and wait for it...)
  • 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
  • close to .NET use msdn, stackoverflow help

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
  • Patch your own pingroups
  • 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)
  • Composed Datatypes (Spread of Spread,..)
  • No more binsizes needed!1!!
  • Loops to iterate within one frame
  • 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,...

Forum

To accommodate for the fact that from now on we essentially have 2 products, we added two main categories to the forum:

Living together in harmony: beta and gamma

The existing question, feature, bug, general sections were moved into vvvv beta, and the vvvv gamma section got its own question, feature, bug and general sub-sections. Note that by default the search is constrained to the category you're currently viewing. When you're using vl in beta, still feel free to ask questions in the beta forum. We'll handle that.

Tutorials

Head over to this forum section to watch some video tutorials:https://discourse.vvvv.org/c/tutorials

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.

Download

Here you go: vvvv gamma 2019.1 preview 975

Changelog:

975 26 11 19

  • works with VL.Audio
  • Fixed race condition between state disposal and OnNext calls in reactive ForEach regions. Was responsible for an access violation in OpenCV tooltips.

959 19 11 19

  • equals version included with beta39
  • can now create a node while linking by simply starting to type (double-click not required anymore)
  • fixed SVGWriter
  • fixes on bumpy Damper
  • removed a few unnecessary Damper versions
  • fixed time step calculation of Damper (Fast)
  • Dampers can now be used in loops
  • fixed image tooltip
  • fix on tooltip layout
  • some color operation improvements

930 02 11 19

  • fixed annoyance with nodes being selected instead of dragged
  • fixed problem with red nodes not updating after installing VL. nugets
  • fixed time step calculation of Damper (Fast)

923: 31 10 19

  • added ToVector2/3/4 (Float32)
  • fixed Tokenizer (Frame)
  • fixed register services method called too early
  • fixed regression that timings wouldn't show up on regions
  • fixed timings not working on Cache region
  • fixed serializer not dealing with fields of type object correctly
  • fixed serializer crashing with a stack overflow when data like vectors or colors stored in an object field were re-interpreted as arrays
  • fixed IL emitter not picking up type dependencies on fields if the type was a generic type instance (https://discourse.vvvv.org/t/weird-reference-documents-behavior/17949)
  • added Random implementation for RGBA
  • fixed hue calculation and minor improvements in color space conversions
  • added String <-> Array<Char> conversions
  • shutdown dialog now lists unsaved documents
  • installer adds windows defender exceptions

827: 09 10 19

  • setup.exe is now signed and shouldn't trigger "windows protected your PC popup anymore"
  • added Quad>Windows>Key/MouseDisplay
  • fixed GrayScale Skia ColorFilter
  • added Damper/Oscillator 2D, 3D
  • Packages are now in AppData\Local\vvvv\nugets

703: 16 09 19

  • tooltip performance improved
  • ImageReader now returns correct format of images
  • added FromBytes (SKImage)
  • added Resize (SKImage)
  • LinearSpread now has Phase input
  • added midi ProgramChange node

667: 03 09 19

  • added IsEven/IsOdd nodes
  • added Morph node
  • added MultiFlipFlop node
  • added ConnectAll node
  • added CounterFlop
  • added Random (Centered)
  • added Sort (FormerIndex)
  • added OrderBy (FormerIndex)
  • added IndexOf (KeySelector)
  • added Search
  • added Search (KeySelector)
  • added Resample nodes (Point, Linear, Repeat, Hermite, BSpline)
  • Switch node can now have more than 2 inputs
  • Filter node now has TweenerMode exposed
  • Nodebrowser now also looks for tags in nugets
  • FromImage (Skia) now has options for the case of R16->R8
  • FromImage (Skia) now handles 24->32bit conversions
  • ADSRSettings has optional inputs for Attack, Decay and Release curve settings
  • ADSR has an input to set a new clock at any moment
  • fixed AddRange (Array) of SpreadBuilder
  • updated VL.OpenCV to 0.2.129-alpha

618: 22 08 19

  • SVG/PDFWriter now deal with background correctly
  • improved some warnings
  • increased max tooltip height

615: 21 08 19

  • more tweaks for tooltips
  • Ctrl+F now also considers nodes category
  • updated to VL.OpenCV 0.2.122

573: 08 08 19

  • pin tooltips now show their infos again when available
  • copying messages from tooltips is now via ctrl+shift+c
  • added simpler Mouse and Keyboard (Skia.IO) nodes
  • skia primitives (rect, circle,...) now come in two versions, instead of as overloads
  • updated to VL.OpenCV 0.2.121

552: 01 08 19

  • reworked tooltips
  • new settings: MouseMiddleButtonOpens to activate middleclick to open patches of nodes
  • addded node: FromImage (MutableArray)
  • added skia ColorFilter nodes: Transform, Brightness, Contrast, Grayscale, LUT

411: 12 06 19

  • Value to bytes nodes now have defaults
  • Fixed somehow newly introduced crash in patches making use of serialization (like Tilda) or reflection API (like the runtime-model-editor demos)
  • Fixed accumulators on loops being auto-disposed causing object disposed exceptions in more complex patches (ike Tilda)
  • Fixed Sampler (Reactive) getting stuck in an endless loop if upstream observable crashed (also seen in Tilda)

406: 10 06 19

  • Fixed crash when creating IOBoxes in regions while linking
  • Fixed pin highlights when linking via region border point
  • Fixed application restart with F8/F5
  • Skia gradient nodes rework

398: 05 06 19

  • fixed couple of regressions in compiler introduced between 369 and 380
  • fixed splash screen flicker
  • fixed a null exception on startup

380: 01 06 19

  • fix for Tokenizer (Frame/Postfix) with empty separators

369: 27 05 19

  • Skia PerfMeter (F2) now measures full paint time
  • fixed "Countdown" output of Trigger node
  • fixes in compiler
  • performance improvements in compiler
  • added pixel format R32G32F to imaging
  • fixed a freeze in Tokenizer
  • added Tab, CR, LF, CRLF nodes
  • added serializer for Range
  • theme and interaction improvements
  • added Skia checkerboard style that can be used as a paint
  • fixed removing .vl doc references

344: 14 05 19

  • PerfMeter in Skia renderer (F2) now shows UpdateTime and RenderTime
  • added checkerboard style that can be used as a paint for any layer
  • improved scrolling behaviour for sliders
  • CoreLib improvements
  • sped up RepellingCircles demo patch
  • several compiler fixes
  • compiler performance improvements

318: 09 05 19

  • frames now let you choose colors from a palette instead of the color chooser
  • frames now move their content along as you drag on their titlebar
  • frames now only move elements that are fully contained
  • frame is now included in the "surround with" context menu
  • press SPACE to force-include frames in selections
  • in inspektor changing precision for floateditor now also sets precision for min, max and stepsize.
  • can now grab border control points on regions properly without interfering with region resize
  • default culture setting is now invariant

303: 08 05 19

  • fixed missing dependency for VL.OpenCV

301: 07 05 19

  • windows timer is set to 1ms on start
  • mainloop uses less performance and doesn't block windows messages
  • Skia Renderer has PerfMeter build in, toggle with F2 when selected
  • fixed dpi problem with text in SymbolFinder
  • ctrl+T/ctrl+shift+T to bake/clear type annotations on datahubs
  • fixed "invalid cast in typeunification" error

287: 06 05 19

  • shortcuts now work with all tabs closed
  • Renamed action "Assign->Pop" to "Assign->Clear assignment" to make it easier to understand what the action does
  • Firmata: Tokenizer was stuck in an endless loop
  • fixed null exception in ResizeSelectedMouseHandler
  • Typewriter: Shift+PageUp/PageDown - select to the beginning/end of the document, cursor stays at the same column.
  • OverlayEditor now has minimumsize (again)
  • ImageEncoder doesn't have the bmp option anymore as skiasharp can't encode into bmp

273: 02 05 19

  • fixed another problem with editors/tooltips and high dpi settings
  • fixed "ReguarExpression" typo
  • AllAtOnceEditor for vectors now sticks to value of first component
  • fixed problem with enum-editors on pins getting stuck
  • no more duplicate "Horizontal" entry in IOBox inspektor
  • inspektor now also shows elementtype properties for Spread<Vector>
  • serialization for custom types doesn't throw errors for inspektor/defaults
  • upstream dis/connected iobox no longer looses its settings
  • added GroupBy (Length) and GroupBy (Count) nodes to split a spread into spread-of-spreads
  • added Clean node: removes slices with empty strings
  • added RepellingCircles skia demo

252: 27 04 19

  • fixed dpi handling for fonts in editors
  • can now set ApartmentState of BusyWaitTimer to make UI threads
  • mainloop now has high precision
  • added PerfMeter to VL.Skia
  • editing comment/string now keeps size of editor
  • comments now have correct initial size
  • StringEditor on pin now has wider fixed width
  • fixed problem with paddings differing between single and multiline textbox
  • fixed setting bool pin value via dragging
  • fixed interaction in signature view of patch explorer
  • fixed deadlock when implementing interfaces

230: 24 04 19

  • fix for regions inside operation definitions disappearing
  • fix for patches with more than 10 operations showing later operations as black
  • quad icon now works for all themes
  • previous/next icons now colored correctly in all themes
  • string editors/comments now have a configurable "Max Visible Characters" to prevent low performance with too long lines

222: 18 04 19

  • VL.Skia Camera 2d is not experimental anymore
  • fixed pin interaction in signature view
  • fixed an edge case when then node browser wouldn't show up
  • fixed IOBox rendering freezes
  • added many tags to VL.CoreLib to find nodes faster
  • VL.Skia is referenced by default for new documents
  • toggle toggles on every mouse click
  • IOBox values are not applied while typing anymore

200: 15 04 19

  • inputs/outputs of definitions/regions and groups can be moved (again)
  • fixed problem with documents not opening anymore
  • fixed file path serialization of dependencies when the path couldn't be made relative to the document itself
  • fixed coloring of pads and region bordercontrol points

191: 13 04 19

  • a comment that only holds a link can be right-clicked to open in the browser
  • recent sketches now show in reverse order: most recent is topmost
  • fix: improved recizing of nodes, regions and ioboxes
  • fix: input/output indicators on pins and pads are now in sync with tooltip (again)
  • fix: selected spread ioboxes can now be deleted with backspace when hovered with the mouse

180: 11 04 19

  • fixed background for definition patches
  • Skia ButtonBehaviour now lets you specify which buttons to listen to

177: 10 04 19

  • new setting DocumentAskOnFirstSave sets whether to ask for save location on first document save
  • added "Show Intro Patch" to quad menu, to recall intro patch even if it's not shown on startup
  • reactivated play/pause mode visualization
  • various coloring/theme fixes
  • active tab is underlined (again)
  • definition patches now have a hatched background
  • removed RestructureDocument from patch context menu
  • default count of a collection pin group can now be configured
  • Skia Group defaults to 2 inputs (again)

150:

  • VL.OpenCV now comes with demo patches in Help Browser!
  • fixes for Skia ImageReader and ImageWriter
  • added '-m' or '--allowmultiple' command line arg to allow running multiple instances side-by-side
  • shortcuts are deactivated for patch when Finder box is open
  • several fixes for IOBox drawing and interaction

139:

  • fixes various assembly not found exceptions when using nodes of the Midi category, the Script region or binary serialization: a, b, c

137:

  • fixes problems with pin-editors: a, b, c
  • enables spread-editors directly on pins

134:

  • Info.vl in now called Intro.vl
  • double-clicking .vl files will open with the already running instance
  • Skia renderer goes fullscreen via F11 or Alt+Enter
  • many fixes and tweaks

Apart from the promised and still missing parts, we're aware of quite some little glitches still and will update the download link above periodically. So please check back often and report your findings!

Yours truely,
devvvvs.

joreg, Tuesday, Nov 26th 2019 Digg | Tweet | Delicious 22 comments  

Patcher People!

It's been a while since the b38.1 release. But finally we're getting ready to release an update to vvvv beta. Here is the release-candidate, meaning it has all we wanted to add for beta39. We only want to give you a chance to test this with your current projects so we have a last chance to squash any new bugs, you may encounter.

Fancy shading with the new PBR effect contributed by flux

Here are the highlights of the upcoming release:

General

  • We get rid of the term 'alpha' and replace it with the term 'beta-preview' to be in line with gamma and gamma-preview
  • Finally we ship an installer! Just a few clicks and you should have vvvv beta running.
    • Optionally installs the addonpack for you.
    • Still we left good old setup.exe there but renamed it to config.exe, since you don't necessarily need to run it anymore to set things up
    • We're also planning to offer an offline-installer, but only for the actual release (not every preview)
    • We're also keeping the .zip downloads
  • For convenience, by default new patches now save to %User%\Documents\vvvv\beta(-preview)\Sketches. Like this you can quickly find your recently created patches via a new main menu entry: Recent Patches
  • We've added two shortcuts to the main menu:
    • Show Installed Packs: opens explorer pointing to the \packs directory
    • Download Contributions: opens a browser pointing to the contributions page
  • vvvv beta now supports RCP out of the box, which allows you to expose IOBoxes to control them remotely. See the helppatch of Rabbit (RCP) for details.

New nodes

  • WebSocket (Network Client)
  • PBR (DX11.Effects), PBRInstanced (DX11.Effects)
  • PBRTextured (DX11.Effects), PBRTexturedInstanced (DX11.Effects)
  • MaterialPropertiesPBR (DX11.TextureFX)
  • Lights (DX11.Layer PBR)

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

Download

vvvv beta39 x64 RC11
vvvv beta39 x86 RC11

Changelog for Candidates:

RC11

  • fixes on bumpy Damper
  • fixed SVGWriter

RC10

  • fixes issue with girlpower\VL\_Basics\ParticleSystem not loading

RC9

  • Press IOBox now releases when left button is click while right-pressing
  • Fixed a bug in OSC nodes
  • Dampers can now be used in loops
  • fixed image tooltip
  • fix on tooltip layout
  • some color operation improvements
  • can now create a node while linking by simply starting to type

RC8

  • updated to latest VL
  • removed a few unnecessary Damper versions
  • fixed time step calculation of Damper (Fast)

RC7

  • Installer finds path to Powershell.exe on it's own
  • VL close dialog lists unsaved documents
  • some minor fixes on VL Damper nodes
  • fix for C# node input pins that access an empty spread

RC6

  • SaveAs inside VL editor back again - node references in v4p should now get updated correctly
  • Fixed a few crashes of VL serializer when dealing with object fields
  • PBR nodes should show up in nodebrowser again
  • SelectNodesDontScroll added

RC5

  • Regions now show timings again
  • Node tooltips now show timings for the current instance
  • Image download from GPU will again happen in AsImage node to avoid breaking changes and potential crashes in existing patches
  • installer adds vvvv folder and process to Windows Defender exceptions

RC4

  • changed AppData location for nugets to \beta(-preview)_{architecture}\nugets
  • removed AppData location for packs again (to be reconsidered after b39)
  • in VL outboxes are working again
  • installer checks and installs DX9 and VC++ Redistributables correctly

RC3

  • Ctrl+P now creates new patch pointing to active patchs directory
  • fixes problem with AsImage (DX11)
  • fixes problem with saving a new patch to \Sketches

RC2

  • adds options to register .v4p and .vl from the installer
  • fixes an issue with the installer popping up config.exe unnecessarily
  • fixes Ctrl+G
  • fixes Keyboard (Devices Windows) Enabled pin
  • fixes global references to .fxh includes for dx9 effects

So please give this release candidate a spin and be sure to report your findings, preferrably in the forum using the "preview" tag, or also just by posting a comment below.

joreg, Wednesday, Nov 13th 2019 Digg | Tweet | Delicious 29 comments  

In preparation for the Xenko game engine integration we decided to change the default math library of VL from SharpDX to Xenko. The decision was particularly easy since both math libraries have the same origin and most types and methods are identical. And thanks to the VL import layer it's easy to switch out the types, without any noticeable changes for the VL user.

What you get:

  • Existing VL patches will continue to work as before
  • No conversion needed when working with Xenko
  • Faster matrix uploads to GPU (see below)

Trivia

We are (again) in luck with Xenko since it just so happened that Alexandre Mutel, who developed SharpDX, was a core developer at Xenko. We actually didn't know that at the time we started to work on the VL core library. We chose SharpDX mainly because it was well established, complete and open source. So it was quite a nice surprise when we browsed the Xenko source code for the first time and saw that they basically use the same math code.

Download

Here are direct links to the latest preview versions:
vvvv gamma 2019.1 preview 624
vvvv_50alpha38.2_x64
addons_50alpha38.2_x64

Technical Details

This section is only relevant for library developers.

Transposed Matrix Memory Layout

Xenko's 4x4 matrices have a transposed memory layout compared to SharpDX. This is not to be confused with transposed matrix elements (M11, M12, M13 etc.), it is only relevant when doing low-level operations with memory and pointers, such as uploading them to the GPU. The big advantage of it is, that Xenko's matrices can directly be uploaded to the GPU without the overhead of transposing them.

Changes on C# Projects

Most C# projects written for VL don't need to be changed. Only if they use the SharpDX.Mathematics nuget to work with vectors, matrices, rectangles etc.:

In order to transition your C# project to Xenko, remove the SharpDX.Mathematics nuget and install Xenko.Core.Mathematics instead. Then change the using statements in the C# files:

//old:
using SharpDX;
 
//new:
using Xenko.Core.Mathematics;

If you then get an error on compilation, your project might be in the old format. Upgrading is quite easy, it just involves changing the header and deleting most lines in the project file. Follow this guide or join our chat if you need help.

Please give the new version a spin and send us a report if anything doesn't work as before.
Happy calculations!

Yours,
devvvvs

tonfilm, Friday, Aug 23rd 2019 Digg | Tweet | Delicious 4 comments  

Here we go!

As mentioned previously, an update to how tooltips look and work, was one of the two main things missing before we call vvvv gamma a 1.0 release. And they have just landed in the preview, horray!

Previously tooltips where text-only, rendered all in one style and often contained rather cryptic information. Now we have structured information that is nicely presented and we also tried to replace weird messages with human readable text where possible.

Nodes

Tooltips on nodes foremost show the nodes full name and category plus its "Summary" and "Remarks" help information in two separate paragraphs. Additionally, if available you'll see timing information, ie the amout of time the node needs to execute. Operation nodes can also show you the name of the operation they are currently executed on.

A process node with summary, remarks and timings
Operation nodes can also show the operation they are called on

In case a node has an error or warning, we try to help you understand what's going on by answering the following three questions:

  • What is the problem we see?
  • Why is this a problem?
  • How can you deal with it?
  • In case of warnings: When can this warning be ignored?

Also, while a warning/error tooltip is visible, pressing CTRL+C copies the message for convenient pasting, eg. in the forums.

Toggle warning/error info by pressing SPACE

Pins

Tooltips on pins foremost show the pins name and datatype. For for primitive types (like numbers, strings, colors,...) that can easily be displayed, we also show the current value.

Pin tooltips showing name, type and value

In cases of collections (like spread), we also show the current count and again, if the datatype is displayable, we now show up to three slices, as compared to the previously only one.

Collections show up to three slices

Oh, and the obvious:

You're vlcome

Links

Tooltips on links are by default only visible, if the link has an error or warning. To get a tooltip showing on normal links, to see their datatype, press CTRL while hovering it.

Links can show values too

Scaling

Zooming patches is nice, but we figured independent of that, we also want to be able to define the size of a tooltip. so zooming tooltips it is:

Press CTRL while scrolling to zoom a tooltip

Explorer

Also the patch explorer got a bit more informative using the new tooltips.

Tooltips on the patch explorer

Nodebrowser

Same goes for the nodebrowser, which should make it easier to find the right node as the summary and remarks are now much more pleasant to read.

Tooltips in the nodebrowser

Settings

And finally, there are a now a couple of more settings to tweak for tooltips:

  • Classic: enable to go back to the old style tooltip
  • Scaling: default value for the tooltips size
  • ShowAdvancedTimings: make process nodes show timings for individual operations
  • ShowObjects: show innards of patched objects
  • ShowLocalID: mostly for our internal debugging use
  • ShowMoreInfo: default state of errors/warnings with more info
  • ShowOperation: which operation the node/pin/link is on
  • ShowSymbolSource: which document the node is coming from
  • ShowTimings: show or hide timings alltogether
  • StdDelayInMilliSeconds:

A few tweaks here and there and more viewers to come for more special datatypes over time...but the biggest part is hereby done. To test, download the latest preview and then please let us know what you think in the comments.

joreg, Thursday, Aug 1st 2019 Digg | Tweet | Delicious 4 comments  

anonymous user login

Shoutbox

~3d ago

joreg: Know someone who should learn #vvvv? Send them to one of our intro workshops in #Berlin https://nodeforum.org/announcements/2020-series-of-2h-introduction-workshops-to-vvvv-gamma/ #creativecoding

~4d ago

udo2013: @sunep:had an idea how to restore midi-data by one lick and bring the sliders in original position.patch in forum."restore midi.."

~10d ago

sunep: @udo2013 make a forum post about and I can share my subpatch

~10d ago

sunep: @udo2013 I have myself dealt with that problem by using LTP (Value) in pickup mode

~13d ago

~14d ago

~16d ago

joreg: @soundreactor: yes

~16d ago

soundreactor: is 50beta.. supposed to be working in windows 7 ?