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


new post

Blog-posts are sorted by the tags you see below. You can filter the listing by checking/unchecking individual tags. Doubleclick or Shift-click a tag to see only its entries. For more informations see: About the Blog.

  reset tags

addon-release core-release date devvvv gallery news screenshot stuff
delicious flickr vimeo
Order by post date popularity

previously on devvvvlopment: vl-networking-and-async

With beta35 (including VL) out in the wild and people apparently starting to use it (see forum threads about it) we're quite happy with the feedback so far. We know of people already including VL in their daily patching and getting the hang of it. Others are still more cautious and are waiting for better documentation or are hoping for node17 to open their eyes. All fair enough, no pressure.. in any case the question is of course:

What next?

One of the many aspects that vl will be different when compared to vvvv is its node-library. In vvvv we have a closed-source base-library (written in delphi and closely bound to the vvvv core) plus a wide range of open-source nodes including community contributions (written in c# via a plugin-interface). For vl we'll still distinguish between a base-library and the rest, but all libraries will work the same way, ie not be bound to the core. And not even need a plugininterface. And be open-source.

So from the beginning in vl we separated core from libraries and already have a git-repository including all of VLs libraries organized in neat packages (as you can basically already see in your beta35\lib\packs) that we're ready to open. Why haven't we done so already? Well, by releasing library source-code we're kind of committing to a style that everyone should be able to use to write nodes for vl. Therefore this is really a crucial part that we simply wanted to give a second look.

Jump to 49:55 for: Defining Nodes

Remember when at node15 we teased how to define nodes for vl? Everything already felt fairly simple indeed. The typeimporter, a breeze. As mentioned in previous blog-posts we've been continuously importing libraries ourselves since then and noted a few things that we needed to improve to make the workflow for future library developers even more convenient.

So this is what we're reworking at the moment and what we hope to be releasing soon:

  • the complete vl node library as open-source
  • documentation on how to import/write your own nodes/libraries for vl
  • documentation on how to package your libraries for consistent distribution

This will reduce the barrier for developers enormously because everything they have to do to contribute to the vl nodelibrary, will be very little vl-specific and very close to what any c#/.net developer is doing anyway.

Other than that our focus until node17 will continue to be the integration of vl with vvvv, improving documentation and adding the one or other smaller feature. So, that at node17 we have a strong foundation to teach on and hopefully even already some new, contributed libraries..

Until the next update,
good patch!

joreg, Monday, Jan 30th 2017 Digg | Tweet | Delicious 3 comments  

previously on VL: vl-progress-report-4

Networking is a huge topic and we just started scratching the surface. While in the process of implementing more features we want to stay flexible to unify nodes and namings to keep the nodebrowser tidy and the patching experience nice and easy! Therefore later mentioned nodes are published as experimental since they might be subject to signature changes still, meaning pin and node names.

things you know

the vivid blog reader already knows the drill: everything stays the same if you liked it just the way it was.

Simple VL UDP nodes
vvvv flavoured UDP send and receive nodes

Specify remote host (IP address), a nice port number, connect some data and bang the send to let your UDP packets travel over the network. Or open a server to receive bytes arriving on the specified port. The only difference to vvvv you might see is, that here you also get infos about the sender of the packets via the Remote Endpoint output (which is an IP Address and a port)

Simple VL TCP nodes
likewise vvvv flavoured TCP Server and Client nodes

same same for the TCP nodes: The client will try to connect to a server. And once the connection is established, you can send and receive bytes.
The TCP Server awaits incoming connections to talk to. The subtle difference here is the Tuple input, where you would expect the data pin. No one ever requested it, but now you can decide which packet should be sent to which client by specifying IP address and port together with the message. In case you still want to send the same packet to all of your clients, just set the address to and port 0

UDP & TCP revisited

so why did it take so long, what's the goodies behind that?
Unlike the monolithic networking nodes in vvvv you can peek inside the VL ones. The goal was modularizing on a much lower level to be able to provide the very basics as nodes for the patcher:

  • Timeout on send and receive (you have that one via @phlegma in the TCP (Network Client Advanced) node in the addonpack)
  • access to Local Address and Local Port: means you can have senders and receivers bound to different networkcards (not just listening to any packet coming in on a certain port as it was now, or relying on the system automatically chosing the right card to send from)
  • amongst which cards are available and running, get all sorts of information about the network capabilities of the system
  • The guts of UDP and TCP are tightly built around Berekley Socket where you have tons of infos and code snippets on the web. untested yet, but you should be able to tinker your own networking magic, e.g. speak the raw IP protocol directly.
Socket base stuff
UDP and TCP nodes implemented on the base Socket type

woei, Saturday, Jan 21st 2017 Digg | Tweet | Delicious 2 comments  

Good news everyone, from now on you're getting a brand new node able to talk to your loaded-with-firmata Microcontroller Boards (like Arduino, Teensy, Particle.io, ...):

  • FirmataBoard (Devices)

Together with jens.a.e (author of the original Arduino (Devices StandardFirmata 2.x) ) we've looked for a more convenient, easier and faster way to patch microcontroller related ahhmm... patches.

With this implementation:
  • Just plug a DigitalWrite (Firmata), AnalogWrite (Firmata) or ServoWrite (Firmata) node to the FirmataBoard node (or concatenate them together) to set the pins of the Board.
  • Connect DigitalRead (Firmata) and AnalogRead (Firmata) nodes to get the values from the Board's pins.
  • Use the Sysex Messages output to receive different 'Sysex Messages' sent back by the Microcontroller Board. Some Sysex decoders are already there (see StringDecoder (Firmata), CapabilityResponse (Firmata), FirmwareResponse (Firmata)). Sending custom 'Sysex Messages' is easy as well.
  • The node is able to talk to any microcontroller board loaded with the standardized Firmata firmware without any further configuration. In the Arduino-world such Firmata firmware is called "StandardFirmata".
  • Have some custom Firmata running on your chip? Just provide the configuration manually using the BoardConfig (Firmata).
Easier than ever before:
  • no need to supply a spread for all 20 pins and then SetSlice some of them to particular values.
  • no need to define the 'PinMode' for each pin.
  • no need to define which pins should report their values back.

Hardware for the development was kindly provided by QUADRATURE.

Oh, by the way, these new Firmata nodes are fully implemented in VL.

And of course there are some caveats.

  • The Cons (Firmata) has only 5 input pins which are interleaved with 'BinSize' pins. But note that you can cons multiple cons nodes... (for now)
  • The VL nodes eat more processor ticks as their C# counterparts. Working on it...

The nodes are now available in Alpha Builds.

This is a rework of the original release of 'Arduino Second Service'.
See the previous (now outdated) blogpost.

robotanton, Sunday, Dec 18th 2016 Digg | Tweet | Delicious 0 comments  

this little feature upgrade for both vvvv and vl has been lingering around the alphas for a year already...

do you (have to) create touch applications with vvvv? then read ahead:
Pan, Zoom, Rotate, TwoFingerTap and PressAndTap touch gestures are now handed over to you via the GestureDevice. As expected they're multitouch capable, so they report an ID, the position, the distance (Pan & Zoom amount) or the Rotation, and a device ID (in case you have multiple monitors hooked up)

vvvv gesture nodes
gesture node set in vvvv

As with the Touch nodes, these also rely on the windows message loop. so touchscreens with windows capable drivers required. fortunately most screens do have these nowadays...

check the helppatches for a microdemo

As mentioned, everything is accessible in VL as well. though you have the equivalent of the vvvv nodes as the one GestureState node you see a lot more nodes. due to VL understanding types it's possible to have much more fine grained control over how to deal with the incoming gesture events.

vl gesture nodes
vl gesture node set

hope you like it,
happy fingering

woei, Wednesday, Dec 14th 2016 Digg | Tweet | Delicious 0 comments  

previously on VL: VL: Many Paths Lead to Rome


so while the features are freezing we're still cooking the bytes on a low temperature to get them all smooth..

UI Performance

Finally we took the time to do a few performance tweaks on the UI. Not perfect but quite an improvement to what you've seen so far. Selecting nodes and moving them around is now definitely at interactive rates. What you'll still see is that your animations are interrupted while handling the patch. While this might be annoying in the first version of the VL integration, we have worked on the foundations for a non-blocking approach. So expect that to improve in the future. Just not now, priorities are to make everything work first.

Clocks and Time

Previously all VL nodes which do time based calculations had to have an input pin for the time per operation. The default value for the Time type was set per frame by the VL runtime.
This is now different: You can make a Clock or a FrameClock input on the Create operation of your patch or type and store the clock in a pad to access the time in the other operations. This prevents you from making time inputs for every operation. The default value of the Clock if nothing is connected is the VL runtime frame clock.
The Clock type is very simple and only has a Time property.
The FrameClock has a additional property TimeDifference which holds the delta time since the last frame. This saves you from calculating the delta time everywhere on your own.


  • there've been some fixes for high-dpi screens
  • in the patch-explorer (topleft) unused properties now draw transparent
  • vl-nodes in vvvv now turn red if there is an error in vl
  • some unnecessary entries have been removed from the TypeChooser
  • the nodebrowser now shows more help strings when hovering nodes
  • the middleclick alternative (alt+leftclick) now also closes patches when pressing it on a tab
  • new optional via settings:
  • MouseWheelZooms: true by default, vertical pan otherwise
  • NavigationShowCategoryDropDown: false by default, show C menu otherwise
  • NavigationShowNodeDropDown: false by default, show N menu otherwise
  • press ctrl+0 to reset zoom/pan in a patch
  • the Documentation Form (ctrl+M) now follows when navigating patches
  • you can now type a pin as Spread<> to get a spread in vvvv (needed to be Sequence<> so far)
  • defaults of pins now propagate upstream correctly
  • a couple of tweaks/cleanups to the VL.CoreLib.vl

Next Steps

If all goes well we'll see the beta35 (including VL as a first class patching language) release soon™ and with it we're entering phase 2 where we'll actively try to convince you to have a look at VL and actually start using it for your projects. At the risk of repeating myself.. this should be done by updating the gray book and providing a couple of introductory video tutorials. And then the world...

If you want to get started with VL right now, here is what you do:

Diving into VL

If you want to let us know that you like anything you just read...we're always up for a comment or even a flattr:

joreg, Wednesday, Dec 14th 2016 Digg | Tweet | Delicious 4 comments  

after let-me-present-to-you-file-io, here comes another thou shall not be afraid

known nodes
handling files and folders as usual

the last post demoed reading and writing files... but the shown iobox with the filename inside actually gracefully skipped the part on how to get to your file. so up above you see the set - well known to any vvvv user who - which takes care of handling directories, files, folders, paths,...

guess, no need to say much about those. Watcher and File/FolderDialog are of course non-blocking and Copier and Mover do their work asynchronously in the background.

so what's the Path thing?

VL extends the behaviour of vvvv string ioboxes a bit. in vvvv you could open up a folder or file selection from the iobox directly. you can again do that, of course. however, the system now knows about Paths, which is more than just a simple string. sounds a bit academical, right...

path makes this possible

the nice thing about this Path Type is that everything feels more like file handling in the explorer

  • most nodes now work on both file and directory out of the box: Modified, Exists, Get/SetAttributes...
  • Size gives you either the one of the file or, in case of a folder, of everything that's inside
  • Copy, Move, Rename and Delete do their job on files as well as folders: eg. no need to move every single file inside a folder to a new location anymore (juggling the strings to preserve the subfolder structure...)
  • traversing file/folder hierarchies is now a piece of cake (think asset management!): you have parent/children relation - not a flat spread of strings anymore
woei, Monday, Dec 12th 2016 Digg | Tweet | Delicious 3 comments  

Thanks to MESO our HTMLTexture (EX9.Texture) node got another update to version 3.2840.1513.gf7effc7 (Chromium 54.0.2840.59) of the Chromium Embedded Framework.

The most important change compared to version 3.1750.1738 (Chromium 33.0) shipped with beta34.2 is probably the improved font-rendering quality by making use of DirectWrite.

For a complete list of changes between Chromium 33.0 and 54.0 have a look at the official development blog of Chromium.

Advanced features like WebGL, Flash, PDF rendering etc. should all be working, but compared to Chrome itself playback of H.264 encoded video files will not work because we do not have a license to ship these proprietary codecs. For a more detailed discussion have a look here.
In case you need to support these codecs you'll have to build the exact same CEF version we're using (3.2840.1513.gf7effc7) on your own (with set GYP_DEFINES="proprietary_codecs=1") and replace our shipped CEF files with those of your custom build.

As always the node can be tested using our latest alpha builds.

Elias, Monday, Dec 12th 2016 Digg | Tweet | Delicious 0 comments  

There's been a plugin programming feature request by VVIPP vux to get a custom node pin that could also accept value/color/string/transforms which got resolved a while ago. As there were no further complaints about the way it got implemented in the API we now will commit us to the following changes:

  • All pins are now based upon the rather abstract node pins implementing different data interfaces.
  • You now can create an unspecific node input that just asks for different interfaces dynamically and by that can work with different types of data of the builtin pins.
  public INodeIn FX; // unspecific regarding the expected data

later on you then can ask for a handle on the data via:

FX.GetUpstreamInterface(out myData);
  • test for specific data by asking if myData supports IValueData, IStringData, IColorData, IRawData

As a side node: Making all pins compatible might help users at times. All data can now flow over GetSlice (Node) and Switch (Node) nodes.

See "girlpower\VVVV Plugin API\VariantPins" for an example for a Switch that is connected to colors, strings, values and whatnot at the same time.

various data over one connection

original request: https://discourse.vvvv.org/t/plugin-interface-feature-request/12639

gregsn, Sunday, Dec 11th 2016 Digg | Tweet | Delicious 5 comments  

Ever wanted to tweak time? Well now you can!

As a patcher you might want to have a look at the Clock (VVVV) node and look at the help patch to get startet. Have some animation running to see the effect. It already allows you to set the time that all time based animations are based upon. The help patch also shows how to create a clock that just lets you tweak time by a small factor. So there is lots to play with.

Also for plugin developers there is a low latency way how to set the time. Register your timeprovider (aka clock) at the host via:


You have two options:

  • hand over a delegate that should be called back or
  • implement interface ITimeProvider and hand over self

In any way the host will ask you to decide upon the current frame's time, just right before the frame gets calculated. You're completely free on how you provide the time. You may base your time on the original frame time or implement another notion of time.
See girlpower\VVVV Plugin API\Time for an example how to tweak time with the API.

you now can even freeze animations:

this animation is frozen in time
gregsn, Sunday, Dec 11th 2016 Digg | Tweet | Delicious 2 comments  

previously on VL: vl-progress-report-3

Dave Skylark said
same same, but different

on the way to catch up with what you know and need from vvvv, the first choice for expanding VL core library was to work on file thingies. The following should look extremely familiar and probably quite unexciting for you:

FileReader and FileWriter
the very basics needs

These guys do exactly what you would expect them to do: read from file, respectively write to a file. as a convenience nodes you have string versions, the standard ones give you bytes.

since it's 2016, these nodes do their work asyncronously, hence these output pins, which keep you informed about the working status, giving you the opportunity to draw some nice loading animation.

async loading info
async working status info

it wouldn't quite feel like vvvv if the curious ones could not actually peek inside the node to see what's going on

inside the FileReader
the guts of the FileReader

looks a bit overdone for such a simple thing, right?
the motive for the splitting up into File and the actual IO operation has a couple of (imho) good reasons:

chaining operations
chaining io operations

no need anymore to load the whole file and then decide what to do with the content. you can for example parse the header of a video file, look up some frame offset and directly do a partial read of just the blob you are interested

control over file access

there are a bunch of ways to access files. now you can actually control all of that. one reason might be security, since you can decide, whether anyone else can read or write or even delete the file at the same time. you can set it to forcibly create a new file, so you don't accidentally overwrite something existing.
another reason is performance, you are welcome to dive into the deeps of the web to find out which combination of modes causes which thread to do the work. we tried to set the defaults for best performance for parallel reading.

stream stream stream
Stream Operations
the ops: left blocking, right async; also available for strings

the File node actually returns the FileStream. so all these operations can instantly be used with anything else, that is a stream (which is a lot of things in the .net world)

while the async details here are still hidden away in the c# code of the nodes, the process has paved the way towards general patching of threading/async computation. stay tuned...
woei, Thursday, Dec 1st 2016 Digg | Tweet | Delicious 1 comments  

anonymous user login


~1h ago

david: @neuston: email is going out very soon!!!

~1h ago

neuston: @sunep Thx, but I have checked the spam folder but could not fine any

~4h ago

sunep: @neustron have you checked your spam folder? Mine went to spam.

~5h ago

neuston: I've not received any activation email for Talque, after purchased tickets of NODE20 last week. Is it normal? just want to confirm.

~12h ago

boplbopl: @tonfilm nice!

~13h ago

tonfilm: The first #vl #stride screenshots are here! vl.stride-earlyaccess-screenshots #visualprogramming #dotnet @stride3d #creativecoding #vvvv #gamedev

~1d ago

udo2013: @systray27 thank you :)

~3d ago

systray27: @Udo2013> Wow that's beautiful!

~8d ago

mediadog: @tonfilm Thanks! Need to kill a specific vvvv instance, so that enables "taskkill /FI "WINDOWTITLE eq (title)"