» 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

helohelo,

here is a supasmall thing. But it can be supausefull. So i thought you should know rightaway: We're all familiar with noisy signals coming from sensors and the simplest thing in vvvv to do to calm such a signal always was to use a Damper (Animation). But of course that introduces a lag, which is sometimes unwanted.

Enter the 1€ Filter: A Simple Speed-based Low-pass Filter for Noisy Input in Interactive Systems
All credits to its creators: Géry Casiez, Nicolas Roussel, Daniel Vogel and Mitsuru Furuta from which we borrowed the C# implementation.

Available now with more details in the helppatch in the latest alpha.

joreg, Thursday, Dec 4th 2014 Digg | Tweet | Delicious 13 comments  

helo nerds,

this is the second in a series of blogposts about our forthcoming nextbigthing that we still call vvvv50 (50). If you haven't already done so please first read the last issue with the title:

All information given here is still preliminary and subject to change.

Now here is the first real treat. We're starting with a simple one: Colors, or how we like to call them: Operations.

First here is a bit you may not have been aware of: When in vvvv45 (45) you create subpatches this is actually only for your own sanity. vvvv itself does not see those but only deals with all your nodes as if they were in one big patch. So in 45 every cascaded system of patches can actually be seen as only one very big patch. And even more so actually everything together can be seen as one big function/operation that is executed every frame. Quite shocking, innit? In 50 this is very different in that the visual structure has actual meaning to it. Good news: You can keep your assumptions, only now they will really work out.

Defining Operations

As an example let's have a look at two patches in 45 which are called "PointIsWithinCircle" and "PointIsWithinRectangle":

Two 45 patches defining one operation each.

So here each of the two operations is defined and saved in a separate .v4p file. In 50 they look basically exactly the same only that they can also be defined together in one patch like so:

One 50 patch defining two operations.

And you really can collect any number of such helper-operations in one patch by just selecting a group of nodes and giving them a name. Like this multiple operations can be saved in one .vl file. Now this is obviously cool on the one hand but you may also immediately think of scenarios where this has more implications (think: project structure, versioning,...). But let's not ruin the party with such thoughts already. So anyway you just learned that in 50 a patch can be a container for defining more than one operation. Easy.

Having a closer look at the 50 screenshot you see something you haven't seen before. People call those things "Colors" and while they are basically evil, when used in the right way they can actually be quite helpful. Here we use them to visually distinguish between different operations in one patch. You may argue you'd not need colors for this because the operations are all placed next to each other anyway. Indeed, but note that this is really just the most simple case. Think of multiple operations in one patch exchanging data (via links) between each other...we'll come to that in a later blogpost.

For people familiar with c# here is a transcription of the patch that you see:

static bool PointIsWithinCircle(Vector2d point, Vector2d center, float radius)
{
  //implementation
  return output;
}
 
static bool PointIsWithinRectangle(Vector2d point, Vector2d center, Vector2d size)
{
  //implementation
  return output;
}

So you also see how 50 clearly translates the signature of such operations to a visual representation with the colored header and footer of the operation resembling the function-header and line of return that are embracing the implementation.

Here is another example of an operation returning multiple results. Again nothing special you're already used to that from 45 only here the colors encompassing the output pins speak a clearer picture.

50 operation with multiple outputs.

Using Operations

You know from 45 that any operation you defined in a patch can be placed as a node inside another patch. Same in 50. Doubleclick a patch to bring up the nodebrowser and select the operation you want to use as a node.

50 nodes with ugly font-rendering.

So all-in-all no big deal right? Only that inch better and finally, colors. Have a suggestion where we would allow users to choose their own colors? Get a life...

...but then also come back for the next article in this series revealing more awesome from the future of programming.

Liked what you read? Insert coin: /downloads|vvvv?.

joreg, Tuesday, Nov 4th 2014 Digg | Tweet | Delicious 18 comments  

It's been a while again since we last dropped news about that next big thing we still call vvvv50 (50). So in order to get the hype slowly started here are some further notes...

All information given here is still preliminary and subject to change.

Now

45 patch
45 patch. cool.

First a quick recap of what we have with vvvv45 (45) so far: For the first ~6 years in existence vvvv was a rather monolithic thing. We sloppily called it "a multipurpose toolkit" and really only later found out ourselves that it was actually made of 4 parts:

  • a development environment (GUI)
  • a visual programming language
  • a runtime
  • a library of nodes

Still very much monoltithic in that there was no way for the user to change any of those. Only when in 2008 we introduced the plugininterface vvvv became more modular in that it allowed users to create their own nodes, and boy they did (->addonpack, dx11-pack, cv.image-pack, ...).

So the library part was addressed but critizism remained:

  • meeehh runtime, we want to be able to run patches standalone
  • meehh cross-platform
  • ufff spreading hell
  • bäähh GUI..

According to the great Joel Spolsky the single worst mistake you can do when writing a software, is starting from scratch. So we did.

Then

50 patch
50 patch. still looking like shit.

So here is our bold plan, this is what we're aiming at (longterm):

  • a hybrid development environment (HDE) that will be able to host visual and textual languages.
  • a topofthepops visual programming language (with features known from c#)
  • a compiler for that visual language (that creates cross-platform executables)
  • a node library (closely modeled after .net)

Now if that sounds familiar as in "so whats the big difference?" then exactly. Instead of saying it will be completely different we can also say that it will be very much the same only much better. People tend to prefer hearing either. We couldn't decide...

Anyway we're at a point with this where we have bits from all 4 parts implemented and can do simple demos. But mostly we're still focusing on the "visual programming language" which we consider the foundation of the pleasure we want you to have with 50.

Language Features

The great thing about 45 is still that it is simple to learn. Say that again..!? No really, if you approach it the right way (arrogant!) it actually is. There is a huge library of nodes that is hard to grasp, true, but the things you have to know about the visual language vvvv are only a few:

  • spreads
  • framedelay
  • send/receive

Those are basically the language features of 45. Specifically the concept of Spreads is what makes vvvv stand out. It allows you to do simple things quickly but as things get more complex they are quite cumbersome to work with. We call this "low-level" while the goal of our new visual language is to be able to work more "high-level", ie. less thinking about concepts that make things easy to understand for the computer but more thinking in human terms.

So with 50 we're introducing a number of new language features that will make it easier for the user to create more complex programs. Here is the buzz of what we have so far:

  • userdefined datatypes
  • functions
  • interfaces
  • generics
  • events
  • loops

Sounds scary? Naa... you'll see, all a breeze. Really the basics are not changing: You'll have nodes and pins to connect, a renderer, a quad, ... nothing new. If you're not using any of the new features you can still work kind of 45-style only then you'll not be seeing any of the productivity-increase you can gain from using them.

Specifically as you'll not need to use them all right away and you'll be using them without noticing anyway. But in order to talk about them we need to call them names.

In a forthcoming series of blogposts we'll show you how working with those features will feel like. If you already like what you've read so far and want to buy the cat in the sack we're always up for a /downloads|vvvv?.

joreg, Tuesday, Sep 30th 2014 Digg | Tweet | Delicious 17 comments  

To you suckers for framed keys,

right into this gorgeous sommerloch we bring to you the initial public offering of our next generation TimelinerSA: a standalone timelining application that sends out its values via OSC and as such a candidate for becoming the successor to the rusty original TimelinerSA.

for now this is not a replacement but more an experiment still.

We started this from scratch for all the wrong reasons. Basically we were looking for a simple application to test our new gui framework Posh and mostly in order to have a real world usecase we decided to start redoing the timeline. So while at this point it is still lacking quite some of the old timelines features it already has some shiny new stuff:

  • undo/redo
  • styling via css
  • remote access via webbrowser

Missing are foremost:

  • more track types (curvy values, color, ...)
  • a node-version
  • grouping of tracks
  • copy/pasting keyframes

and some more, see timeliners issues on github

And as soon as we have the node-version this time it should not be too far out to hope for proper GetTrack/SetTrack nodes for recording values or doing your own evaluating of the keyframes...

For now it still has one major bugger: when deleting a keyframe while hovering it with the mouse everything will freeze. If you get in that situation just press F5 to reload the page. Also big thanks to the patience of all alpha-testers.

Now get it here and in the comments (here) please let us know whats your favorite missing features that makes this thing still useless for you. Hopefully this will let us prioritize further development on timeliner.

If you already like what you see we'd appreciate a /timelinersa|Timeliner?.

Ah and yes it is all opensource: See Timeliner on github.

joreg, Tuesday, Jul 8th 2014 Digg | Tweet | Delicious 9 comments  

Problem

When developing a GUI application you have to decide on a ui-framework for windowing and drawing. Being a .net developer, typical choices would be WinForms, WPF or GTK# for the windowing part and System.Drawing, Cairo, SharpDX or OpenTK for the drawing.

When hoping for a GUI that at some point will run across platform borders WPF and SharpDX are no options anymore. When even thinking mobile you'll have totally different windowing needs anyway and the typical way would be to do the drawing in OpenTK so at least that part is possibly portable and fast. Still you'd have to maintain separate windowing code for each platform.

In an ideal world you'd not want to think about platform specific issues and especially not maintain all the separate codepaths resulting from whatever compromise you choose.

State

Luckily mankind came up with that internet-thing and now that we're quite some years into its long-evoked 2.0 phase it feels like they have mostly agreed on quite solid standards and even have implemented them across the current world of devices. So today we are in this privileged position to only face one platform that is: the browser. If it runs in the browser it runs on any device.

But wait, the browser, that was that java(kiddy)script-thing, right? You'd obviously not seriously want to go down there. So isn't there a way to write a GUI that runs in the browser without writing a single line of kiddyscript? Well of course there is and the fact that you're not the first one coming up with that unpopular idea, it should only give you strength to reinvent the same with a focus on your own needs.

Experiment

Introducing Posh - a flat-ui-framwork that misuses the browser as a windowing/drawing environment for your c#/.net based applications by pushing SVG snippets to it while receiving events from it in return.

posh
Image taken from the internet to attract more people on facebook to click the link of this posting and also to give the text some structure.

Posh exists of two parts:

  • a javascript library: that receives SVG-snippets, attaches event-handlers, inserts them into the DOM and makes convenient RPC-calls back to the application. thats the part you don't have to deal with.
  • a .net library: that takes the SVG-DOM you build in your app and sends incremental changes on it (snippets) to the browser and translates the RPC-calls into regular .net events for your coding pleasure.

So essentially in your application all you do is build an SVG-DOM (possibly even by simply loading .svg files) and react to normal .net mouse/keyboard-events that you can attach to SVG-elements. That means when building your application you don't have to think about anything windowing/drawing related except building the DOM describing your UI. Also styling is completely for free via CSS.

Communication between the browser and the application is realized via the WAMP protocol using the autobahn.js and WampSharp projects. For all things SVG in .net we use the C# SVG library.

Try it

We provide a simple demo-app that should also be a good starting point if you want to create your own posh-based app. Clone Posh and then start

 Demo.WinForms\PoshDemo.sln

to get an idea. If you're interested in a more advanced usecase have a look at Timeliner.

joreg, Tuesday, Jul 8th 2014 Digg | Tweet | Delicious 4 comments  

Inspired by this forum post, the SVG nodes got two new companions which make it easy to render a spread of textures from a spread of SVG elements.

The Join (SVG) node is similar to the Group (SVG) but instead of packing all elements into one SVG group it outputs one SVG group for each slice of the input elements.

If you put an AsDocument (SVG) node right after it, it will create a spread of SVG documents for each SVG element at its input. And since the SVGTexture (EX9.Texture) is also spreadable, you can render a bunch of textures at once.

Please test in latest alpha builds and bugreport as usual.

render on,
devvvvs

tonfilm, Tuesday, Jul 1st 2014 Digg | Tweet | Delicious 0 comments  

The HTMLTexture (EX9.Texture) node is now based on version 3 of the Chromium Embedded Framework (CEF) and available for testing in the latest alpha builds. Thanks to MESO for sponsoring the update.

The update to CEF 3 brings the following features:

But there're also some new limitations we came across in our first tests:

  • Mouse flickers in flash files - see http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=10688 - will probably never be fixed because of deprecation of NPAPI.
  • Our transparent flash example doesn't work anymore - and didn't find a way yet to get it working again. This is probably related to the mouse flickering mentioned above.

We encourage everyone to test the node and report issues as usual in the alpha forum.

Elias, Friday, Jun 27th 2014 Digg | Tweet | Delicious 0 comments  

hola senioritas preciosas y seniores pequeños,

here is an update on our progress with documenting everything we know about vvvv. our documentation taskforce robotanton is busy on two ends:

  • revvvvamping the wiki documentation pages
  • structuring/reworking the \girlpower demo patches that ship with vvvv

Wiki Pages

the Audio and IO sections were reworked last year already but the latter got a new section on Files more recently that should answer many questions regarding how to read from and write to files. the page on all things Strings is new and offering convenient entry-points to topics like unicode, xml, json, regular expressions and more. and also The GUI got a complete facelift while Physics only received minor cosmetic treatment.

Girlpower demo patches

for more than a decade the \girlpower directory shipping with vvvv was a rough corner. undocumented poser-patches showing off stuff that you could do with vvvv if you only understood how.

starting with beta30.2 we thought it may be a good idea to try and explain a bit more and we shipped a new directory called

 \girlpower\The Next Generation

that collects all new carefully documented demo patches. with the beta32 release this directory will be gone and all the good new (and still some of the old) stuff will be available in a new structure closely resembling the wiki Topics.

here is where the new bits are with beta32:

  • \IO\Files
  • \IO\Keyboard-Mouse-Touch
  • \Graphics\DX9\Geometry, Shader, Texture
  • \Strings

and yes, as always, still more to come..

joreg, Wednesday, Apr 30th 2014 Digg | Tweet | Delicious 2 comments  

There are several nodes in vvvv that have a functionality which does not need to know anything about the datatype on which it operates, since the functionality is so meta. In modern programming languages this is commonly known as generic programming.

Some examples are Cons, GetSlice, Select, Queue... They all move around some data but don't really care about which data.

Over the past years some developers programmed generic node definitions and used them in the addonpack, in their own packs or contributions. This is a great thing, but for a new developer its almost impossible to know where they are all hidden.

The latest version of the vvvv-sdk contains a project which gathers all generic node definitions from different places. Every node developer can now reference this project, covert the template files with a convenient patch and get over 20 nodes for his own data type for free:

Generic Nodes

happy coding,
devvvvs<T>

tonfilm, Wednesday, Apr 23rd 2014 Digg | Tweet | Delicious 5 comments  

helo everyone,

here is to give you a little heads up on UI related improvements for the upcoming beta32 release. so read carefully now and don't later say that nobody told ya.

DPI Awareness

most importantly (and as already mentioned before) vvvv is now fully dpiAware meaning that you can enjoy vvvv at any OS zoomlevel which you can specify via

 Control Panel\Appearance and Personalization\Display 

thanks to everyone who bugged us on this one for quite a while and thanks for your testing and reporting.

Touchable

as also mentioned previously vvvv can now be basically operated via touch devices. Please see that older posting for gesture details.

Selection Behavior

as rightfully demanded by dottore vvvv adopted the following new selection behavior:

  • if nodes and links are in a selection only nodes are selected
  • if only links are in a selection they are selected
  • pressing ctrl selects both links and nodes (old default)
  • pressing shift only selects links

so among other nifty options this means that you can now by default select a group of nodes in your patch and delete them without worrying that you'd also delete links which you'd rather keep.

IOBoxes

here is the first feature backported from vvvv50 to 45: inlets (ie in vvvv45 an IOBox that has a descriptive name and is only connected to downstream) have their label displayed above the node for better readability. ages ago this has also already been suggested by urbankind.

IOBox (Node) can now display a stream of raw bytes which was an obvious thing still to come and requested by everyone working with raw data.

IOBox (Value Advanced) now features a new behavior for 'Boolean' valuetypes called Press which returns a 1 for as long as the right mouse button is pressed on it. also requested long time ago by sven.

as correctly pointed out by motzi creating a bool iobox via middleclick was still missing options to quickly choose between Bang, Toggle and now of course Press.

and finally the Bang now has a proper afterglow as asked for by elliotwoods and u7angel here and there.

S/R

as requested by seltzdesign and reaktant Send and Receive nodes (of all types) now show their channel-names in their nodes by default. that will make it easier to navigate patches with a lot of S/R nodes. if you hate that you can still remove the label easily with a middleclick on the nodes. note that this flag is simply stored as a configuration pin called Display Channel on all S/R nodes. also note that when opening <b32 patches you'll have to manually enable this on S/R nodes there we didn't want to mess with your old patches.

Debugging

ever saw your tty spammed and wanted to find which node this is coming from? now hit debug mode (ctrl+f9) and see nodes logging to tty rendered in a different color. while this feature kind of has been there for quite a while it is now really supposed to work. also Renderer (TTY) has a new configuration pin called Show Node Address which even displays the full node-path to the node that is spamming.

so you see all simple stuff hopefully improving ease of use..ah and of course now would be a good moment to test all this in the latest alpha builds and report problems in the alpha-forum as latest alphas already pretty much are what you'll get with b32.

joreg, Monday, Apr 21st 2014 Digg | Tweet | Delicious 14 comments  

anonymous user login

Shoutbox

~8h ago

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

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