» 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

Newsflash!

Here are two new little features we want to make sure you're aware of. Not completely finished but already helpful:

StepByStep

Press F6 to pause and step through your patch one frame at a time. Press F5 to continue running the patch.
F6, F6, F6, F6, F5

Note how the Quad (topleft) indicates run/pause. Tremendous you say? Indeed, but beware the following caveats for now:

  • this works only for vl, so if you have parts of your patch in vvvv, those will still continue to run as usual!
  • tooltips don't work in this mode yet, so you'll need IOBoxes wherever you want to inspect values
  • no stepping through slices of loops

Still you'll see that in cases where you're looking for a logical problem in your patch it is already useful to be able to step through its execution one frame at a time to better understand how it is evolving.

JumpToError

Set RuntimePauseOnError to TRUE in the settings in case you want to have the patch paused in case an error occured.
Pink: the node that threw the runtime-error.
Bright: the call stack, leading up to the error.
Dark: nodes not executed.

This can be useful when you're on a debugging spree and expect an error to happen at some point. Activate this option to be brought to the point where the error occurred, the moment it happened. Saves you some navigation and highlights the nodes involved leading up to the error. Again press F6 to step or try F5 to get the patch running again after you solved the problem.

Caveat: Look closely, the error message in the tooltip actually belongs to the Add of the Dictionary. The reason for that is code-optimization which sometimes leads to the error-indicator being one node off. A setting to disable code-optimization is pending..


As mentioned, both features are not finished but are a first step into the direction of better debugging support. Still more to come..

joreg, Tuesday, Dec 19th 2017 Digg | Tweet | Delicious 6 comments  

NEWS!

If you're writing your own dynamic plugins in C#, we got something for you! If not, still read on, so yo know, just in case..

The C# language is evolving all the time with nifty features. In order to be able to use those, you need a suitable compiler that understands those. So far, the C# compiler included with vvvv only supported language features of C# versions lower than 6. But no more:

Latest alphas suppport all features new in C# 6.


image grabbed off the internet

Caveats:

  • You need to have either Visual Studio 2015 or MSBuild Tools 2015 installed
  • You have to enable the new compiler by using the commandline parameter /cs6 when starting vvvv
UPDATE:
This is now activated by default for everyone even without the caveats as mentioned above!

So get yourself a fresh alpha now and do yourself a favor by using those new language features.

joreg, Thursday, Nov 30th 2017 Digg | Tweet | Delicious 3 comments  

101 Tutorials

By using Firmata it was always easy to control LEDs, Motors, Relays,.. and to get data back from a bunch of Sensors.

Now it is also easy to get started if you are completely new in the field.
Check these basics tutorials in your vvvv folder:

 girlpower\VL\IO\Firmata\00_Basics\
Getting data from an analog sensor. As easy as that.
Getting data from an analog sensor. As easy as that.

Fixes

  • Talking via I2C protocol to your digital sensors is fixed and should be rock solid now. This example shows how to configure the ADX345 accelerometer and get its data:
 girlpower\VL\IO\Firmata\00_Basics\06-I2C.v4p

The Basics tutorials and fixes are now available in Alpha Builds.

Previously on Firmata:
Firmata Second Service

robotanton, Thursday, Oct 5th 2017 Digg | Tweet | Delicious 1 comments  

finally,

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.

Using .NET Libraries

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:

  • you know of a functionality that comes with .NET standard library... simply go to your document > Dependencies > Files > Add .NET Framework Assembly, choose the assembly the functionality you're looking for is in and boom: you can now browser that assembly via the nodebrowser
  • you find a .NET library you want to use on the internet orhttps://nuget.org... download it, go to your document > Dependencies > Files > Add Existing... choose the file and boom again: browsable via the nodebrowser

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.

Writing Nodes in C# or F#

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

public static float Add(float input, float input2)
{
   return input + input2;
}

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.

Still Missing

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?

No.

Here is the full workflow that we're aiming at:

  • Save package from VL editor
  • Upload package to nuget.org from VL editor
  • Search and download package from nuget.org via a packagemanager (similar to VPM)

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!

joreg, Friday, Sep 29th 2017 Digg | Tweet | Delicious 3 comments  

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:

  • Tokenizer (Raw FixedLength)
  • Tokenizer (Raw LengthPrefix)
  • Tokenizer (Raw Postfix)
  • Tokenizer (Raw Frame)

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:

  • Spread: take the spread as is
  • Discard: take the last slice of the spread
  • Enqueue: take the new Enqueue (Raw) node, which collects incoming spreads of raw and always only returns one of the collected slices per frame
Classic scenario tokenizing by CRLF as postfix. Easy.

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:

  • PrefixLength (Raw)
  • PostfixBytes (Raw)
  • FrameBytes (Raw)

What the VL?

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.

Elegantly tokenizing Firmata with VL

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.

joreg, Tuesday, Aug 22nd 2017 Digg | Tweet | Delicious 0 comments  

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

VVVV

  • All Editors from the editing framework have a Gizmo manipulator.
  • Links will be drawn red when the pins don't match anymore. Invalid links are stored in patches so that they can be reestablished when they match again. This should be helpful for dynamic plugin and VL development.
  • More love for enums: enum spread shuffling nodes finally behave as wanted, GetSlice added, simplified internal encoding. s/r nodes performance restored

VL

  • You can search inside patches (Ctrl+F) or across all the currently opened VL documents (Ctrl+Shift+F)
  • The whole document structure can be browsed with the new solution explorer (Ctrl+J)
  • The default patch type "Patch" is now called "Process" and all patches types in the category VVVV are now picked up as nodes inside vvvv (previously only "Class" used to work)
  • Unified user interaction - double click always opens node browser, right click always opens context menu
  • Links will now snap to pins

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

Download

64-bit
vvvv (35.7_rc5)
addons (35.7_rc5)
32-bit
vvvv (35.7_rc5)
addons (35.7_rc5)

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.

Elias, Saturday, Jun 17th 2017 Digg | Tweet | Delicious 9 comments  

Dear pointmovers,

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.

  • Press 'g' to turn a Gizmo On/Off
  • Pick and drag its handles to transform the points
  • Hold 'Shift' for uniform scaling
  • Nudge points with arrow keys

The Gizmo is working in both DX9 and DX11 worlds.
See Editor's helppatches.

Nothing more to say.
Easy.

Available in the latest Alphas.

robotanton, Wednesday, May 24th 2017 Digg | Tweet | Delicious 2 comments  

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.

New VL nodes

Also try out some new goodies that you can find here:
XML and JSON
Event based MIDI
Reactive Programming
And even more: Change Log

Temp file issue

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.

Download

64-bit
vvvv_alpha35.5_x64_rc4
addons_alpha35.5_x64_rc4

32-bit
vvvv_alpha35.5_x86_rc4
addons_alpha35.5_x86_rc4

tonfilm, Thursday, Apr 13th 2017 Digg | Tweet | Delicious 7 comments  

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:

André Staltz said

Reactive programming is programming with asynchronous data streams

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.

Processing events

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.

Refresh web data every 30 seconds in the background and pass the result on to the mainloop.

You can switch or merge event sources:

Switching or merging midi events.

There are also filtering options with OfType or Where:

Only get TouchDown events from a combined event stream

Other nodes include Skip, Delay, Delay (Selector), Scan, Switch, ...

Receiving events

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:

Three ways to get event values to the mainloop.

Creating events

It's also pretty easy to generate event sources of your own:

Different ways to create observable event sources.

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.

Observable<Observable<T>>

Yep, totally possible and has useful applications. But i am just gonna let this idea sink in for now...

Further reading

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

For coders:
Introduction to Rx

tonfilm, Thursday, Apr 13th 2017 Digg | Tweet | Delicious 12 comments  

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.

Modularity

Instead of having all settings on one node, functionality is now separate to allow arbitrary combinations.

Devices

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:

Driver list updating on connect/disconnect of a device

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.

Route all messages from in to out
Message Filtering

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:

Only let messages on midi channel 0 thru
Message Handling

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.

Create a channel message and read its content

Event Based Processing

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.

Handling midi messages in a custom patch as they occur

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.

Events vs. Mainloop

To Mainloop

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:

Getting the value of midi controller 7 directly

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.

From Mainloop

If you want to generate midi messages in the mainloop you also have a simple node that generates controller message events:

Sending controller 7 on channel 0 on value change

For other messages use the Reactive nodes ToObservable which create an event source that you can use to send events from the mainloop.

Spreading

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.

Filter messages of channel 0 or channels 0, 3 and 5
tonfilm, Thursday, Apr 13th 2017 Digg | Tweet | Delicious 15 comments  

anonymous user login

Shoutbox

~5h ago

guest: uno|https://platform.uno/

~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

~8d ago

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

~8d 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!

~8d ago

~8d ago

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

~9d ago