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.
And here we are, another fresh DirectX11 release, which gives a nice 1.3 bump.
For impatient people, here are release highlights:
For spreadable technique example, see: girlpower\misc\texturefx_technique_spread folder
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).
Download Here :
helo teachers, tutors and students,
we'd like to assemble a list of your educational institutions that teach vvvv in order to:
for 7 years (i just checked my notes) we planned to build a system into the website (similar to the businesses) where you could manage your own little profile of your institution. apparently that didn't happen...so let's try it the oldschool way. there are two ways to add your institution:
in case you send an email please include the following information:
to give you an idea how the information will be presented, see this example:
|Name of Institution||Country, City||Notes||Contact|
|St. Pölten University of Applied Sciences||Austria, St. Pölten||vvvv is being used in the following two courses:
Bachelor Media Technology
Course: Realtime-Engines for Video and Motion Graphics (2x3 ECTS, teaches vvvv from scratch as a tool for realtime video processing, virtual studios, augmented reality,..., in german)
Master Digital Media Technologies
Course: Modular Media Programming (2 ECTS, General introduction into interactive media applications using vvvv, in german)
See Students showreel for examplary works
|Matthias Husinsky motzi|
whenever you have an update, simply modify the wiki-page or send us another email. we'll also periodically send out an email to ask you to confirm your information is still valid, to keep the list up-to-date.
so if you're a teacher, please send us your information, if you're a student please ask your teacher to do so. if you know someone who should be on the list, please let them know about this.
thanks for spreading the word!
Who a a a a, sebl, joreg, david
When Wed, Aug 8th 2018 until Sun, Aug 12th 2018
Where Grüne Hütte, Germany
sun sun sun, here we come!
We hereby launch the first vvvv summer camp and we call it: LINK
Check out its website for all info.
It is all great and shiny with only one caveat: unfortunately the number of people we can host is limited to 25. This is why we have to run a simple application process and depending on the number of applicants we will have the difficult task to tell some of you that they cannot come. booohh..we know.
Please don't hesitate to apply though, we're hoping to assemble a group of not only the usual suspects but also to get to know some new faces!
Also if you cannot attend for the whole time, join us on the public sunday. More information on the website.
So, in a nutshell:
Greetings from the summer camp team:
ann-katrin, david, joreg, julia, laura, sebl
Or microdee's keynode aka long article about what's going on aka "oh no microdee's hyping his own stuff again".
Since September in my freetime I've been working on major refactoring of my packs to be more accessible and more organized and also writing more documentation, help patches and more understandable girlpower while also improving on features and fixing bugs. This all started with unifying semantics and pipelines in mp.fxh and mp.dx shaders but because of my slight bipolarity I've finished a lot of things since then except that. So there are still some inconsistencies on that side and the fate/direction of the rendering part is still hanging up in the air (that PBRBase thing and the Disney shading). I'm a single person on this so it'll take some time.
Meanwhile I've started to make my C# backends 99% independent from VVVV*, started to properly build them on Appveyor and properly publish them automatically to Nuget. The first materialized result of this is md.stdl (microdee's standard library) which is a collection of some common functionalities used often during development (sort of like the VVVV.Utils library, just on my own). More and more features will be ported from mp.essentials nodes to md.stdl. An exciting side-effect of this that md.stdl can be inherently used in VL by its magnificent Nuget support (though I didn't have the arriving to test it properly yet).
Another library, which was separate, then merged into mp.essentials, then grown out of mp.essentials again but this time properly and has its own Nuget now: is mp.pddn (mcropack pin dictionary dynamic node) which is an extension library for creating VVVV nodes with highly dynamic pin management. One of the direct results of this were the introduction of the truly generic VVVV node pattern in mp.essentials and Notuiv (see below) where you can still be type-safe but can manage any type with a single node without the need for VL or C# code.
Meanwhile I've joined the forces of MESO and priorities slightly shifted for me from graphics to re-usable subsystems (of course while directly developing projects). The first bigger realization of this shift became:
VVVV is used to create large scale user interfaces a lot. Anything requires a screen and user interaction VVVV scales in size like no other package does from lot's of tiny screens to huge LED walls the size of a building (or your mom), VVVV can handle that with breeze. Except any professional will know that developing UI logic which people are taking as granted from browsers or smartphones are painful to develop in VVVV's dataflow environment. The shear presence of overlapping UI elements can make your brain explode in pure VVVV. In the past I had several attempts to solve it and they all failed for various reasons (khmvobjectskhm khmvoogkhm). Those shalt be forgotteth and shalt be never spoketh thereof. Learning from those mistakes, and still repeatedly fighting with the above mentioned incomprehensible logic cobwebs suffering from deadline induced chaos and doom, I came up with Notui.
Notui is a UI behavior package written entirely in C# providing a robust skeleton for your UI elements. The intention here was to keep VVVV's vast drawing capabilities while eliminating the above mentioned horror with logic. The result is a mostly dataflow friendly system which separates structure, stateful-logic and rendering. Note also that Notui is a C# library first and Notuiv is its VVVV implementation. This again means all the features of Notui theoretically can be accessed in VL and simply fetched from Nuget.org. This also means that you can patch your own element types and behavior delegates in VL, but I'm ahead of myself.
I hear you saying "Yeah, yeah tl;dr, big words, etcetra etcetra, What are its features?"
For a quick demonstration this can be your typical Notuiv app structure, greatly simplified though (one of the girlpower examples):
Which yields this result:
Expand that patch to see how simple it is to set up this 2 draggable windows with stateful content and animated declarative transitions patched 100% in VVVV with Notuiv:
Read the complete list of features and download on the contrib page: Notuiv
Now at MESO we decided to release Notui and Notuiv as BSD 3-Clause open-source libraries. Which also allows you to use it in your own commercial project without any hassle or royalty whatsoever. So grab the sources here:
CraftLie is super great and tonfilm even created pure C# VL.UI.CraftLie https://github.com/tebjan/VL.UI.CraftLie which at first glance does very similar things as Notui. Unfortunately though the scope is quite different. But nothing stops you to combine CraftLie and its UI thing, VL and Notui to have a powerful system, if you install Notui into VL through Nuget, or just reference Notui.dll from vvvv/packs/Notuiv/nodes/plugins folder. This is kind of untested area yet, so please give me feedback how it went.
Side note: Now for those who want to use Notui outside of VVVV don't get fooled or intimidated by the lines of code count of Notuiv implementation, that amount of boilerplate code is not a Notui specific phenomena . It's an inherent structural issue with how VVVV works. It's a general rule of thumb that if you want to implement a large library solving a big set of problems in a very modular way with lot's of information on their building blocks, VVVV's plugin interfaces requires thousands if not ten-thousands of lines boilerplate to deal with all the conditions a plugin can have. This is 100% solved in VL though.
Disclaimer on the logo: Notui have nothing to do with Israel's new shequel. That symbol just looks great and resembles an 'n' and a 'u' interlocked, throw in an 'i' and you'll get Notui \o/. But if anybody feels offended by this for any serious reason (like if an Israeli person really feel like their national currency symbol is being abused by random UI libraries for simply aesthetic reasons which has nothing to do with it, or with Israel) I'll immediately change it.
Almost forgot you can get mp.essentials and mp.dx from here: md.ecosystem
or through Github releases:
There are couple of smaller important thoughts as well:
First: FBX4V will be open-sourced soon and will become part of mp.dx, and maybe I'll find some time to fix some crucial issues with it during the process.
Second: the refactoring also ended up in a more modern way of deploying my packs. (like how Velcrome's messages and Vux's DX11 packs are doing for ages. All md.ecosystem packs are still available from vpm, but their binaries are finally not stored directly in their repo, and they are available from Github releases for those who are not happy with vpm. vpm itself will be revisited soon as I need to sort out couple of things to fit more into automatic deployment schemes. Also finally because of Appveyor they're all generating version.info files now and also they have About nodes with detailed versioning info too.
2.5th: During this transition I'm also creating nice and tidy help patches with lot's of reading materials where it's suitable and the node has a decently isolated function. So hopefully it will result in less confused patchers.
Third: A reminder that all of my stuffs are open-source on Github, one can easily fork it and send me pull-requests. Yet I can count on a single hand the number of occurrences this happened. If there's no active project with a deadline MESO embraces open source development which can help faster realization of future projects (the reason you have Notui now) so funding wise I'm ok, BUT I'm a single guy maintaining this entire thing, so if you're bored and can do vvvv patching you'll make me the happiest guy on earth if you send me pull requests to my repos fixing minor issues I haven't noticed or improving on my crappy code/patch.
Thank you for reading this through, I hope my packs provide you as much productivity as they do for me. If you have any questions I usually answer them.
Cheers and happy patching!
previously on vvvv: vvvvhat happened in March 2018
more than a month now since the release of b36 and we are happy with it. but are you? anyone using a previous version still? meanwhile we have b36.1 heavily in the making where we are concentrating our work on the vl CoreLib. making it more managable so we can finally open it up for contributions. some of the fruits can already be seen in the nodebrowser if you're using alpha builds. announcement and some explaining words on this still pending. and then quite some crazyshit is happening in the secret labs that we hopefully can talk about soon...geee
one of the more often requested features for vvvv was the ability to run different parts of a project in different mainloops. since b36 this is conveniently possible using vl and the article Patch Your Own Mainloops explains how. no more excuses...
still more on the beginner end of things?
and in case you missed the annoucement: LINK - the vvvv summercamp application will open soon and selected participants will then be informed by june 8th, leaving you with 2 months to arrange your travels.
|some nifty new stuff:||
and updates for two oldygoldies:
and two nice teases from upcoming work by microdee as part of his md.ecosystem 3.0:
happy to see three works in progress shared in april. keep them coming:
and meso documented 3 of their latest works:
Welcome dear patchers to a new episode of devvvvs giving you control over your PC mainboard.
When you work in vvvv or VL the evaluation of your patch is automatically driven by a mainloop. It executes the nodes in your patch (usually) 60 times per second and by this allows changes to happen in your patch over time.
If you have a look at the PerfMeter in a renderer with a mainloop timer without any tweaks you will see lots of flickering like this:
Those flickers indicate that the time between two frames of the mainloop is changing a bit every frame. In an ideal world those flickers would not be there and the time between two frames would always be the same. An unstable mainloop like this creates jitter in animations, drops video frames and lets the visual output of your patch look less smooth.
It's quite a difficult task to get high-precision timer events on a modern computer architecture. Timers and me go way back to the early vvvv days at MESO when i worked on the vvvv mainloop and the Filtered time mode. Since then we could improve the vvvv mainloop time stability quite a bit by doing tricks like changing the windows system timer resolution and introducing a short busy wait phase at the end of the mainloop. The result of this work looks like this:
The experience gathered from the vvvv mainloop improvements is now available in the VL library, so you can build your own sub-mainloops.
But why would you need your own timer at all if you have a good mainloop already? There are a few reasons:
In VL the patch of a process node by default has a Create and an Update operation. Create gets called once an instance of the process is created and Update gets called periodically by the mainloop. In this process node patch you can place other process nodes that 'plug into' those two operations by placing their own Create on the Create of the surrounding patch and their Update on the Update of the surrounding patch.
This is the same for stateful regions like ForEach [Reactive], only that the Update of the ForEach region doesn't get called automatically by the surrounding patch but gets called by the events of the incoming observable. More on that in this blog post: VL: Reactive Programming
There are many sources of observable events. For example Mouse, Keyboard and other input devices as well as AsyncTask or MidiIn. The timer nodes work in the same way. The output is an Observable that is on a new thread and either sends the frame number (for the system timer nodes) or a TimerClock (for the MultimediaTimer or BusyWaitTimer). A patch would look like this:
The use of observables also makes it easy to swap one timer for another if neccessary.
Basically there are 3 ways to setup timers in windows and now VL has them all!
This is the most common timer but it usually only has a precision of 16ms. It can be used for recurring events when accuracy is not the most important issue and the interval is in the seconds range or a higher millisecond range. Nodes that use these timers are for example Interval and Timer in category Reactive:
This is a dedicated timer for applications that do video or midi event playback. It is fairly accurate to about 1ms and doesn't need much CPU power. So it can be used for most time critical scenarios. To use this timer, make sure you enable the Experimental button in the VL node browser and create the node MultimediaTimer:
So that's nice, but it has two little draw backs. You can only specify the period in whole milliseconds and as you can see there is still some flickering in the measured period times. The flickering is well below 1ms but still, we can improve that:
Since its possible to measure time with high accuracy, one can write an infinite loop that always checks the time and executes an event once the specified interval time has passed. This timer always uses 100% of one CPU core because it checks time as often as it can. But hey, how many cores do you have these days? With this method you can achieve precision in the micro second range, which is insane!
If any patch processing is happening on the timer event, the power of your core is of course shared with the busy wait. Just make sure that the processing doesn't take longer as the specified period:
This timer has an option to reduce CPU load for period times that are higher than the accuracy of your system timer. You can specify a time span called Wait Accuracy. This is a time span before the desired end of the period that specifies when the busy wait phase should start. Before that time the timer is set to sleep for 1ms periodically. 16ms is a safe value, but you can decrease it until the Last Period starts to jump in order to reduce CPU load even more.
Both the MultimediaTimer and the BusyWaitTimer start their own background thread with priority AboveNormal. The thread priority setting might become an input pin in the future.
So now download latest alpha, enable the Experimental button in the VL node browser and give it a shot. If anything unexpected happens, let us know in the forums.
HEY we got news!
we will have vvvv beginner's courses in
Berlin, London, Saint Petersburg, Athens and Linz this summer!
In 6 days, these courses will give beginners a solid grip on vvvv basics and interactive tech.
previously on vvvv: vvvvhat happened in February 2018
we did it!
beta36 is out, after only a few months overtime, packed with new features. please read the release notes carefully to learn about all the goodies. judging by the >100 downloads a day and not too many crazy bugreports since, i think it is fair to say at this point that it turned out well. if there is still a particular reason you're using an older version, please make sure to let us know about it!
are you into computer-vision? wanna see one particular thing you can do with beta36? check out our first episode of vvvvTv in which we cover a new computer-vision library for vl available as a prerelease now.
planning your summer travels? save the date for LINK - the vvvv summercamp!
and a new book it out about learning vvvv: it is in chinese. so only the majority of people on earth now got a chance to get in touch with vvvv, horray! many thanks to the authors for their dedication!
|two new ones by new user Bartuc, welcome!||and updates by our trusted gang:|
all not good enough? check out these job boards:
Who david, a a a a, joreg, sebl and hopefully you
When Wed, Aug 8th 2018 - 10:00 until Sun, Aug 12th 2018 - 23:59
Where At a peaceful lake near Berlin, somewhere near nowhere, Germany
We're planning to spend some good times.
Save the date for LINK, the very first VVVV summer camp.
The summer camp will take place from August 8th to August 12th this year at a wonderful and peaceful sight near Berlin. The camp will be a short vacation from your everyday life, a time for ideas and projects you never found the time for.
You are willing to bring your ideas and developments and this communtiy further? Then this is the place for you!
Nota bene: There will be only a super limited amount of seats available. The summercamp is not like an academy or workshop. You are not coming to learn. Here you are coming to share and spend quality time together while bringing forward your developments and ideas for future developments.
Expect 5 fantastic days at the lake with tents, barbecue, wine and overheating notebooks.
So save that date now.
Details on everything and how to apply for it will follow soon here.
we're starting to collect the fruits of our hard efforts of making it easy to use thirdparty libraries. please give a warm welcome to VL.OpenCV
remember the amazing ImagePack initiated by @elliotwoods years ago? VL.OpenCV is essentially the same, only for vl: a collection of nodes for computer-vision tasks based on the industry standard library OpenCV.
OpenCV is a vast library with an endless number of interesting features. elliot back in the days did a great job in hand-picking some of the most interesting ones and wrapping them into easy to use nodes for evvvveryone.
meanwhile OpenCV has progressed and so we thought we'd give it a try and make it accessible for everyone in vl. watch this first episode of vvvvTv where ravazquez who has been working on this for the past 2.5 months, explains how you can use the prerelease package today.
if we haven't missed anything, most of the functionality you know from the ImagePack should already be available, except some special video input devices, StructuredLight and FeatureDetection stuff but on the other hand already much more:
so we have:
and most of the nodes and pins come with documentation in the tooltips!
as opposed to the ImagePack, this library is completely free of the complexities of threading. instead a user can use the threading regions of vl to define their own threading. while this indeed puts a bit more effort on the user we hope that the flexibility in dealing with their own threading outweighs the cons of this.
the library is open for everyone to contribute. since it is mostly done in pure vl, with hardly any c# written, it is quite accessible for everyone to extend. so please do so and best join us in the chat to discuss matters when they arise.
anonymous user login