» 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

And here we are, another fresh DirectX11 release, which gives a nice 1.3 bump.

  • - Begin Small Update (1.3.1) :

Two small issues decided to hide themselves in latest 1.3, and since they are annoying enough they deserved a quick fix and a 1.3.1 bump:

  • Group (DX11.Layer) and Enabled (DX11.Layer), when disabled and stacked, could cause some upstream nodes to fails, and then preventing render of next groups in line. This is now fixed
  • TextureFX, with it's latest update, had an eventual issue when patch starts in disabled mode and would not recover from it.

Also since it got implemented, TextureFX shaders that can use "wantmips" now do so (Edge, Blur, BlurDirectional, BlurGlow, BlurPerfector, DistortFlow, DropShadow, UnsharpMask)
.They are all faster in that scenario.

  • - End Small update 1.3.1

For impatient people, here are release highlights:

Texture FX

  • Technique is now spreadable (you can now build some really nice effect banks)
  • Reflection is now performed only on compile (no technique swap penalty), and general better runtime performance.
  • Now technique can have the annotation : wantmips , this avoids to make your own mip pass (runtime will do it for you, and will only do so if input texture requires it).
  • New pin "Preserve On Disable" (spreadable). This allows (When Enabled pin is off), to keep last frame result instead of routing input.

For spreadable technique example, see: girlpower\misc\texturefx_technique_spread folder

Render States

  • Presets internal handling is now less error prone and faster.
  • New blend state presets : MultiplyAlpha, ReplaceAlpha , BlendDestination
  • Several new nodes that allow to modify individual parts of a render state without touching the rest (DepthClip, Wireframe, EnableScissor, AlphaToCoverage


  • New DrawFullScreen (DX11.Layer) : does a standard full screen draw, all ready to go
  • New texture array routing nodes (Search for GetArray), contributed by sebl
  • Renderer (DX11) now outputs input device objects, as well as states, contributed by tebjan
  • Several new convenience Bullet nodes
  • FrameDelays got a fix which was not releasing memory when deleting the node : Also they now block upstream evaluation when disabled (and have auto evaluate flag on)
  • New documentation pages inhttps://github.com/mrvux/dx11-vvvv/tree/master/Docs . For now full semantics and annotations reference.

Patreon and Supporting DirectX11 development

I of course wanted to say thank you to people who did either a Patreon subscription, or by doing private yearly invoice.

There is now an About (DX11) node, which has the names of all Contributors and Supporters.


For next release, the main aim is to upgrade to latest version of Assimp (and it's c# wrapper).
This will allow to import the newly supported formats (gltf), and use more complete wrapper version (specially for loading options).

Please note that latest Assimp binaries will be incorporated in next alpha build (github).

Full Changelog

  • Submodules are now http, which should help for clining entire repository (ssh would fail on forks)
  • Added About (DX11), which contains version number, contributors and supporters information
  • Framedelay (2d and 3d) were not disposing resource when deleted from patch.
  • Framedelay (2d and 3d) now also start render graph (as part of update stage), and do not evaluate upstream anymore when disabled.
  • New blend state presets (available in Blend and Renderstate nodes) : MultiplyAlpha (only multiplies alpha channel, leave color as it it), ReplaceAlpha (leave color and set new alpha), BlendDestination (uses alpha in the render target instead of pixel shader ouput as factor, for opacity masks).
  • Add EnableScissor (DX11.RenderState) : Allows to modify state to enable scissor, without touching the rest.
  • All state nodes now use static enum instead of dynamic string based version, which increases performance for those nodes (no more lookup needed).
  • Add DrawFullScreen (DX11.Layer) : as in title , a fast version instead of using module
  • Gesture (Kinect2.Microsoft) : Fix issue when rceiveing frame and no skeleton is reported (which could happen sporadically)
  • Add GetRigidBodyCustom(Bullet) : Allows to get custom pin of a rigid body.
  • Add BoxContainment(Bullet Rigid.Filter) : Allows to filter rigid body list if they are inside or outside a bounding box.
  • Add SphereContainment(Bullet Rigid.Filter) : Allows to filter rigid body list if they are inside or outside a bounding sphere.
  • GetConstraintDetails(Bullet) : Now outputs related body.
  • Gesture (Kinect2.Microsoft) : Now allows to specify user index manually, instead of using first found skeleton as before.
  • Renderer (DX11) : Now has output for events as well as state for user input (mouse, keyboard and touch), contributed by @tebjan)
  • GetArray (DX11.TextureArray), allows "GetSpread" in texture arrays, contributed by @sebl
  • GetArray (DX11.TextureArray BinSize): same as above, but with bin size (allows combining), contributed by @sebl.
  • AlphaToCoverage (DX11.RenderState) : allows to enable alpha to coverage for multisampling in an existing render state (without modifying other options)
  • AlphaClip (DX11.Effect) : simple effect with texture that discards pixel if alpha is below a certain value
  • DepthClip (DX11.RenderState) : allows to enable or disable depth clipping (near/far plane) in an existing render state (without modifying other options)
  • Texture FX Technique pin is now spreadable (means you can now use different effects for different slices, see girlpower\misc\texturefx_technique_spread folder for an example)
  • Texture FX cache is now more efficient, no more penalty when switching techniques.
  • Texture FX technique can now use a "wantmips" bool annotation, to build mips before the first pass (only if needed)
  • Texture FX has a new option "Preserve On Disable" (spreadable), if Enabled pin is off, keeps previous frame texture instead of passing texture In.
  • Info (DX11.Texture2d) no exception if a texture is null, returns same defaults
  • New reference semantics (MIPLEVELSOF and INVMIPLEVELSOF) to allow to access input texture mip levels in effects (see girlpower\misc\referencing_miplevels for example)

Download Here :

vux, Monday, May 21st 2018 Digg | Tweet | Delicious 1 comments  

It's been a little while again, but here it is, new Directx11 version.

There are many changes around, so I'm not too sure where to start.

First thing, versioning has been updated, no more alpha/beta, that joke about "software is always beta" made it's time, but as we say, shortest jokes are the best, and for many users that sounds pointless and confusing, so now build is adopting a more formal version naming eg : release, with beta and alpha being used for in between releases.

Second thing, build system has been reworked and now uses a build server, which allows direct update to git releases, so users who want to try out early releases can do so much more conveniently viahttps://github.com/mrvux/dx11-vvvv/releases

No more need to build the pre releases yourself.
This also means that users can expect more frequent releases.

Second thing was in the list for a long time, interface has been changed (basically
IDX11ResourceProvider and friends have been replaced by IDX11ResourceHost version and friends. Removing IPluginIO is necessary as it creates some major issues going forward (and never got used anywhere inb the codebase anyway).

For this release ResourceProvider is working alongside Host (it is now marked as deprecated and will be removed from git version pretty much as soon as I finished this post.
Sadly, LayerProvider could not be made to work alongside Host version, so those have been removed already. From what I know there's no custom plugins using it (or they already move to new interface), so on a user perspective there should be no transition issue.

As usual, I think I should have a ready to paste version, and maybe an auto bot to reply in forums, bugs are to be submitted herehttps://github.com/mrvux/dx11-vvvv/issues

Ok now let's go past those (boring) announcements details and go through what every user wants eg : What's new (and download obviously)


  • First general shader node internals got reworked, removing some non necessary pipeline calls, and pin system got updated to moved to mave a lower api footprint as well. Also have some new specific optimization if same geometry is renderered several times). So now Layer shader nodes go from faster to much faster.
  • Shaders also now allow multiple passes: This comes at the restriction that Vertex shader input in every passes have the same signature. See girlpower example (misc/multipass)
  • Fix 64 bits depth format (even if it is rarely used)
  • Effect pass can have topology annotation: Since some shaders expect a specific opology and nothing else, this can now be set at pass level (and avoid some subtle bugs) See girlpower example (misc/topology)
  • New shader semantics (SIZEOF and INVSIZEOF), which allow with a ref annotation, to point to a resource variable. Runtime will auto set this to Resource size. See: girlpower/misc/referencing_variable

New Nodes (or new options in node):

  • Renderer (DX11 TextureSpread): Allows to render to a spread of texture (so you can use various resolutions and formats for each view/projection slice)
  • Text (DX11.Geometry) : Don't think I need much explanations for that one
  • Viewport (DX11.layer Indexed) : Sets a new viewport depending on camera index from renderer.
  • Zip (TextStyle) + bin version (user:sebl)
  • Renderer (DX11) : Now has a flip sequential pin, which allows to handle eventual tearing issues, see girlpower/misc/flip_sequential
  • All platonic solid: Radius pin
  • World (DX11.Layer) Allows to move a whole layer while preserving Camera (View), this is also set in shaders via new semantics : LAYERVIEW, WORLDLAYER, WORLDLAYERVIEWPROJECTION ...
  • ViewProjection (DX11.Layer) Spreadable, can repeat a full scene with a different camera.
  • Anisotropic (DX11 Sampler) : Anisotropic sampler preset
  • Enabled (DX11.Layer) : Blocks both render and evaluate is disabled. Same as group does, but lightweight.
  • TextFormat(DirectWrite.Advanced)
  • Kinect2 (Devices) : Depth Camera Intrinsics pin (user:id144)
  • PixelData (DX11.Texture) : Reads raw pixel data in a stream, no image conversion (can perform stride copy if wanted though).
  • DynamicBuffer (DX11.Buffer Raw) : Raw buffer from stream type
  • DispatcherX DispatcherXY (DX11.Drawer) : convenience nodes for 1d/2d dispatch, which does thread group calculations (avoid to replicate this everywhere)
  • BufferData (DX11.RawBuffer) : gets raw buffer data as a stream.
  • TextSettings (DX11.Advanded) Allows to create a different text engine, specially to allow large text (see girlpower/misc/large_text)
  • InputElement (DX11.Geometry Preset) common input element presets, to use along gsfx and to avoid repeating those over and over again.
  • TemplateComputeBuffer (DX11.Effect) : Template to quickly get started writing to a buffer in Compute.

Fixed Nodes:

  • Info (Assimp.Mesh) : spread indexing was broken
  • Cylinder (DX11.Geometry): Radius issue
  • Text styles had an issue in spread cases (user:sebl)
  • GetSlice (DX11.TextureArray) : Fix some potential error on delete
  • GetSlice (DX11.DepthTextureArray) : Fix some potential error on delete
  • VideoIn (DX11.DShow) : Fix some potential error on delete
  • Renderer (DX11) : Accepts key presses again (user: azeno). This was disabled long time ago due to some silly vvvv core Beep issue.
  • All Readback (StructuredBuffer) can read any structuredBuffer (not only ones from renderers)
  • Vlc (DX11.Texture 2d) reports file as invalid if they are parsing late, instead of potential crash.
  • Add DynamicBuffers (structured versions) : Have a different upload mode Dynamic/Default/Immutable, to eventually improve performances depending on usage (for example, a static buffer should be set as Immutable and Apply set to false asap).
  • Renderer nodes now have a new Depth buffer mode eg: WriteOnly. In case you do not need to read depth buffer, this should be the new default (does not expose an output pin). On newer cards this allows graphics card to improve performances.

Lot of new examples and help patches (20+ from Assimp, Semantics...)

So for users who did read all and did not scroll hear (or just skipped and went straight into contribution page):

Download here:

vux, Monday, Feb 6th 2017 Digg | Tweet | Delicious 7 comments  

here we go.

in an attempt to save the collected wisdom of node13 for posterity this blogpost aims to provide a reference of where all the stuff that was handed out during node13 workshops went.


Video Effects and Compositing


Facade Mapping
DirectX 11 Rendering Techniques I
Dynamic Plugins
Software engineering patterns with vvvv
Bullet – 3D physics based interaction
Building Applications with vvvv
High-level multi-touch gesture recognition
vvvv and the Arduino
  • workshop patches are in \addonpack\girlpower\Arduino
Motor Control
Art and Brainwaves with vvvv
Folding & cutting paper with vvvv
Voodoo Camera Tracker with vvvv
Visualizing dance with Motion Bank


Particle Madness
Working with the vvvv-sdk

more is promised...will update this posting as material comes in.

joreg, Wednesday, May 22nd 2013 Digg | Tweet | Delicious 0 comments  

Hey VVVVolks,

just in time for the weekend we are super happy to share the NODE17 Workshop Video Captures!!!111

In total we have been able to capture 22 workshops. And chrisr spent the last weeks editing the video and sound, uploading, adding video descriptions and bringing it all together.

Happy binge watching!

And if you are searching for the workshop materials, here you go: node17-workshop-material

Yours Truly,

3D basics & building interaction - Part 1

3D basics & building interaction - Part 2

Advanced DirectX11 shading - Part 1

Advanced DirectX11 shading - Part 2

Box 2D

Bullet Physics


Compute shader

Cutting & Folding Paper

Forward+ or how to bring thousand of lights to VVVV

How to use a statemachine - Automata UI

Instance Noodles

Introduction to DX11 rendering

Introduction to VVVV message awesomeness

PBR Rendering

Procedural noise

Supershiny Motion Graphics with Superphong


VAudio basics


VVVV.js Game Engine

Programming DMX and visualizing with grandMA2 - Part 1


Programming DMX and visualizing with grandMA2 - Part 2


timpernagel, Friday, Aug 11th 2017 Digg | Tweet | Delicious 13 comments  
Happy birthday

So where to start...

After a couple or years of bugging devvvvs for features, creating/fixing new bugs, it's finally there.

So there's a little nice hefty number of nodes around already, but let's speak about what to expect from it, except the fact of joreg already being in the starting blocks to submit bugs :)

As usual going to a new API also means there's some changes (bugs) around the corner.

So let's see a bit of (non ordered) features list.

vux, Sunday, Dec 16th 2012 Digg | Tweet | Delicious 27 comments  

photo by benju


this one took us longer than planned, but it was a difficult one in a way that it includes so many new details. if you are following the devvvv blog you should already know about most of the new stuff thats coming with this release. here is a feature-summary:

for the user

  • we finally have a refactoring option. select a bunch of nodes, press CTRL+G and see them be replaced by a suitable subpatch. gorgeous.
  • we got a series of new vector-modules that should just be more comfortable to use than what's been there so far. check:
  • now please have a look at the new Zip/Unzip nodes. they are basically generalized Vector Join/Split nodes but faster. here are some details: zip-and-unzip
  • there has been a subtle change for all keyboard and mouse related nodes. shouldn't worry you to much as a user. is now just supposed to be more comfortable. specifically check the revamped KeyMatch (String) which will save you some nodes from now on. some more on this is here: keyboardstate-mousestate
  • the next thing is a bit more nerdy but just as userfriendly. it basically allows you to control values in your patches from your android phone. here is how: remoting-vvvv-exposing-pins-kontrolleur

for the developer

here is a list of the latest blog-posts with infos regarding changes to the plugininterface for beta28 that should make your devvvvs lifes easier:

for a full list of fixes and changes check the change-log as usual.
good patch,
yours devvvvs.

Download: 32bit vvvv_45beta28 | See Changelog | 2087 Dls
joreg, Tuesday, Aug 14th 2012 Digg | Tweet | Delicious 0 comments  

Rolls-Royce Motor Cars Ltd. delivered more vehicles in 2014 than ever before in its 111-year history, marking the fifth consecutive annual sales record for the ultra-luxury brand.
via yahoo finance

definitely in the wrong business.

helo and welcome to the 4th in a series of year-in-review articles about the numbers that make your favorite multipurpose toolkit that is vvvv. new to this? for last years rant see: vvvv-in-numbers-2013


so lets first have a look at where you come from. as you can see for the second year in a row the first 4 spots have not changed. the exciting bit happened with japan which climbed into the top 6 and settled on spot 5. 脱帽! shall we say thank you to mino and team for creating their vvvvook? oh, 確かにどうもありがとうございました.

2011 2012 2013 2014
germany (-) 16.82% germany (+) 16.99% germany (+) 17.02% germany (-) 13.81%
usa (+) 11.36% usa (-) 10.72% usa (-) 9.87% usa (+) 10.74%
uk (-) 6.33% uk (-) 6.31% russia (+) 5.78% russia (+) 7.39%
france (-) 5.17% russia (+) 4.98% uk (-) 5.64% uk (-) 5.37%
italy (-) 4.66% italy (+) 4.97% france (+) 4.93% japan (+) 4.85%
russia (+) 4.17% france (-) 4.92% italy (-) 4.56% france (-) 4.12%

the number of unique visitors still seems to increase though it gets harder and harder to tell due to a constantly growing number of spam (most of which you luckily don't get to see). on a normal weekday vvvv.org has ~1500 unique visitors. on march 6th 2014 it had 61.410 and not a single one of them bought a license! so i removed that number from the total amount for 2014 and still we see quite an increase compared to the years before:

2010 2011 2012 2013 2014
244.010 313.075 335.056 350.650 408.173

my guess: the number of non-spam unique visitors did indeed increase. just probably not as much as the number pretends (>50k) but rather in a range of ~15-20k like in the years before. sigh.

i spare you the sad details about what browsers you're using. when will they ever learn...

the spam-attack also destroyed the session-overview of the whole year. what you see below is starting from march 7th and compares 2013 (orange) and 2014 (blue).

you had even less interest in vvvv.org during the summer than last year but then made a strong finish towards the end of the year. see the strange spike (marked) end of november? that was when the combined tags of #vvvv and #photoshop in a facebook posting attracted >13.000 people to have a look at vvvv.org according to the click-stats of facebook. speaking of which: na, couldn't care less..

this diagram shows we had a sharp decline in questions asked in the forum. and also all other numbers regarding using features on the website (blog, screenshots, shouts) went down (i'll omit the depressing shot of those stats). the only numbers that went up were new and edited wiki-pages, ie. we put quite some effort in our Documentation and also the translators, most notably h99 (italian) and sebescudie (french), were quite active. grazie mille et merci beaucoup for that indeed.

and apart from the wiki-documentation robotanton has continued his дотошный work on the \girlpower demo patches shipping with vvvv. i can only hope that those efforts have at least contributed to the diminishing numbers of questions asked in the forum.


probably the best indicator of a user-count is the downloads because spambots don't do that. then of course every download is not an individual user but still we can make out two things from the statistics:

  • less downloads overall: bad.
  • slightly better ratio of people getting the addonpack as well: good.
2010 2011 2012 2013* 2014*
releases 4 3 5 5 5
core 45.700 32.100 36.000 45.000 42.500
addons 10.700 14.400 18.800 29.000 28.500

* x86 and x64 combined


as we often heard that people wanted to support vvvv even when using it non-commercially (nobel) early in 2014 we added the possibility to support our development via flattr, a practical and simple way to give and accept micropayments. and really all of the 17 people who requested that, flattred us at least once. some even multiple times so that in the first year we earned 30 flattrs worth 74.60€. now stop laughing already and get yourself an account and join in. then try here, it is fun:
actually a value of 2.48€ per flattr is quite something. like for example a slice of pizza at our downstairs dealer. very much appreciated.

if you're still not convinced. just have a look at the download-numbers again. if every download was a flattr we'd actually fly quite high. don't mistake the actual numbers we have so far with the potential this can have if people understand that it is a good thing to support something you like/use/benefit from not just with a +1/like but some actual micromoney. the crowdfactor then does the rest.

also remember that other vvvv users and contributors can be flattred as well. here are the stats:

1. vux 95 from 23 people
2. tonfilm: 38 from 10
3. joreg: 35 from 10
4. woei: 27 from 10
5. westbam: 25 from 11
6. elliotwoods: 25 from 7
7. velcrome: 8 from 3
8. microdee: 6 from 2
9. u7angel: 3 from 3
10. gregsn: 3 from 2
11. elias: 2 from 1
12. colorsound: 2 from 2
13. dottore: 1
14. robotanton: 1

makes a total of 299 flattrs which i'd like to argue is not nothing. still of course should be at least 10 times as many but it is a start. and btw flattr has announced improvements to their service. looking forward to those.


now first the bad news. as you can see the blue bar is below even its level of 2009. even though for the first time it includes the numbers of our new big business mainstay that is El Protektor. hmm...how can we talk that up..?

how about like so: licenses were bought by 81 (thats one more than just eighty) different companies from 17 different countries on this wonderful planet. compare this with the previous three years:

  • 2013: 69 companies from 17 countries
  • 2012: 61 from 18
  • 2011: 52 from 19

see a trend there? mhm, apparently more and more companies out there are using vvvv and are so happy with it that it feels totally natural to them to pay for their licenses. so proud of you people! (that just gave me the chills). so ja, if everyone just concentrates to get that number up, the other numbers will follow...

here is how the licenses spread over the world. germany and the uk hard to compete with in the top ranks. but then, switzerland made it again to spot three and most amazingly japan doubling its share. 驚くべき! あなたの努力のためにもう一度感謝 mino and team.

2010 2011 2012 2013 2014
germany 43% germany 48% germany 65% germany 55% germany 48%
austria 25% italy 27% uk 10% uk 25% uk 14%
uk 17% uk 12% switzerland 8% austria 3% switzerland 6%
russia 4% usa 3% russia 5% japan 2.8% japan 5.6%
switzerland 4% austria 3% austria 3% russia 2.5% aut, aus, usa 4.22%
south korea 3% switzerland 2% spain 2% france 2.5% russia, norway, czech 2.8%

hey usa, glad to see you back on the ranks. according to website-access-statistics you should be on rank 2 though, or are you just doing all the spamming?

all in all you see we are facing some gravity, but thats exactly why on april 28th this year we'll release our second album!. why did that take so long? hey it took guns'n'roses 15 years to release their last album. clearly good things take a while..

in the meantime get your node15 ticket and prepare for the best. so much looking forward to seeing you all again in frankfurt this year, horray. thanks for every single bug report that helps us polish vvvv and thanks for all your contributions that make vvvv so much more valuable to everyone than we could ever make it alone.

nur das beste im neuen jahr.

joreg, Tuesday, Jan 13th 2015 Digg | Tweet | Delicious 10 comments  

It's been a while again since we last dropped news about that next big thing we still call vvvv50 (50). So in order to get the hype slowly started here are some further notes...

All information given here is still preliminary and subject to change.


45 patch
45 patch. cool.

First a quick recap of what we have with vvvv45 (45) so far: For the first ~6 years in existence vvvv was a rather monolithic thing. We sloppily called it "a multipurpose toolkit" and really only later found out ourselves that it was actually made of 4 parts:

  • a development environment (GUI)
  • a visual programming language
  • a runtime
  • a library of nodes

Still very much monoltithic in that there was no way for the user to change any of those. Only when in 2008 we introduced the plugininterface vvvv became more modular in that it allowed users to create their own nodes, and boy they did (->addonpack, dx11-pack, cv.image-pack, ...).

So the library part was addressed but critizism remained:

  • meeehh runtime, we want to be able to run patches standalone
  • meehh cross-platform
  • ufff spreading hell
  • bäähh GUI..

According to the great Joel Spolsky the single worst mistake you can do when writing a software, is starting from scratch. So we did.


50 patch
50 patch. still looking like shit.

So here is our bold plan, this is what we're aiming at (longterm):

  • a hybrid development environment (HDE) that will be able to host visual and textual languages.
  • a topofthepops visual programming language (with features known from c#)
  • a compiler for that visual language (that creates cross-platform executables)
  • a node library (closely modeled after .net)

Now if that sounds familiar as in "so whats the big difference?" then exactly. Instead of saying it will be completely different we can also say that it will be very much the same only much better. People tend to prefer hearing either. We couldn't decide...

Anyway we're at a point with this where we have bits from all 4 parts implemented and can do simple demos. But mostly we're still focusing on the "visual programming language" which we consider the foundation of the pleasure we want you to have with 50.

Language Features

The great thing about 45 is still that it is simple to learn. Say that again..!? No really, if you approach it the right way (arrogant!) it actually is. There is a huge library of nodes that is hard to grasp, true, but the things you have to know about the visual language vvvv are only a few:

  • spreads
  • framedelay
  • send/receive

Those are basically the language features of 45. Specifically the concept of Spreads is what makes vvvv stand out. It allows you to do simple things quickly but as things get more complex they are quite cumbersome to work with. We call this "low-level" while the goal of our new visual language is to be able to work more "high-level", ie. less thinking about concepts that make things easy to understand for the computer but more thinking in human terms.

So with 50 we're introducing a number of new language features that will make it easier for the user to create more complex programs. Here is the buzz of what we have so far:

  • userdefined datatypes
  • functions
  • interfaces
  • generics
  • events
  • loops

Sounds scary? Naa... you'll see, all a breeze. Really the basics are not changing: You'll have nodes and pins to connect, a renderer, a quad, ... nothing new. If you're not using any of the new features you can still work kind of 45-style only then you'll not be seeing any of the productivity-increase you can gain from using them.

Specifically as you'll not need to use them all right away and you'll be using them without noticing anyway. But in order to talk about them we need to call them names.

In a forthcoming series of blogposts we'll show you how working with those features will feel like. If you already like what you've read so far and want to buy the cat in the sack we're always up for a /downloads|vvvv?.

joreg, Tuesday, Sep 30th 2014 Digg | Tweet | Delicious 17 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  


vvvv has finally arrived in the age of 64bit computing. to you this means you can finally use all of your PCs memory. to us it means we have to maintain two builds now. but nevermind. service is our success.

so basically "out of memory" messages should be out of our memories (cheese us!) soon and content/texture heavy vvvv-applications ahoi. in theory due to the compilers use of SSE2 instructions things should be generally faster as well..but we already noticed this doesn't seem the case just yet. generally.

now available from: alpha builds

and of course every beauty has its beast. so here is a list of a couple of things that are not yet (probably never will be) working in the 64bit builds:

missing from core

missing from addonpack

most of the addons already work with the 64bit build. below is a listing of those which still need some treatment. chances are good that we'll get most of them to run..given some time.

need some bugging towards vux

  • Assimp
  • Bullet
  • Box2d
  • Bass
  • StructureSynth
  • MSKinect
  • FitEllipse, MinimumAreaRect, KMeans
  • all of his EX9.Geometry nodes

some devices

  • all Phidget stuff
  • LD2000 (Devices)
  • LinBus (Devices)
  • RS232 (Devices Spreadable)
  • NWTouchData (Devices NextWindow)
  • SpaceMouse (Devices)
  • Tablet (Devices Wintab)
  • uEyeCam (Devices)
  • WiiMote (Devices)


  • Ssh (Network)
  • Arduino
  • OpenNI
  • FileStream (EX9.Texture VLC)
  • FileStream (Irrklang)
  • HTMLTexture
  • Flash (EX9.Texture) (RIP)


when you want to debug 64bit stuff use:

 scripts/fetch-binaries --platform=x64

in the bash to get the according executables and in the Addonpack.sln set the Configuration to x64.

joreg, Tuesday, Nov 20th 2012 Digg | Tweet | Delicious 8 comments  

anonymous user login


~8min ago

ggml: how to hide vl window from vvvv ?

~21h ago

CeeYaa: https://experiments.withgoogle.com/collection/ai/move-mirror/view Skeleton Tracking with my Browser - cool AI stuff

~2d ago

woei: everyone who likes or has to work with 3d models: something you might wanna try scenegraph

~4d ago

tonfilm: Saving and loading your own data types to disk was never easier: vl-serialization #vvvv #vl #dotNet #visualprogramming

~6d ago

stulloyd: @dominikKoller my little brother works for them.

~11d ago

vasilis: @readme I already did this...but when I reopen my patch and make some changes I press save all..and then the same again. It opens 2

~11d ago

readme: vasilis, Alt+R in your vvvv instance, delete it from vvvv root, save. Otherwise vvvv loads up the patch by default.