» 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

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  

helos,

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  

helos,

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.

@avaos
@d723lld
would be interesting to hear if those changes fixed this problem you had:
vvvv-brings-up-an-error-after-starting-intel-message-catalog

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:

 .IsBoygroupClient
 .BoygroupServerIP
 .RealTime
 .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.

yours,
devvvvs.

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

on optical-flow elliotwoods commented:
"i think the AddonPack is a bit of a failed concept. It works for some users but I personally hate the idea of dumping all available addons into my vvvv folder."

just to clarify: we are aware that the situation with contributions and the addonpack is not perfect. the ideal solution would of course be a fullblown package-managing-system that handles:

  • dependencies
  • multiple sources
  • experimental/stable versions
  • a convenient browser
  • automatic download of missing plugins

sou..but until we have such a tool we think the contribution/addonpack duality works quite well. here is why:

without an addonpack we'd have the forum full of such:
"get this patch, works with beta26, needs contribution A version 2, B version 1 and contribution C version 3 (the one you find on myblog.com/contribC, the one on vvvv.org/xyz is outdated!)

an enduser (and we all are!) should not need to know about addons. for the first contact of a user with a node it is not important for him to know if it is an addon or a native node. if he is interested in that though, he can easily find out via the author-tag in the nodebrowser and find out more about a specifc addon.

the addonpack is a single download for the enduser that makes sure he gets working versions of all addons and their dependencies for a specific vvvv release. true, this adds a bit of a startup-lag but we think this is a good tradeoff for potentially reducing the problems of missing or out of date addons. no fiddling around with individual addons, just get the pack, don't touch it and you should be save 90% of the time.

now not every contributor wants to deal with github so we introduced a second standardized way to contribute addons, the contributions. here it is easy for everyone to upload stuff. also the integration of downloads into ones vvvv installation is easy]: make a directory "contributions" say on your desktop, reference that directory in vvvvs root and put the downloads in there. done.

of course the contributions bare the risk of becoming out of date but again that is an accepted tradeoff in order to make it possible/easier for more people to contribute.

that being said, ideally all addons would be developed in a fork of the vvvv sdk. like this it is very convenient for fellow coders to test/contribute to your stuff by simply pulling your feature-branches. in order to get an addon tested by people not familiar with github it makes perfect sense to upload binaries to the forum and get them discussed.

when an addon is ready for primetime all a developer has to do in order to get it included in the addonpack is then to send a pull-request to the main vvvv-sdk repository. once accepted we can all be sure that a version of all plugins working with a specific release will be available for all users with a single download.

and somewhere over the rainbow when we have the packaging-system we can stop distributing an addonpack and the system works directly with git in order to serve you always the freshest experimental/stable versions of only specifically requested addons (from even potentially different repositories, not only the vvvv-sdk). see? easy as cake.

till then, thanks for all your great work.
your devvvvs.

joreg, Monday, Nov 14th 2011 Digg | Tweet | Delicious 7 comments  

helohelo,

over the years vvvvs codebase has grown quite a bit. it consists of private code and an ever increasing pool of open sources. in addition there are contributions by more than 15 individuals to the addonpack.

we realized though, that working with so many contributors and a centralized version control system (like subversion, the one we used on sourceforge) became a bit of a pain. so in order to make all our coding lives easier we decided to follow the hype and move to github.

there you see the vvvv-sdk repository which contains all of vvvvs public sources plus all contributed sources from plugins in the addonpack (that were previously hosted on sourceforge). while at it we also simplified the repositories directory structure. so essentially you can now get everything you need to develop for vvvv with a single download and are ready to code (in case you're not sure: yes, this is amazing! you could tweet that. prolly smn like: #vvvv #sdk #github #gorgeous).

please refer to the vvvv-sdk wiki page on how to work with the repository (and note that this is not only useful for plugin-developers but also for module or help-patch contributors, as well as for effects magicians, freeframers, etc). if you're familiar with git, it is as easy as "clone, build" to get a complete working/running copy of all of vvvvs public code plus all stuff in the addonpack.

if you're not familiar with git, you'll likely hate it at first. we all did. but do yourself a favor, believe the hype and do some reading on using git (the vvvv-sdk page includes some links). it shold help you stop worrying...it took us more than a month, but we'd not change back.

also while at it we upgraded vvvv and all your plugins to using .net4 (to whom it may concern).

we realize there may be some questions left which we'll answer for you on irc? or in the forums as usual. have a good hakc.

yours,
devvvvs.

joreg, Tuesday, Nov 8th 2011 Digg | Tweet | Delicious 13 comments  

anonymous user login

Shoutbox

~6d ago

Joanie_AntiVJ: I have an issue with some reflection calculations, any vector expert may know the secret of mirrors ? :) https://discourse.vvvv.org/t/help-to-mirror-a-vector/20523/4

~6d ago

Joanie_AntiVJ: I have an issue with some reflection calculations, any vector expert may know the secret of mirrors ? :) https://discourse.vvvv.org/t/help-to-mirror-a-vector/20523/4

~16d ago

joreg: @LCA remember that we also provide custom support for commercial projects: https://visualprogramming.net/#Support

~17d ago

LCA: where to ask about hardware setups: VL application over 26 1080p displays. maybe also with FUSE

~24d ago

tonfilm: @tobyk there is also this, who wants to win: https://bottosson.github.io/posts/oklab/

~1mth ago

tobyk: LCH is the best color space, all the other color spaces are now big losers. https://atmos.style/blog/lch-color-space

~1mth ago

schlonzo: "HowTo Work with Children" somehow I expected something else :D

~2mth ago

fleg: This Tuesday, Cologne: exhibition opening of "interwoven", textile disinformation patterns created with vvvv. https://fleg.de/news/exhibition-interwoven