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.
the upcoming vvvv release (beta28) will contain a new way of accessing pin data by using the IStream interface. please note that it's just "a new way" and not "the new way" as its usage is much more complicated than ISpread and it will only be superior to ISpread if the plugin you want to write accesses its data sequentially.
if you don't mind writing much more complicated code in order to squeeze out every last bit of performance, read on, otherwise you can safely skip this blog post.
for some advanced plugin usage scenarios we introduced two new interfaces in the upcoming 28 release of vvvv:
the device service can be used to enumerate all directx9 devices created by vvvv (for example through a renderer) or to get notified when a device was created or destroyed. this might come in handy if plugins do some kind of background work using a directx9 device (like texture preloading) and need to know when a device got lost in order to stop all processing scheduled for that device. another future use case would be for some sort of directx9 sink node, like a pipet for example, which needs a device in order to be able to evaluate its inputs.
the second interface can be used to get various notifications about all the different stages the main loop goes through when computing one frame. a possible use case could be a custom set of classes/nodes running in some kind of special "subgraph".
both can either be imported or retrieved via two new properties on the IHDEHost.
so we had this problem in our vvvv-sdk git repository that some filenames:
vvvv45\addonpack\lib\nodes\plugins\BézierSpline (Value) help.v4p vvvv45\addonpack\lib\nodes\plugins\BézierSpread (Spreads) help.v4p vvvv45\addonpack\lib\nodes\plugins\RösslerAttractor (Animation) help.v4p vvvv45\lib\nodes\native\BézierLine (GDI) help.v4p vvvv45\lib\nodes\native\BézierLoop (GDI) help.v4p vvvv45\lib\nodes\native\BézierSpread (Spreads) help.v4p
where not displayed correctly and always caused troubles when working with the repository (for some of you).
fortunately with the latest git for windows versions (>=1.7.10) there is full unicode support. so in order to benefit from those changes please update git and then pull from upstream to get those files renamed properly.
if you now face troubles when switching branches (in case you have multiple) you'll have to delete those 6 files, switch to the other branch, remove those files again and merge-in the develop branch so that the commit that fixes the naming of those files comes to your other branch as well.
that's odd, yes, but you'll only have to do it once. and there is a script that deletes the files for you in the sdks root dir. call
to save some clicks.
please let us know in the comments if you have troubles with this.
this is to inform you that latest alphas come with a new commandline: argument
starting vvvv with this option (on windows >= vista) brings you:
texture-sharing can be used to share textures e.g. between two instances of vvvv (without noticable performance penalty) and even with any other software that also supports DX9EX. check the helppatch of SharedTexture (EX9.Texture) for instructions.
apparently this can also work as a bridge to opengl if someone wants to give this a try...and for those wondering, yes this enables stuff on windows your macfriends have been bragging about for a while now using syphon.
another new thing (not related to dx9ex) is the possibility to render the deph of scenes directly without using an extra pixelshader pass. just set the Texture Format of a DX9Texture (EX9.Texture) to INTZ and you should get the depth of your scene rather than a colorbuffer. disclaimer: may not work on certain graphiccards, see here
available now in latest alphas, enjoy.
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)
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:
2.4 2.5 2.6
see? should allow you to quite mess around..
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.
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)
07 05 12: developer-meetup-on-irc
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)
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.
if noone finds a big deal we'll make this the official beta27.2 on monday, may 7h and continue our ride towards 28.
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:
anonymous user login