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.
this is basically where we'd hoped to have been for NODE17: Have the new "node importing" feature in a state where we're quite confident with its workflow. We had it working already enough to demo at NODE as elias did at the keynode and we used it in the VL Nodes and Libraries workshop. But only now it is in a shape that we can talk more widely about it and actually recommend you to try it out for yourself in latest alpha builds.
To create a node for vvvv, always someone has to write some code. In the beginning it was only us who could do that. With vvvv vvvv40beta16 we introduced the PluginInterface that allowed everyone to write their own nodes.
For vl we came up with a new feature that now allows everyone to simply use operations available in a any .NET library as nodes without the need for vl specific coding. This means access to an endless number of nodes at the expense of only a few clicks. Big? Huge!
Two common scenarios are:
As good as this sounds and actually works in many cases, there are cases where using thirdparty libraries directly like this has a few peculiarities, stemming mostly from the fact that those libraries are usually not made to be used in a dataflow scenario like VL. For details, see the gray book on Using .NET Libraries.
Now that we can use any code from thirdparty libraries we can obviously also write our own nodes for VL, basically using any .NET language (so far we've tried with C# and F#). And the good news here is that it is dead-simple. While a plugin-developer for vvvv needs to follow the PluginInterface, ie. have some understanding of vvvvs workings, writing a node for VL requires no VL specific knowledge!
The simplest node you can write in c# looks like this
Build that into a .NET .dll and then simply use the library as mentioned above. For more details and example projects for C# and F# see the gray book on Writing Nodes.
Thankyouverymuchthatwasabouttime I hear you say and whatabouttherest?! Right. Now that creating nodes and libraries for VL is so trivl, obviously everybody will start doing it like crazy and we'll hopefully end up with a lot of nice packages and contributions soon. So how do we expect to handle those? Collect them in an addonpack again? Upload everything to the Contributions again?
Here is the full workflow that we're aiming at:
Sounds simple enough, but believe me for once, if you're looking at the details, this includes unsolvable problems (think package dependencies, versioning). Don't want to bore you with the details, just want to say, we're at it but as always, it may still take some time...
So now go ahead, use your favorite .NET libraries like a pro and hit us in the forum if you encounter any troubles.. Even if you don't encounter any troubles we'd love to hear about what you're working on. Try the new forum category WIP for this!
Dear jugglers of the bytes,
sorry this took so long! Almost five years ago we introduced the new datatype Raw for easier handling of byte streams in vvvv. It came with all the nodes you'd need, except probably the most important one, a Tokenizer. So for collecting incoming bytes via e.g. TCP or RS232 and making sure to separate them into the correct message-tokens you'd still have to fall back to the good old Tokenizer (String). Possible, but annoying.
Enter the new series of Tokenizer nodes:
Users of Tokenizer (String) may remember that it was always a bit tricky to configure since it had quite a few options to configure it and you'd have to make sure to get those all right for your specific use-case. So now we've separated those use-cases and spent each of them an individual node. The nodes versions should be self-explanatory. If not, they all come with help-patches!
Now all of the Tokenizers always return a spread of tokens found in the last frame. So in order to simulate the Queue Mode of the original Tokenizer (String) here is how you do:
Also, on the other side, if you're in the business of sending out a stream of bytes here are the counterpart nodes to frame your messages accordingly:
Of course. All patched in VL and even more practical to use over there because (once again) datatypes and delegates. The Tokenizer in VL is much more primitive in that it only collects all incoming bytes and then executes a delegates on the buffered bytes. The delegate allows you to easily implement more complex scenarios than the four preconfigured ones mentioned above.
The Firmata protocol for example fits non of the above mentioned simple cases as it has different types of tokens. Still the basic Tokenizer can be used to implement the firmata peculiarities on top of it. Further the delegate allows you to return the tokens already in your desired datatype. So instead of returning a Spread<Spread<Bytes>> as the Tokenizers in vvvv can only do, in VL it can readily return a Spread<MyToken> which is just so much more modern..
If you feel anything missing here or have any questions, please let us know in the comments!
The nodes are now available in Alpha Builds.
My dear vvvv users,
we've scheduled beta 35.7 for release at the end of the week. To make it as polished as possible here comes a release candidate for you to tamper with. Download it, try it and report any findings in our forums.
Also note that this release will be the last one before NODE17. So workshop hosts especially should have a look at it whether or not everything they need is in there and working.
The noteworthy changes are
For an in depth list of changes have a look at the changelog.
This release is intended to be the last one of the beta 35 series. We changed plans a bit and deliberately kept the rather big internal feature branch (which allows you to drag'n drop .NET assemblies onto the patch) out of this release as it will need a longer testing period in the alpha build channels.
from now on you can translate, rotate and scale way more faster.
There is a Gizmo for that.
And every Editor in our EditingFramework has it inside.
The Gizmo is working in both DX9 and DX11 worlds.
See Editor's helppatches.
Nothing more to say.
Available in the latest Alphas.
As you may have noticed, we are back in our every 2 month release cycle and a new beta is up on the horizon.
As we have noticed, not many of you use alpha builds to test it against your latest an greatest projects. So here is a particular fine alpha version that is our release candidate for beta35.5 scheduled for Monday.
Please give it a test run with a few patches and send us reports on any bug or problem you encounter. Testing is also the perfect excuse to miss any Easter obligation.
Some have reported that they are seeing ~temp files being written on save. We could not reproduce the error here, but we have now an error pop-up to inform you when something goes wrong and the exception that caused the problem will be copied into the clipboard. Open the projects that have that issue and paste the exception message into a new forum thread to help us tracking it down.
Here is something really great. The new Reactive category gives you tools to handle asynchronous events, background calculations and even enables you to build your own mainloop that runs on a different CPU core. But let's start with a pragmatic explanation of what it is:
In a way, this isn't anything new. Event buses or your typical click events are really an asynchronous event stream on which you can observe and do some side effects. Reactive is that idea on steroids. You are able to create data streams of anything, not just from click and hover events. Streams are cheap and ubiquitous, anything can be a stream: variables, user inputs, properties, caches, data structures, etc. For example, imagine your Twitter feed would be a data stream in the same fashion that click events are. You can listen to that stream and react accordingly.
On top of that, you are given an amazing toolbox of functions to combine, create and filter any of those streams.
Since a while VVVV and VL use these so called Observables to handle external events (i.e. mouse, keyboard etc.) and asynchronous data. This was mostly under the hood and the actual operations for observables are hidden in the VL.DevLib. The reason is that out of the box the operations do not go well together with the frame based Update concept of VL because they are intended to be called only once or when something has changed. But as of now we have wrapper nodes for the most common observable operations that do exactly that, listen for change and only rebuild the observables when necessary.
The go to node for handling events is definitely ForEach Region (was Region (Stateful) in earlier versions) in the category Reactive. This region allows you to place any node inside and can also remember any data between two events. There is also one with version Keep that can filter out events using a boolean output. This region is very similar to the ForEach region for spreads, only that its input and output is event values in time instead of slices of a spread.
You can switch or merge event sources:
There are also filtering options with OfType or Where:
Other nodes include Skip, Delay, Delay (Selector), Scan, Switch, ...
If you want to leave the observable world and pass event values to the mainloop use one of the 3 nodes HoldLatest, Sampler or S+H which all behave a little bit different. Depends on what you need:
It's also pretty easy to generate event sources of your own:
As a general advice, only send values of type Record as event data because they are thread safe. If you send values of any Class type be sure that you know exactly what you are doing.
Yep, totally possible and has useful applications. But i am just gonna let this idea sink in for now...
The above just scratches the surface of whats possible with the reactive framework. If you want to know more browse some of the following links:
The pragmatic Rx expert from the quote above:
2 minute introduction to Rx
Visual explanation of the observable operations:
Operator Reference with marble diagrams
Videos from the creator team. Note that IEnumerable is called Sequence in VL and Spread is also a Sequence:
Erik Meijer: Rx in 15 Minutes
Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 1
Erik Meijer and Wes Dyer - Reactive Framework (Rx) Under the Hood 2
Introduction to Rx
Midi was released in 1982 and is one of the most successful hardware communication protocols in the world. The simple nature of the protocol makes it easy to implement and even more important, easy to understand for humans.
This makes it a perfect example for the first event based library in VL using the MIDI-Toolkit developed by Leslie Sanford.
Instead of having all settings on one node, functionality is now separate to allow arbitrary combinations.
Device nodes have an enum input for the input/output device driver you want to use. You can have many of them, even for the same driver. Under the hood they will share the actual device driver resource. The driver is opened only if it is necessary, for example if there is an event sink listening to it.
The dynamic device enum will update as soon as a midi device is connected or disconnected to the machine. So no restart required on configuration change:
MidiIn has one observable output for all midi messages received on the given device. MidiOut has one input that accepts an observable to send midi messages to the given device.
Following the midi message structure, there are filters that allow you to select only the messages you are interested in. For example only midi clock messages, or messages on a specific midi channel:
For all midi message types there are specific nodes to read the message content or construct new messages. These are mostly the native methods of the MidiToolkit library.
You can process a midi message (in fact any event) directly as it occurs. The new ForEach region in the Reactive category executes it's patch for each event that is passed in and can transform the event into a different message type and decide whether to pass the current event on via the Keep output.
This is part of a bigger programming paradigm that was also polished for the new midi nodes. Definitely check out for the blog post on Reactive Programming.
At some point all async input event handling in the background will be over and you want to leave the observable world and have the processed values in the main loop. For that there are several options:
For supereasy controller value input there is ControllerState or NoteState:
For more advanced scenarios refer to the Reactive nodes HoldLatest, S+H or Sampler which provide ways to pass event values safely to the mainloop.
If you want to generate midi messages in the mainloop you also have a simple node that generates controller message events:
For other messages use the Reactive nodes ToObservable which create an event source that you can use to send events from the mainloop.
Since VL makes a difference between a single value and a spread of values, some nodes come in 'plural' version to allow listening for example for multiple channels at one.
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,
anonymous user login