» Devvvvlopment Update January 2017
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

Devvvvlopment Update January 2017

previously on devvvvlopment: vl-networking-and-async

With beta35 (including VL) out in the wild and people apparently starting to use it (see forum threads about it) we're quite happy with the feedback so far. We know of people already including VL in their daily patching and getting the hang of it. Others are still more cautious and are waiting for better documentation or are hoping for node17 to open their eyes. All fair enough, no pressure.. in any case the question is of course:

What next?

One of the many aspects that vl will be different when compared to vvvv is its node-library. In vvvv we have a closed-source base-library (written in delphi and closely bound to the vvvv core) plus a wide range of open-source nodes including community contributions (written in c# via a plugin-interface). For vl we'll still distinguish between a base-library and the rest, but all libraries will work the same way, ie not be bound to the core. And not even need a plugininterface. And be open-source.

So from the beginning in vl we separated core from libraries and already have a git-repository including all of VLs libraries organized in neat packages (as you can basically already see in your beta35\lib\packs) that we're ready to open. Why haven't we done so already? Well, by releasing library source-code we're kind of committing to a style that everyone should be able to use to write nodes for vl. Therefore this is really a crucial part that we simply wanted to give a second look.

Jump to 49:55 for: Defining Nodes

Remember when at node15 we teased how to define nodes for vl? Everything already felt fairly simple indeed. The typeimporter, a breeze. As mentioned in previous blog-posts we've been continuously importing libraries ourselves since then and noted a few things that we needed to improve to make the workflow for future library developers even more convenient.

So this is what we're reworking at the moment and what we hope to be releasing soon:

  • the complete vl node library as open-source
  • documentation on how to import/write your own nodes/libraries for vl
  • documentation on how to package your libraries for consistent distribution

This will reduce the barrier for developers enormously because everything they have to do to contribute to the vl nodelibrary, will be very little vl-specific and very close to what any c#/.net developer is doing anyway.

Other than that our focus until node17 will continue to be the integration of vl with vvvv, improving documentation and adding the one or other smaller feature. So, that at node17 we have a strong foundation to teach on and hopefully even already some new, contributed libraries..

Until the next update,
good patch!

joreg, Monday, Jan 30th 2017 Digg | Tweet | Delicious 3 comments  
microdee 31/01/2017 - 01:08

nice! and I hope after node17 vl will be able to move out from their parents' basement ;)

u7angel 31/01/2017 - 13:33

moving out of the basement makes only sense if the bicycle gets some wheels hence DX11 rendering, c# integration and the shader editor. so pretty much what we have now. looking forward to it...

microdee 31/01/2017 - 18:02

it's made in C# you develop for it in C# and then if you don't want to spend too much time in visual studio for some reason it's just a matter of taste what scripting language you implement through the library importer (like IronPython, CSX or Edge.js).
Vulkan or DX12 is a harder nut but both have C# bindings. I vote for keeping it as low level and as close to the actual library as possible. Also I'm against built in editors, atom.io, sublime text or visual studio will always do a way better job. So I'm rather voting for listening to file changes rather than reinventing the wheel.

  • 1

anonymous user login


~6h ago

u7angel: @xxxlalala i meant matcap, look for that

~8h ago

xxxlalala: thanks @u7angel superphong is exactly what i was looking for. litsphere gave me no search results though :(

~10h ago

u7angel: i guess most pro vvvv users don't use emeshe for various reasons but more custom collection of shaders. see superphong or litsphere

~12h ago

xxxlalala: is emeshe the way to go for rendering with materials ? (asking because it says deprecated)

~3d ago

catweasel: Lovely, that did it! Just needed right click which wasn't coming through :)

~3d ago

catweasel: is the tablet plugin missing from recent builds? seems like all 35v(64bit, or is that the problem?)

~3d ago

joreg: ...aaaand here's the full workshop schedule for #NODE17 node17-workshop-schedule #vvvv

~5d ago

joreg: here we go: complete list of 49 workshops for #NODE17 node17-workshops-announced schedule still to come #vvvv

~5d ago

velcrome: @superflysiNZ it is pretty cool, and works solid. but you need #m4l