» 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

Hoi!
I've updated my deployment workflow yesterday solving a major issue which I wonder if anybody else met actually. If you're and you were using vpm nothing changes for you. Except 2-3 more entries in the license agreement page. If you are installing them manually well, you might want to switch to vpm, or edit xml files.

The problem

So the problem was that all my packs depend on md.stdl and mp.pddn which are both swiss army knifes when it comes to dealing with everyday coding issues. So far I just delivered them next to my packs. However this created an issue when 2 packs delivered a different version and vvvv loaded the older one first, it might have broke the pack with the newer version.

Resolution

So I found the simplest way to deal with this is patch the vvvv.exe.config file to look for referenced assemblies in another folder (in this case vvvv\packs\md.core) and put my supporting libraries there. This is what it looks like:

<configuration>
  [...]
  <runtime>
    [...]
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="lib\core;packs\md.core" />
      [...]
    </assemblyBinding>
  </runtime>
</configuration>

This also means my packs won't deliver these libraries with them. I'm improving these libraries as persistent as possible so old API's should stay the same while up to date packs can be guaranteed to use new API's.

During this process I also got rid of the 100 .NET core System.*.dll's you might have noticed them recently, that was just the result of some misunderstanding

So if you're using them, install or keep installing my packs from https://vvvvpm.github.io

microdee, Tuesday, Sep 4th 2018 Digg | Tweet | Delicious 0 comments  

previously on vvvv: vvvvhat happened in July 2018


what a summer...

you missed link? well..you were missed too. so what happened? basically: patch, lake, food. to get a bit of a glimpse, check the final presentations of the focus groups.

next chance to meet your fellow patchers in the realworld is our 4th berlin vvvv meetup on september 5th.

we've still not released our candidate for beta37 since we had a few buggers to fix thanks to your feedback. if no unexpected events occur, this should drop really soon now.

and the latest big news is that we've announced to have started work on a 3d-pack for vl with all bells and whistles. it is a lot of fun to play with and looking really smooth so far. if all goes well, we should be able to show something before the end of this year...

if you're looking for a job, check this announcement by intolight.

Contributions

we got one new contribution this month:

and then, as a direct outcome of a discussion at link, to boost the "work in progress" section on our forum, there are a lot of new things to find here, mostly for vl. again, the idea is to show what you're working on early, even before you have something useful to share. like this we're hoping to prevent that folks start working on the same things in parallel. so be sure to check out these:

and we got two teasers: one and two

Gallery

and a nice little physical game by kbln: Trolleys


That was it for August. Anything to add? Please do so in the comments!

joreg, Monday, Sep 3rd 2018 Digg | Tweet | Delicious 1 comments  

Who david, aaa, joreg, sebl
When Wed, Sep 5th 2018 - 19:00 until Wed, Sep 5th 2018 - 22:00
Where Spektrum, Bürknerstraße 12, 12047, Berlin, Germany

Berlin Patchers.

On short notice:

We're looking forward to have Quadrature giving us insights to their latest and greytest work.

Quadrature is a berlin based art collective. Their works revolves around space: data from space, humans in space, messages from space. The results are kinetic installations, performances, graphics, sculptures (actually anything but video) - and 99% of the time vvvv is at least involved in the making process.... They will show current work in progess, e.g. a new sound performance for the Kubus at ZKM.

As always, feel free to bring your project/notebook/questions or whatever you want to share with the community. We have space and time for spontaneous presentations!

There will be a bar serving us drinks. There will also be other poeple around as well. This time we share the space with the openframeworks community.

Thanks go to Lieke and Alfredo who are running the fantastic spacehttps://spektrumberlin.de.

joreg, Friday, Aug 31st 2018 Digg | Tweet | Delicious 1 comments  

hi there,

beta37 is done - as far as we know. Now, please help us to find out!

Try the release candidate - link at the bottom - by opening the project you're currently working on and see if it opens timely, patching is responsive and everything works correctly. If not, please let us know in the forum using the alpha tag.

Release Highlights

Cleanup and cleanup tools

This one can be understood as a late spring cleaning.

To get the desired appearance in the node browser we at times needed to resort, rename and polish nodes and types without changing much in terms of functionality. There were other examples though where we refined some major bits in the basic node set - e.g. file IO and serialization nodes got a complete rework and just got so much easier to use. And we made sure that the core library feels more explorable just by making basic nodes more visible than others. Advanced, experimental or obsolete nodes now don't hide in different packages but can be opted into the list of nodes, while browsing the library. Within that process, we also polished the node browser quite a bit.

But this release also comes with features for you to clean up. Frames help to structure patches in a visual way, groups, and categories in a structural way. You even can tweak the visibility of your nodes in the node browser and by that distinguish rather advanced or still experimental nodes from the daily node set. Library developers will also love the feature to make certain helper nodes internal so that they are free to change or delete them at any time in the future.

A lighter VL

Startup speed got improved. Also, there are less VL documents open making the navigation menu more meaningful. Let me not begin with the much lighter ".Net Packages" menu or the much lighter download size. Process nodes now opt for mutation which makes them lighter in terms of memory allocation.

Entry points and document management

Together these features allow this workflow:

  • Drop VL documents onto vvvv or VL to open them. They start running.
  • To make them go away use the "close document feature Ctrl-F4" in the VL document menu.

In essence, this allows to do example patches, tutorials or help patches - an essential feature that will make future libraries so much easier to learn. To have a patch start on document load, create a non-generic process called "Root" in the document patch. So again from the end user perspective: no need to create a node in vvvv to see the patch running.

Ctrl-W now behaves like in an internet browser: It just closes the tab - closing the last tab closes the VL window. Ctrl-W doesn't ask you to save the document though. Closing a tab doesn't close the document, it just closes the view onto the specific patch within the document.
If you now managed to hide the VL window use the "Show VL" command in the vvvv main menu to get back into VL.

Debugging

Debugging should feel much more intuitive, as it now allows to inspect the exact state of the patches for the moment when something went wrong.

Some notes on the debugging settings:

  • RuntimePauseOnError: When turned on, allows to inspect nodes and pins above the pink node. You see the values for when the exception occurred. For end users, this feature typically is off. Library developers will likely switch this often depending on whether they're debugging or using their library. Reloading the settings now always should work. No need to restart when switching the setting.
  • RuntimeAutoJumpToError: if the auto panning gets in the way this is the setting to turn off.

You can switch the settings via Quad menu -> Settings -> Open in editor.

Cache region

Actually we never really told you about how amazing the Cache region is. If you have any node that you want to perform better, ask yourself if it wouldn't be enough to only compute it when the input changes and then cache the computed results. The cache region allows expressing this easily. The cache region actually got added with beta36, but now the interplay with other constructs works better.

Loops for example now output their spreads in a way that the changed-detection of a downstream connected Changed node or Cache region only triggers if the slices actually changed from frame to frame.

Some of this stuff may for sure sound pretty special interest, but we have the feeling that these details matter in the end for having an expressive but playful language.

Baby, don’t make me spell it out for you

All in all this release makes VL easier to learn, use and develop for.

VVVV

HTMLTexture now for DX11 and more

VL

VL: Corelib Cleanup
VL: Frame Your Patches
VL: Groups and Categories
VL: Serialization
VL: Improved File IO

for an in-depth list of changes have a look at the changelog.

Download

Release Candidate 6
64-bit
vvvv
addons
32-bit
vvvv
addons
Beware: Make sure you secure your data. Patches saved with an alpha might lead to not being able to open them with the former beta.

gregsn, Friday, Aug 24th 2018 Digg | Tweet | Delicious 26 comments  

Not many will remember the times when vvvv's 3d rendering was based on Direct3D 8. Not important really, because at the same time we released vvvv 33beta1 in December 2002, Microsoft released Direct3D 9 with a lot of new features, so we knew what we had to do..

Luckily vvvv's DX9 implementation proved powerful enough to be quite useful for many years. Then it took Microsoft 5 years to release its successor DX10 which was only available on Windows Vista, which nobody wanted. Also graphic-card adoption took quite a while so we didn't really feel an urge to start working on it right away.

A Gift

A year later in 2008 Microsoft released Windows 7 and with it DX11, which altogether looked more promising. But still a lack of adoption of supported hardware and Windows 7 didn't put too much pressure on us to implement it. Instead we thought it would be smarter to improve the plugin-interface for vvvv to make it easier for users to contribute to the library of nodes.

In parallel we had already secretly started work on our next big thing that would become VL, which we first announced at the keynode during NODE13. Since with VL we've mentioned from the beginning that we wanted it to eventually run across platforms, for us, implementing a new renderer based on the windows-only Direct3D api became less and less appealing.

What happened next couldn't have been more fortunate: besides many other major contributions, using the possibilities of vvvv's plugin-interface, power-user vux took it in his own hands to create a set of nodes for rendering with the features of DX11, which he released on vvvv's 10th birthday in December 2012. And the vvvvorld was a better place.

DX11 for vvvv is amazing, but innovation in the world of computer graphics started moving faster and faster. Despite the magic that DX11 brought, users demanded more and more bling, but all we were talking about was how VL would revolutionize visual-programming, which brought us all together in the first place.

Another Gift?

With the cross-platform goal in mind, for years it seemed the only option was going for OpenGL instead of Direct3D as rendering API for VL. But all those years, following OpenGLs development and stories about bad support by Microsoft and Apple never got us excited enough to just go for it. Meanwhile a new player has appeared as a modern cross-platform graphics API, called Vulkan, but since it is still in its early stages and support for MacOS seems not official yet, again we were reluctant to jump on it.

All the years we knew there would be another option: Instead of using Direct3D, OpenGL or Vulkan directly, we could base a rendering library for VL on a game-engine API that would deal with different graphics APIs under the hood and would possibly have all 3 as back-ends that can be used on different platforms without us needing to worry about it.

While this sounds brilliant, it obviously has other potential drawbacks (out of scope for this post). But also the range of options for game-engines we could have used wasn't too overwhelming. Until recently. Enter Xenko.

Xenko is a universe of its own and as such comparable to Unity3D, UnrealEngine, CryEngine and the GodotEngine. Please check Xenko's propaganda page to get a glimpse of its features.

We've had an eye on this engine for a while already but it being targeted at commercial game-studios would mean that every user of vl would also need to buy a license for it, so again we were hesitating and looked for alternatives.

But what just happened could again not have been more fortunate: The company behind Xenko, Silicon Studio, removed its commercial licensing and released it to the community under the MIT license, which is a very permissive open source license. This would allow us to base a renderer for VL on it without any licensing restrictions.

Xenko and VL

Initial tests look very promising. Within just a few days we were able to patch a little interactive scene and export the project as an executable so it could be distributed via the Steam store and run on a VR device.

Hence our plan is to investigate further in this direction and at the moment we see two interesting workflows between VL and Xenko:

  • a VL.Xenko pack: that would be basically like the VL.Skia pack we've just released
  • Xenko Studio as a host for VL: that would be similar to how vvvv is hosting VL at the moment

For both scenarios what will be important, is a proper library design wrapping the original Xenko functionality into a comfortable set of nodes, similar to what we just did for Skia.

Next Steps

We'd usually not water your mouths before we are more sure about things. But with Xenko just having gone full open-source and looking to build a community of developers and users, we thought it would be a good idea to talk about this now and try to involve you from the beginning.

So if you're curious about Xenko's universe, just head over to its website and see what it has to offer. You can even download and play around with the editor and if you're familiar with C# create a little game with fancy graphics and assets in no time.

Next we'll demo what we've got so far to participants at LINK and start a discussion there. If you're not at LINK please still join the discussion with your thoughts using this thread. If all goes well we should also be able to share our proof of concept sometime after LINK.

So we hope you understand that at this stage it is too early to promise anything but at the moment we are confident to having found the right library for implementing a 3d rendering system for VL. Just as we were happy when we finally found Skia as the perfect library for VLs 2d rendering system.

Meanwhile please help spread the word about Xenko, retweet their announcement and consider supporting their Patreon to help them build a strong developer community.

We'll update you about developments as we progress...

joreg, Thursday, Aug 2nd 2018 Digg | Tweet | Delicious 11 comments  

previously on vvvv: vvvvhat happened in June 2018


Summertime...

...and the patching goes easy. And we have a release candidate for beta37 out! Please take a moment to test it against your latest projects and report any problems in the forum using the alpha tag.

We added two more features to the alphas within the last month:

For the brave we also pre-released the long announced 2d Rendering Engine for VL based on Skia. Note that this is still an alpha-grade release and we are very much hoping for your feedback on it! But this also means that for projects that don't necessarily need 3d-rendering you can now most likely start thinking full VL! Who will show us the first such project?

The 2nd Berlin Meetup has happened and now LINK Summer Camp is coming up shortly. Even if you're not attending, we'd be happy if you participate in the discussions we'll be having there. And maybe you can make it to our next meetup at the lake on August 12th!

Contributions

Two new:

Two updated:

And also one WorkInProgress and a Teaser.

Gallery

Realtime Image Regeneration by eps using [https://github.com/affinelayer/pix2pix-tensorflow|pix2pix

Upcoming

The Wisp collective has an Open Call for their Laboratory in Leipzig, this September.


That was it for July. Anything to add? Please do so in the comments!

joreg, Thursday, Aug 2nd 2018 Digg | Tweet | Delicious 3 comments  

Who david, aaa, joreg, sebl
When Sun, Aug 12th 2018 - 11:00 until Sun, Aug 12th 2018 - 22:00
Where Grüne Hütte, Brandenburg, Germany, Germany

Invitation! Come and spend a day at LINK - the vvvv summercamp.

LINK opens the space and shares the experience on our last day Sunday August 12th.
So we thought, lets have the next Berlin VVVV Meetup right there including family, kids and friends.

IMPORTANT:
Please register for the open sunday on the LINK Website HERE

UPDATE: We reduced the expenses to 10 Euro for the food and drinks.

STAYING OVERNIGHT:
Spend the night withs us and stay overnight. No Problem, bring a tent, we count you for the breakfast on Monday morning then.

Also please share your ride with others. Organize yourself in this spreadsheet

For any aditional information and how to get there please see www.link-summercamp.de
And for the completeness here is the meetup event

Thanks go to Laura and Julia and her family who own the space and share it with us.

david, Sunday, Jul 29th 2018 Digg | Tweet | Delicious 0 comments  

Skia is a modern and fast 2d rendering library. As usual, we stand upon the shoulders of giants when making this functionality available to you: the core Skia technology and the .Net binding "SkiaSharp". The VL.Skia package aims to make all of this functionality available within VL in an easy-to-use high-level node set.

You now can have the first glimpse on it. From the start, it comes with a nice stack of tutorials and example patches. This package is done for vvvvbeta37.

Here is a rough overview of what the key concepts are:


Layers and Renderers

Just like known from vvvv the main idea is that layers can be grouped and can be connected to a renderer to draw them. Most Layers come with a Bounds input OR Position and Size and Anchor.

We offer different renderers:

  • Renderer: this one comes with a window
  • Renderer (OffScreen): outputs an image that can be drawn with DrawImage or converted to an IImage via ToImage. Here is what you can do with an IImage.
  • SVGWriter, PDFWriter: they take a Layer and write an SVG or PDF file to disk
A Layer connected to a Renderer

Paint

Every layer comes with a Paint input. It describes how to draw the layer. This is very comparable to the render states in DX9/DX11.

You can stack the Paint-modifying nodes. Nodes like SetColor would take everything from the incoming paint and only adjust the color.

Stroke sets up some paint properties

Shaders, Filters, and PathEffects are all properties of Paint. 1000 words wouldn't be enough to describe what you can do with them. You probably just need to play with them a bit.

What can I say

Text

Text nodes are also just Layers. You can think of them as text boxes.

Within that rectangular region you now can adjust horizontal and vertical alignment. This is done via properties of Paint. The FontAndParagraph node allows to conveniently adjust several text related paint properties in one go.

You can visualize the text box with the Show Helpers pin of FontAndParagraph.

(See the examples\3_Text for how to do word wrapping etc.)


Transforms

Layers can be transformed. This allows you to patch a Camera. You would then connect your scene to the Camera and the camera to the renderer.

Transforms are not that important as in 3D rendering frameworks as all Layers already can be placed.
Scaling a Layer influences the stroke width. If this is unwanted specify the Size on the layer itself and not via transform node.
Everything scales. Also the stroke

Spaces

We designed the library in a way that it works for different scenarios. Sometimes you would like to think in a normalized space, like known from DX9/DX11. In other scenarios, you want to think pixel- or device-independent-pixel-based.
You can choose the space on the renderer. But you can also combine spaces: With the WithinCommonSpace node you can adjust the space for everything upstream. By that, you could have a game that adjusts its content depending on the size of the renderer and still draw some text top-left with a constant text size no matter how big the renderer is. (See examples\1_Basics\08_Spaces-Overview for more details)

Top Left - Device Independent Pixels

Interaction

Layers in Skia can be interactive. The main idea here is: "What you see is what you want to interact with". So if the layer is interactive, connecting it to the renderer in one way or the other means that it will be drawn AND that you can interact with it. (See examples\5_Interaction)

This part is under construction still.
Button is just a experimental proof of concept node

How to install

In order to use this library with VL, you have to install the NuGet that is available via nuget.org. For information on how to use NuGets with VL, see Managing NuGets in the VL documentation. In short, navigate via document menu to Dependencies -> Manage NuGets -> Commandline and then type:

nuget install VL.Skia -prerelease -Source nuget.org

As long as we don't have an example browser here is how to get them via windows explorer:

VVVVDir\lib\packs\VL.Skia...\examples

Drag & drop an example patch onto vvvv or VL. For closing the example use the X on the renderer or hit Ctrl-F4 on the VL patch.

Happy exploring!

Yours,
Devvvvs

gregsn, Saturday, Jul 28th 2018 Digg | Tweet | Delicious 30 comments  

Serialization in VL has drastically been simplified by introducing two new nodes called Serialize and Deserialize in the category System.Serialization.
Let's first have a look at two basic examples:

Serialize takes any value and serializes it into a XElement while Deserialize does the exact opposite, it takes a XElement and turns it into a value of the requested output type.

As you can see from the screenshot the resulting string is very short and contains only the mimimum amount of data. It achieves that tidyness by only serializing user defined properties, skipping properties which have the default value, making use of XML attributes, putting collections of primitive values into comma separated strings and adding type information only when necessary.

When deserializing the system will try to apply the serialized content on the instance to be created. This makes it very resilient to future patch changes as adding or removing properties and to some extend even changing the type of a property will just work.

Serializers are provided for all primtive types (Boolean, Integer32, Float32, etc.), collection types (Array, Spread, Dictionary, etc.), commonly used imported types (Vector2/3/4, Matrix, Color, etc.) and most importantly all patched types. If a serializer should be missing for a certain type either report it to us or keep on reading to the next section where you learn how to patch (or write) your own serializer.

Paired with the new files nodes serialization to disk is straight forward:

That's basically all there is to know from an end-user perspective. You can try these new nodes in the latest alpha versions.

Writing a custom serializer

Even though VL ships with serializers for the most common types the situation could still arise where a custom serializer has to be written - either because it's simply missing for the type in question or one is not satisfied with the output of the already existing serializer.

Creating a custom serializer consists of two steps

  1. Patching (or writing in C#) the serializer by implementing the ISerializer<T> interface using the advanced Serialize and Deserialize nodes working on the SerializationContext
  2. Registering that serializer using the advanced RegisterSerializer node inside the static RegisterServices operation (more on that in an upcoming blog post)

Here are two screenshots of the above from an example implementation which can be found in the VL.CoreLib/help/Serialization.vl file:

We're looking forward to your feedback.

Happy serialization!

Elias, Wednesday, Jul 18th 2018 Digg | Tweet | Delicious 5 comments  

Dear All.

We and the 25 participants can't wait for LINK, here are some information for everybody on what we're gonna do there.

We went through all applications and clustered the topics the participants want to work on and tried to sort all wishes and tagged them into 6 main topics/areas.

1) Timeline
What we've mostly understood by now is that different use-cases have different timeline or cueing needs. Can we identify recurring scenarios and work towards a modular set of nodes to build custom timelines quickly?

2) 3D Engine
Direct3d, OpenGL or Vulkan, all possible with VL but what does a library of nodes look like for the things we want to do. What's the basics, what's needed, what's a bonus?

3) Integrating Libraries
VL makes it particularly simple to integrate basically any .Net library. There are tons of libraries available. What are common patterns, best practices when importing and wrapping third-party libraries for use in a visual-programming language.

4) Machine Learning
Being the buzz of 2018, ML can be beautifully integrated with visual programming concepts. Libraries exist that can be used, ideas are needed regarding what to use them for.

5) Authoring Environment
vvvv is a multipurpose toolkit, VL is even much more general. Too general for some. What future target groups can be identified, what are their specific needs, how to best work towards those.

6) Realizing Projects
This is a group where everyone works on their personal projects but is interested in sharing ideas and best patching practices, brainstorming concepts and helping each other out.

Please add your thoughts/ideas/interests regarding each of these topics in the forum.
hurray!

a a a a, Tuesday, Jul 17th 2018 Digg | Tweet | Delicious 1 comments  

anonymous user login

Shoutbox

~7d ago

joreg: @beyon too bad. but from now on we have a fixed schedule: every 4th tuesday in the month! hope this helps to plan evvvveryones visits

~7d ago

beyon: joreg: ah, bad timing, I would be happy to attend but I doesn't look like it will work out

~7d ago

joreg: @beyon any chance you can add 2 days to stay? would be great to have you at the (not yet announced) #vvvv meetup on the 23rd!

~7d ago

~8d ago

beyon: I'll be in Berlin July 13-22 - anything interesting going on in that time frame?

~8d ago

~9d ago

joreg: moments later: admin fixed it. back to normal.

~9d ago

joreg: indeed. site broken. hope to get this sorted soon. sorry for the inconvenience.