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.
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...
Happy to announce that one of the most requested features for boygroup setups is implemented at last:
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.
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:
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:
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:
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.
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.
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:
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.
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.
Stefan Duffner, the developer of Qfsm kindly added an export window with vvvv automata code. From now on you can easily design your very complex logical state machine with a graphical editor. The Automata code is even updated live, when editing the state machine:
Download Qfsm for windows here:http://sourceforge.net/projects/qfsm
A little tutorial can be found here:
Merry Chrismtas vvvvolks,
didn't posted lot of plugins lately, and they are now all posted in a row in this christmas pack :)
There's 43 new nodes for various things including:
This very simple effect is needed just too many times. I bet people have been repatching the behaviour of a slideshow many times. Even a Slideshow might be a cheesy way of presenting things, i believe you will need it from time to time. If you want to add features, patch it and start a vvvvorum thread. This is version 1.
anonymous user login