» 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

dear coders,

this time of the month again... please join your fellow vvvv developers later today on irc to tell us what you're working on or let us know whats bugging you.

 ##vvvv-meetup on irc.freenode.net
 every first monday in the month (ie. july 5th)
 starting 4pm (CET)

chat log archive

04 06 12: developer-meetup-on-irc-2nd-service
07 05 12: developer-meetup-on-irc

joreg, Monday, Jul 2nd 2012 Digg | Tweet | Delicious 1 comments  

here is to announce a little feature nobody has asked for:

basically you can now write a value/spread to any pin of a running vvvv-patch from the outside. sick? yes.

the plugininterface now allows you to write to any pin which is in turn used by a new node called  Server (VVVV) which listens for your udp/osc-messages and distributes received values to the targeted pins, like so:

 /40/30/2/Y Input Value 2.4,2.5,2.6

sending the above osc-message to the vvvv-servers port will set the Y Input Value of the node with ID 2 which sits in patch with ID 30 which sits in patch with ID 40 to a spread of:


see? should allow you to quite mess around..

what the ... green ioboxes?

now of course you don't want to do this all random and find out about the target-addresses manually. as mentioned in a previous posting refactor-to-subpatch there is one primary shortcut left on vvvvs keyboard cheat-sheet which we saved for this moment: ctrl+k (read "kontroll") allows you to expose selected IOBoxes for being controlled from the outside. first exposing only turns IOBoxes green, but inside this sets a flag on the node that can be accessed via the plugininterface which e.g. allows a node like the afformentioned Server (VVVV) to return a list of all exposed pins' osc addresses...

next it would be nice to write values to such exposed IOBoxes from, say a mobile device. this is where Kontrolleur (VVVV) steps in. essentially just an alternative, more specialized vvvv-server that pushes information about exposed pins to the Kontrolleur android app. check its help-patch for instructions.

and like Kontrolleur (VVVV) it could also make (even more) sense to code a plugin that communicates with Control (which seems to be in quite a rework for some time now so i didn't dare touch it) or one that exposes pins via even other protocols (http, whatnot..)

all necessary functionality (reading of/writing to pins, listing exposed pins,...) is accessible via the plugininterface. you know what to do..

now available in latest alpha builds.

joreg, Friday, Jun 8th 2012 Digg | Tweet | Delicious 26 comments  

dear coders,

the meetup shall see its second installment. please join your fellow vvvv developers on irc to tell us what you're working on or let us know whats bugging you.

 ##vvvv-meetup on irc.freenode.net
 every first monday in the month (ie. june 4th)
 starting 4pm (CET)

chat log archive

07 05 12: developer-meetup-on-irc

joreg, Thursday, May 31st 2012 Digg | Tweet | Delicious 5 comments  

dear coders,

due to popular demand we'll try to organize a regular developer meetup on irc to get stuff discussed. if you're interested in talking about what you're working on or hear what others are working on please join us on:

 ##vvvv-meetup on irc.freenode.net
 every first monday in the month (ie. mai 7th)
 starting 4pm (CET)
joreg, Monday, Apr 30th 2012 Digg | Tweet | Delicious 7 comments  


this is the last call for testers to check the upcoming version of 45beta27.2.
instead of releasing all the magic that is cooking (and can already be tested in the daily alpha builds) we tried to create a build that only fixes bugs introduced recently.

edit: fixed another one, so here are new files as of 02 05 12:
so here is the download and changelog for alpha27.2 core.
and here is the download and changelog for alpha27.2 addons.

if noone finds a big deal we'll make this the official beta27.2 on monday, may 7h and continue our ride towards 28.

happy testing,
yours devvvvs.

joreg, Wednesday, Apr 25th 2012 Digg | Tweet | Delicious 10 comments  


this is to announce the availability of a new node called
FaceTracker (DShow9 Freeframe)
in the latest alpha builds. it is essentially a wrapper around Jason Saragih's facetracking library (to whom all credits belong). Please note though that it is only licensed for non-commercial use which means you must not use it in a commercial project even if you aquired a vvvv-license!

additional credits go to enrico viola for guiding the process of implementing jasons library in the freeframe plugin for vvvv. and to marco tempest for insisting on having this in his magic-and-storytelling ted-talk.

Since the facetracker library is based on opencv 2 (and vvvv so far only shipped with opencv 1) this has been upgraded as well. ie. all freeframe trackers that use opencv have been converted to use opencv2 now. this shouldn'd change anything for most of you. only if someone was using a private freeframe-node that used opencv that would now also needed to be upgraded in order to still work with vvvv.

would be interesting to hear if those changes fixed this problem you had:

joreg, Wednesday, Apr 18th 2012 Digg | Tweet | Delicious 3 comments  

ok, this one has been overdue since quite a while. cheese us!

you're patching away and things start to get messy but you're too lazy to refactor parts of your patch to a new subpatch in order to clean up a bit. too many clicks involved and it is only for cleaning up...boring.

there are not many shortcuts left, but ctrl+g seems quite suitable (in fact theres only one more major shortcut left now..still to come..) for a task that groups selected nodes to a new subpatch. admittedly it would be even more useful if the new subpatch would not even have to be saved in an extra file but unfortunately that requires some more work still. so hope this saves us some clicks already...

now available in latest alpha builds.
reports to the alpha forum please.

known issues:

  • redo (after undoing ctrl+g) does not work
  • grouping an unsaved subpatch does not work
  • does not work inside unsaved patches
joreg, Saturday, Apr 7th 2012 Digg | Tweet | Delicious 14 comments  

Happy to announce that one of the most requested features for boygroup setups is implemented at last:
Video synchronization!

In fact all files which you can play with a FileStream (DShow9) can be automagically synchronized by vvvv now, by just replacing the FileStream node with its corresponding boygroup module.

Along with it comes a node Clock (Network Boygroup), which synchronizes an adjustable server time on the clients almost as tight as N'Sync can dance.

So download the alpha and check the help patches!

To realize all that, the IHDEHost interface got some new goodies:

 .SetRealtime(double time)

have a look at the corresponding documentation pages.

please report all missing dance steps in the alpha forums.

tonfilm, Tuesday, Apr 3rd 2012 Digg | Tweet | Delicious 8 comments  

As of this commit the plugin interfaces dealing with Direct3D9 stuff changed, breaking existing plugins using those interfaces. Plugins using the base classes from the VVVV.PluginInterfaces.V2.EX9 namespace are not affected by this change.

The affected interfaces are:

  • IPluginDXResource
  • IPluginDXMesh
  • IPluginDXTexture
  • IPluginDXTexture2
  • IPluginDXLayer

The change was necessary as it was unclear when to release the SlimDX device used by all implementations of these interfaces.

The situation before this change was like this:

public void UpdateResource(IPluginOut forPin, int deviceAddress)
  // The next call will either increase the reference count on the 
  // internal device and add the device to the object table of SlimDX 
  // or it will simply fetch the device from that object table 
  // (if the exact same call was for example made by another plugin)
  // and leave the reference count as is.
  var device = Device.FromPointer(new IntPtr(deviceAddress));
  // if not created yet
  var resource = SomeResource.Create(device);
  // do something with the resource
  // The next call is dangerous, as the reference count to the internal 
  // device will be decreased by one and the device will be removed from
  // the object table of SlimDX, but what about the resource created a few 
  // lines above? Or what about resources created by other plugins, which 
  // might still hold a reference to the SlimDX device?
  device.Dispose(); // Some plugins called this, some not
  // Not calling Dispose on the device is also not correct, as SlimDX 
  // will still hold a reference to the internal device. Say vvvv 
  // wants to go fullscreen and therefor creating a new device it 
  // might not be able to do so, as it can't get rid of the old one 
  // (reference count is still one).

So to get rid of all this confusion, we decided to move the Device.FromPointer() and device.Dispose() calls to a more central place, (where it is exactly known when a device gets created or destroyed) and hand that already created SlimDX device over to the plugin via the above mentioned interfaces. The plugin should never need to create or destroy a device, it should just use it. Therefor the above example gets as simple as this:

public void UpdateResource(IPluginOut forPin, Device device)
  // if not created yet
  var resource = SomeResource.Create(device);
  // do something with the resource

So the rule of thumb now is like it is for every other object implementing IDisposable: only call Dispose() if it is you who created that object. As you didn't create the device, don't call Dispose() on it.

Elias, Thursday, Jan 26th 2012 Digg | Tweet | Delicious 0 comments  

dir alpha patchers,

let us introduce you to a new service: from now on you have direct access to our daily alpha builds. The second we push code to our repository our server builds new packs (core + addons takes it around 5 minutes) and puts them online for you to test. ...and we call those "ahead of time builds" (but you may also refer to them as "alphas").

Please test them heavily and report issues only in the new dedicated alpha forum or on IRC?. We don't want to see any alpha-talk in the normal forum in order not to get people confused. The beta download is still the only one official that is supposed to be discussed in the beta forum.

For those who want to come even closer please checkout the vvvv-sdk which allows you to build all public sources of vvvv (including the whole addonpack) yourself with just a few clicks. This allows you not only to test the latest builds but also to fix bugs and contribute back to vvvvs repository.

The more you test and report, the more stable our beta releases will become. So thanks in advance for your efforts and happy patching.


joreg, Thursday, Dec 15th 2011 Digg | Tweet | Delicious 4 comments  

anonymous user login


~2d ago

udo2013: hi.superphysical läuft bei mir nicht.meldet sich sofort wieder ab.habe vvvv39x64beta/dx11 1.3.1 brauche ich dafür dx11

~4d ago

joreg: In case you missed it: VL.Stride is available as EarlyAccess now: vl.stride-earlyaccess-available-now

~5d ago

~9d ago

evvvvil: Lowlands Juggernauts - Result of yesterday's live coding improv on Twitch, made with 88 lines of shader code. https://www.shadertoy.com/view/ttsfD8

~17d ago

ddf: stride is great

~17d ago

joreg: vvvv meetup live now: https://youtu.be/EiHW0X6zjKE NODE20

~17d ago

~18d ago

~21d ago

david: NODE20 is online http://20.nodeforum.org First infos on how this all works this year...