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.
one of the more basic things any programming library has to support is parsing and the creation of XML data-structures. since vl is based on .net we don't have to invent anything here but can make direct use of .nets XDocuments, XElements, XAttributes datatypes. so we're happy to announce that in cooperation with dominikKoller we added xml/json support for vl:
so basically anything you could already do in vvvv plus some more. and this is only what we brought to the surface for you. using the underlying .net datatypes (XDocuments, ...) directly, a pro-user will (later) easily be able to use the whole range of functions that those datatypes provide for more advanced use-cases.
so, once again, something for the whole family..available in latest alphas now.
Pointmovers of vvvv!
The Editors got some new features.
Stepping through the points via Keyboard
Marquee selection in a Bezier Editor
Support for DX11
The Editors by itself are graphics-engine-independent, but their points, lines and handles must be rendered. From now on there are DX11 Views for every Editor.
Available in latest Alpha builds.
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:
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.
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:
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,
previously on VL: vl-progress-report-4
the vivid blog reader already knows the drill: everything stays the same if you liked it just the way it was.
Specify remote host (IP address), a nice port number, connect some data and bang the send to let your UDP packets travel over the network. Or open a server to receive bytes arriving on the specified port. The only difference to vvvv you might see is, that here you also get infos about the sender of the packets via the Remote Endpoint output (which is an IP Address and a port)
same same for the TCP nodes: The client will try to connect to a server. And once the connection is established, you can send and receive bytes.
The TCP Server awaits incoming connections to talk to. The subtle difference here is the Tuple input, where you would expect the data pin. No one ever requested it, but now you can decide which packet should be sent to which client by specifying IP address and port together with the message. In case you still want to send the same packet to all of your clients, just set the address to 0.0.0.0 and port 0
so why did it take so long, what's the goodies behind that?
Unlike the monolithic networking nodes in vvvv you can peek inside the VL ones. The goal was modularizing on a much lower level to be able to provide the very basics as nodes for the patcher:
Good news everyone, from now on you're getting a brand new node able to talk to your loaded-with-firmata Microcontroller Boards (like Arduino, Teensy, Particle.io, ...):
Hardware for the development was kindly provided by QUADRATURE.
Oh, by the way, these new Firmata nodes are fully implemented in VL.
And of course there are some caveats.
The nodes are now available in Alpha Builds.
This is a rework of the original release of 'Arduino Second Service'.
See the previous (now outdated) blogpost.
this little feature upgrade for both vvvv and vl has been lingering around the alphas for a year already...
do you (have to) create touch applications with vvvv? then read ahead:
Pan, Zoom, Rotate, TwoFingerTap and PressAndTap touch gestures are now handed over to you via the GestureDevice. As expected they're multitouch capable, so they report an ID, the position, the distance (Pan & Zoom amount) or the Rotation, and a device ID (in case you have multiple monitors hooked up)
As with the Touch nodes, these also rely on the windows message loop. so touchscreens with windows capable drivers required. fortunately most screens do have these nowadays...
check the helppatches for a microdemo
hope you like it,
previously on VL: VL: Many Paths Lead to Rome
so while the features are freezing we're still cooking the bytes on a low temperature to get them all smooth..
Finally we took the time to do a few performance tweaks on the UI. Not perfect but quite an improvement to what you've seen so far. Selecting nodes and moving them around is now definitely at interactive rates. What you'll still see is that your animations are interrupted while handling the patch. While this might be annoying in the first version of the VL integration, we have worked on the foundations for a non-blocking approach. So expect that to improve in the future. Just not now, priorities are to make everything work first.
Previously all VL nodes which do time based calculations had to have an input pin for the time per operation. The default value for the Time type was set per frame by the VL runtime.
This is now different: You can make a Clock or a FrameClock input on the Create operation of your patch or type and store the clock in a pad to access the time in the other operations. This prevents you from making time inputs for every operation. The default value of the Clock if nothing is connected is the VL runtime frame clock.
The Clock type is very simple and only has a Time property.
The FrameClock has a additional property TimeDifference which holds the delta time since the last frame. This saves you from calculating the delta time everywhere on your own.
If all goes well we'll see the beta35 (including VL as a first class patching language) release soon™ and with it we're entering phase 2 where we'll actively try to convince you to have a look at VL and actually start using it for your projects. At the risk of repeating myself.. this should be done by updating the gray book and providing a couple of introductory video tutorials. And then the world...
If you want to get started with VL right now, here is what you do:
If you want to let us know that you like anything you just read...we're always up for a comment or even a flattr:
after let-me-present-to-you-file-io, here comes another thou shall not be afraid
the last post demoed reading and writing files... but the shown iobox with the filename inside actually gracefully skipped the part on how to get to your file. so up above you see the set - well known to any vvvv user who - which takes care of handling directories, files, folders, paths,...
guess, no need to say much about those. Watcher and File/FolderDialog are of course non-blocking and Copier and Mover do their work asynchronously in the background.
VL extends the behaviour of vvvv string ioboxes a bit. in vvvv you could open up a folder or file selection from the iobox directly. you can again do that, of course. however, the system now knows about Paths, which is more than just a simple string. sounds a bit academical, right...
the nice thing about this Path Type is that everything feels more like file handling in the explorer
For a complete list of changes between Chromium 33.0 and 54.0 have a look at the official development blog of Chromium.
Advanced features like WebGL, Flash, PDF rendering etc. should all be working, but compared to Chrome itself playback of H.264 encoded video files will not work because we do not have a license to ship these proprietary codecs. For a more detailed discussion have a look here.
In case you need to support these codecs you'll have to build the exact same CEF version we're using (3.2840.1513.gf7effc7) on your own (with set GYP_DEFINES="proprietary_codecs=1") and replace our shipped CEF files with those of your custom build.
As always the node can be tested using our latest alpha builds.
There's been a plugin programming feature request by VVIPP vux to get a custom node pin that could also accept value/color/string/transforms which got resolved a while ago. As there were no further complaints about the way it got implemented in the API we now will commit us to the following changes:
later on you then can ask for a handle on the data via:
See "girlpower\VVVV Plugin API\VariantPins" for an example for a Switch that is connected to colors, strings, values and whatnot at the same time.
original request: https://discourse.vvvv.org/t/plugin-interface-feature-request/12639
anonymous user login