» 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

previously on VL: VL Summer Update


It may seem a bit quiet around VL on your end but i can tell you our heads get deeper and deeper into what is going to be our next-generation visual programming offering. Before you get the latest infos please read the standard blurb. Too techy?

What the VL?

VL is a visual programming language combining dataflow and object oriented programming. It is compatible with the .net and mono frameworks in that it can consume .net/mono libraries directly and its compiler builds to the CIL.

Notable features include:

  • patch your own types, dynamically instantiate them and manage them in collections (Spread, Dictionary,..)
  • use Generics, LinQ, Delegates, Interfaces
  • asynchronously react to input using the Observer design pattern

VL is embedded into vvvv as a first class patching language and later will be released with its own standalone editor.

Hmmja..probably too techy still..

What happened recently

Library

First here is a little update on whats new in the library. dominikKoller implemented the following devices:

Note that the downloads in those threads are now obsolete since they are now included with alpha downloads.

Then we cleaned up the BezierSegment and BezierPatch stuff a bit that woei had started and moved it from girlpower to library. And we added some random stuff:

  • ArcLength
  • ADSR (time and framebased)
  • Limiter, Trigger, Metronome
  • ArtNet encoder and decoder
  • QRCode encoder
  • Mapping nodes

Of those we wrapped the following for your convenience into plugins for vvvv:

  • EyeTracker (Devices TheEyeTribe)
  • Leap (Devices) quite similar to the extensive leap-pack by microdee
  • ArcLength (2D/3D)
  • Artnet (Network Sender/Receiver) with spreadable subset and universe pins

Check their helppatches for details.

Also there are now FromRaw and ToRaw nodes in VL that allow you to communicate in raw(ie. bytes) between vvvv and VL. Quite some more stuff is in the works in VL that we'll also want to wrap back to vvvv..exciting times..

Nugets

All this preparation of the library took us way longer than expected because about halfway through we decided to give priority to a thing we had initially scheduled for later: VL now has a package management system. It was obvious that we need such a thing since the early days of vvvv but we always knew that it will be a hell lot of work to implement and maintain on our own (think: versioning, dependencies,...). Luckily finally some people came up with a thing called NuGet that Microsoft adopted as the official package managing system for .net. And hey, VL is built on .net...kombiniere..

So essentially now the whole VL library comes as a series of nugets. We have the VL.CoreLib nuget which brings you the most basic stuff and then a couple of nugets like VL.Devices.Leap, VL.Devices.Spacemouse,...you get the idea. In the future anyone contributing to the VL library can create and share nugets. They are versioned and can depend on other nugets and they can be referenced by individual .vl documents. Means: VL has no more monolithic addonpack and no more guessing as to which contributions are missing and where they need to be placed.

In the best future scenario you open a VL patch that has red nodes and VL will check to find the missing pieces (in the correct version) online and simply ask you to confirm to download them with one click. See, if we get this right it potentially solves a lot of problems you were used to in vvvv over the past years.

Can also have this in vvvv? So far we've laid the basis that potentially also vvvv can profit from but that still needs a bit of investigation, so nothing promised yet.

For now we've concentrated on VL and you can see the first results: we're shipping all our nugets with VL, so no dynamic download/update mechanism yet. But still you can already decide to reference individual nugets or not. Read on:

UI

The main navigation got a bit of an overhaul and is now more focusing on the active document. You can now more easily get an overview of all patches in the document and also have a new section to select which nugets you want your documents to reference via a single rightclick.

Please refer to the following two new sections in The Gray Book for details:

Next steps

To repeat our current plan: Get beta35 out at some point early™ next year which will include VL as a serious new language that you can use if you're stuck with vvvv but don't want to use c#. Easyasthat.

And of course at some point we'll let you know how you can build your own nugets. We're just not 100% sure about all the details yet, so please bare with us while we do some more testing on that..

Meanwhile please get yourself excited a bit more. I don't know how you do it normally but here is a few steps i can suggest:

Diving into VL

(Don't be alarmed by the fact that the alpha-downloads are huge at the moment. That'll be improved at some point..)

joreg, Friday, Dec 18th 2015 Digg | Tweet | Delicious 1 comments  

As a vvvv user you are most probably familiar with the node Map (Value). You would use it whenever you have to map a value from one range to another.

For example you want to use a hardware sensor input in the range 0..1000 to control the vertical position of a visual element on the screen in -1..1 range. And since you want to make sure that the visual element never leaves the screen you set the Mapping to 'Clamp':

Mapping in vvvv

So far, so easy.

Mapping in VL

Let's see if we can improve on that in VL.

First we make three important observations:

  1. The Map node does two things, it maps the value ranges and also knows how to handle input values which are outside the input range.
  2. The mapping mode almost never changes during run-time for a particular use case
  3. The specification for both, the input and output range is by Minimum and Maximum (or Center and Width if you use MapRange (Value) ).

So we separated all functionality in VL to gain flexibility in the following way:

Range

We introduced the concept of a Range. Its a simple generic data type that works for every type and has just two fields and two operations:

Range VL Type

If the datatype has the operators +, - and * (Scale) defined, which is the case for numbers and vectors in VL, there are Center/Width nodes that you can use with it:

Range Type Nodes

Range Handling

The mapping mode was a second functionality of the vvvv node and is now a separate story. We have a bunch of nodes which handle an input value that is outside a specific range in a certain way:

Map Modes

Map

The map node itself got pretty simple and just does what its name says, mapping the input from one range to another:

Map Node

Convenience Nodes

Although the above nodes give the maximum flexibility, you would need to patch a few of them together for every use case. So of course we have convenient nodes that should cover most applications.

Since its often needed, the range from Zero to One:

 UnitRange

We made for all nodes a version that takes Minimum and Maximum, one that takes Range and some which work with UnitRange:

 Map
 Map (Range)
 Clamp 
 Clamp (Range)
 Clamp (UnitRange)
 Wrap
 Wrap (Range)
 Frac -> same as Wrap (UnitRange)
 Mirror
 Mirror (Range)
 Mirror (UnitRange)

There is also Mapping and Range Handling together:

 MapClamp
 MapClamp (Range)
 MapWrap
 MapWrap (Range)
 MapMirror
 MapMirror (Range)
 MapDelegate
 MapDelegate (Range)

All nodes are generic and work for numbers, vectors and custom types alike.

Happy Mapping!

tonfilm, Friday, Dec 11th 2015 Digg | Tweet | Delicious 16 comments  

Introduction

While researching for the new VL math library the topic of polar, spherical and geographic coordinates came up. After reading several articles it was clear that there is a common confusion about the angle convention, orientation and naming.

This blog post starts from the official definition in math textbooks and derives the correct implementations in a left-handed coordinate system with y-axis up like the one in DirectX.

Polar and spherical coordinate systems do the same job as the good old cartesian coordinate system you always hated at school. It describes every point on a plane or in space in relation to an origin O by a vector. But instead of 3 perpendicular directions xyz it uses the distance from the origin and angles to identify a position.

Conventions

In the following descriptions the angle units are degree and the cartesian coordinate systems and drawings are the ones you would find in math textbooks.

2D

In 2d the definition is straightforward. A position is defined by the distance to the origin and one angle. We just need the:

  • origin O
  • a reference direction where the angle is 0

For practical reasons mathematicians place the origin at the same position as it is in the cartesian system and the reference direction is the positive x-axis:

Then the conversion from a cartesian vector (x, y) of a position P to polar coordinates (radius, angle) is:

radius = sqrt(x^2 + y^2)
angle = atan2(y, x)

and the way around:

x = radius * cos(angle)
y = radius * sin(angle)

Here a positive angular velocity moves the position counter-clockwise on a circle:

Note that many 2d computer graphics coordinate systems have the y-axis pointing downwards so that everything is flipped upside down. In that case, using the same calculations as above, a positive angular velocity moves the position clockwise.

To get the same behavior in a 2d cartesian system with y-axis down the calculations would be:

radius = sqrt(x^2 + y^2)
angle = atan2(-y, x)

and:

x = radius * cos(angle)
y = -radius * sin(angle)

3D

To define a point in space by spherical coordinates the distance to the origin O as well as two angles are required. The confusion starts here since many conventions for the notation and the order of the angles exist. This page lists most of them:http://mathworld.wolfram.com/SphericalCoordinates.html

But let's step back and have a look at what we need to define spherical coordinates. We will see that regardless of the notation the actual formula for the calculation is the same:

  • the origin O
  • for one angle we need a directed axis which defines the poles (like north and south pole of the earth), this angle is often called polar angle, zenith angle, colatitude, inclination or elevation
  • for the other angle we need a reference direction in the equatorial plane, this angle is called azimuthal angle

The origin is also the same as the one of the cartesian system. Traditionally mathematicians choose the z-axis as the polar axis and the xy-plane as the equatorial plane with reference direction as the positive x-axis:

The conversion formulas are then:

radius = sqrt(x^2 + y^2 + z^2)
polar = arccos(z/radius)
azimuthal = atan2(y, x)

and:

x = radius * sin(polar) * cos(azimuthal)
y = radius * sin(polar) * sin(azimuthal)
z = radius * cos(polar)

As you can see in the drawing, if polar angle is 0 the vector points toward the positive z-axis and the azimuthal angle has no effect because it only rolls the vector around the z-axis.

Positive polar velocity moves the point away from the pole at positive z towards positive x.
Positive azimuthal velocity moves the point from positive x towards positive y.

The drawing uses a right-handed system with z-axis up which is common in math textbooks. As in the 2d case it looks different depending on orientation of the xyz-axis of the cartesian coordinate system in which the position will be displayed.

Geographic Coordinates

The definition of the spherical coordinates has two drawbacks. First the polar angle has to have a value other than 0° (or 180°) to allow the azimuthal value to have an effect. Second the geographic system of latitude and longitude does not match with the two angles.

In order to match the spherical angles to latitude and longitude the polar angle needs to have a value of 90°. Then the position vector points towards the positive x-axis in the equatorial plane which matches a latitude of 0° and a longitude of 0°.

The angular directions of latitude and longitude are the same. So the conversion is quite simple:

latitude = polar - 90°
longitude = azimuthal

and:

polar = latitude + 90°
azimuthal = longitude

With trigonometric substitutions a direct conversion between geographic and cartesian coordinates can be derived:

radius = sqrt(x^2 + y^2 + z^2)
latitude = arcsin(z/radius)
longitude = atan2(y, x)

and:

x = radius * cos(latitude) * cos(longitude)
y = radius * cos(latitude) * sin(longitude)
z = radius * sin(latitude)

Implementation for VL

VL assumes that the user works in a left-handed cartesian coordinate system with the y-axis up which is commonly used with DirectX. This means that all the above images and directions would be somehow rotated and flipped when used in such a coordinate system. But that's of course not what we want. The north pole of a sphere should still be up and the angular directions of the angles should also be the same as above.

The conversion of a vector between the systems is not very complicated:

xR = -zL
yR = xL
zR = yL

and:

xL = yR
yL = zR
zL = -xR

The simplest solution would be to convert the vector before or after the calculation, but we can also apply the conversion to the formulas. Then we get for the spherical coordinates:

radius = sqrt(x^2 + y^2 + z^2)
polar = arccos(y/radius)
azimuthal = atan2(x, -z)

and:

x = radius * sin(polar) * sin(azimuthal)
y = radius * cos(polar)
z = -radius * sin(polar) * cos(azimuthal)

For geographic coordinates:

radius = sqrt(x^2 + y^2 + z^2)
latitude = arcsin(y/radius)
longitude = atan2(x, -z)

and:

x = radius * cos(latitude) * sin(longitude)
y = radius * sin(latitude)
z = -radius * cos(latitude) * cos(longitude)

Angle Units

Since we all love the convention of scaling value ranges to the interval 0-1, the VL nodes also use cycles as units as we are used to from vvvv.

Node Names

As we assume that the standard system you work in is cartesian we use the 'To' and 'From' prefix which we think is more clear than the vvvv names 'Polar' and 'Cartesian' we had before. So we now have:

ToPolar, FromPolar
ToSpherical, FromSpherical
ToGeographic, FromGeographic

Since the Angle (3D) node already calculates the spherical angles and the radius, the VL implementation for the spherical coordinates looks like this:

You can find it along with the other conversion nodes in Basics.vl in the patch Utils3D.

Relation to VVVV nodes

The old vvvv nodes Polar and Cartesian in 3d are similar to the geographic coordinates with the exception that the angular direction of the longitude is inverted.
The 2d nodes do match exactly.

Cylindrical Coordinates

A natural extension of the 2d polar coordinates are cylindrical coordinates, since they just add a height value out of the xy-plane. For completeness here they are:

The formula is exactly the same as 2d polar corrdinates with the extension of the height:

radius = sqrt(x^2 + y^2)
angle = atan2(y, x)
height = z

and the way around:

x = radius * cos(angle)
y = radius * sin(angle)
z = height

Converting that to left-handed system with y-axis up gives:

radius = sqrt(x^2 + z^2)
angle = atan2(x, -z)
height = y

and the way around:

x = radius * sin(angle)
y = height
z = -radius * cos(angle)

Node Names

As for the other conversion nodes we use:

ToCylindrical, FromCylindrical

Download

As usual in the alpha builds.

tonfilm, Tuesday, Oct 6th 2015 Digg | Tweet | Delicious 1 comments  

dir lovvvvers of visual programming,

we've not talked about our progress on VL for a while. So here is what happened since its initial public release at the NODE15 keynode.

What the VL?

VL is our next generation visual programming language that (for now only) integrates with vvvv as you know it and allows you to patch plugins for vvvv making use of its object oriented language features. You can test it by using the latest alpha build and following the VL quick reference as an introduction. If you encounter any problems, please get in contact using the VL alpha forum.

In the future VL will be available in a standalone development environment with which you'll be able to deploy .net executables and .dlls that can be consumed by any other .net application.

What happened since node15

Library

A lot of work has been done in the library. We first tried to focus on getting the basics complete. And I'd say we're about 90% there. Here is an overview of what you can now use:

  • String/Char: more functionality than vvvv except a RegExpr node
  • Color: more functionality than vvvv
  • Math: more functionality than vvvv except an ExpressionParser node
  • 2D: everything plus datatypes for Point, Size, Rect and Circle with all kinds of intersection utilities
  • 3D: everything plus datatypes for Plane, Box, Sphere with all kinds of intersection utilities
  • Transform: about 90% of all nodes known from vvvv
  • DateTime nodes
  • Animation/Logic nodes: about 80% of all nodes known from vvvv
  • Serialization: nodes to de/serialize (if not too advanced) datatypes
  • Collections: more spreading functionality than known from vvvv plus other collection types, like e.g. a Dictionary

As a bonustrack: quite a bit of the above functionality is patched, meaning you can inspect/change its functionality if needed and since everything is compiled the fact that something is patched is not slowing it down. Only the most basic stuff is imported from .net libraries and close to none of the functionality has been written by our hands!

So what's missing is mostly:

  • Audio/Video/Graphics/Physics
  • IO (File, Networking, Rs232, specific devices...)
  • Databases

Those are arguably the big chunks indeed, but since we have plenty of those in vvvv already it should not be that big of a dealbreaker for a start. And anyway we're moving..

Specifically we're in the process of importing a bit larger .net libraries to learn how we can work with them. The first tests resulted in a patched node for the EyeTribe eyetracking and the 3dConnexion spacemouse devices, all open for you to inspect. This is how in the future you will integrate any device. More to come..

UI

UK, so now that we're getting confident with the library what we're also working on is patchability.

Here is the biggest recent changes:

  • a simple Typebrowser now assists you with annotating pads
  • nodes with dynamic pin-counts, like the + node are now adding a new pin automatically when it has no more input free.
  • use Ctrl+M to annotate your documents/types/operations. This info is used in both the vvvv and vl nodebrowsers.
  • renaming a patch or an operation will also update all nodes referencing it.

And yes, much more to be done..

Language

Also languagewise a few things have happened. Here are some of the highlights:

  • loops now understand a special "Alive" outlet. Should the "Alive" outlet evaluate to false the slice will not make it into the output spread...
  • if-regions now have inlets. They provide the region with the value connected to the default input.
  • the targetcode quality has been improved improving the overall runtime performance.

The road ahead

We're quite happy with what the integration of VL into vvvv brings us and therefore instead of the VL standalone we now first concentrate on making VL a first-class language inside vvvv, ie. combining the powers of the two. Therefore we're now working towards beta35 which will be the first vvvv release that officially includes VL, expected around new-year. So take this time to check out the latest alphas and feed us back with your thoughts. The main question being: Are you able to express yourself within VL? Show us your patches and lets discuss where you meet limits. You know where to find us: IRC? and alpha forum. We're very much looking forward to your input.

Then with beta35 we'll expect you to gradually incorporate VL into your projects. Implement parts of new projects in VL and still do the rendering parts in vvvv. While you'll be doing that we'll have some time to prepare the standalone release that at some point should finally convince you to completely move to the next generation of visual programming. But no need to rush it..one step at a time..

If you want to support our work we're happy about every single flattr:
/downloads|vvvv?

joreg, Tuesday, Sep 1st 2015 Digg | Tweet | Delicious 9 comments  

In order to run the current alphas (34.100 and up) a .NET 4.6 installation will be required. The setup.exe will already check for that.

For our dear developers using the vvvv-sdk a Visual Studio Community 2015 installation (which is free) should provide you with all the tools required, for those who prefer SharpDevelop 5.1 the .NET 4.6 targeting pack and the Microsoft Build Tools 2015 should get you up and running.

A nice overview of all the different .NET downloads can be found here.

For a list of changes in .NET 4.6 have a look here.

Elias, Wednesday, Jul 29th 2015 Digg | Tweet | Delicious 0 comments  

The winner of the VL feature voting is now available in the alpha builds.

The type browser will assist you when annotating the type of a pad by providing an auto completion list with all types valid in the current scope.

So give it a test run and as always, report your findings in the alpha forums.

happy typing,
your devvvvs

tonfilm, Monday, Jun 22nd 2015 Digg | Tweet | Delicious 1 comments  

dir people interested in our nextbigthing that is VL,

we've taken a bit of rest after node15 and are getting back into our business of creating serious visual programming experiences...

Feedback regarding VL so far has been cautiously positive and some of you already encountered the most pressing features that are still missing. On our road ahead we want to ask you to help us identify the best order in which we implement things. So of our long list of features that we're definitely going to implement, we've extracted 5 for you to vote on.

Regarding the selection: Those features are only the top five results of our internal voting. Also they only include features we thought we can clearly communicate. Of course there are many other issues we'll address independently anyway.

Think shortterm: Which of the following features could your patching most benefit from?

  • Type Browser: At the moment you still have to know the exact spelling of possible types by heart. The type browser will assist you when annotating the type of a pad by providing an auto completion list with all types valid in the current scope.

/blog/vl-feature-voting?1|Type Browser?

  • Automatic Type Converters: At the moment some links (like Float64->Float32) can not simply be made without manually placing a converter node (like: ToFloat32) in between. We'll introduce special links which convert a value from one type to another and will directly allow you to make such connections saving you quite some clicks.

/blog/vl-feature-voting?2|Automatic Type Converters?

  • Custom Enum Types: At the moment you cannot define your own enum types. You need this in order to be able to create operations like “Map” that can switch between different modes, like Wrap, Float, Mirror...

/blog/vl-feature-voting?3|Custom Enum Types?

  • ForEach Component Region: At the moment when you want an operation to be applied to all components of a vector at the same time you'll have to split and then join it again. We'll introduce a new region especially made for vectors which executes its body for each component of a vector. This allows you to use nodes working with scalar values on vectors without doing the splits and joins manually.

/blog/vl-feature-voting?4|Foreach Component Region?

  • Dynamic pin counts: At the moment nodes always have a hard-coded amout of pins. Nodes with potentially dynamic pin counts (Cons, Group, ...) will automatically get a pin added when the mouse is close and a pin removed when a link gets deleted. This means no more changing the pin count in the inspector.

/blog/vl-feature-voting?5|Dynamic Pin Counts?

Voting ends on June 14th.

Why Flattr? This excludes a large number of people who can vote?! Well, first, anyone can easily sign up to Flattr here, and on the other hand it specifically invites those who probably take this a bit more seriously. So this is an experiment. Looking at the list of vvvv flattr users it seems that we have a potential of 27 votess in total at the moment. Lets see how this goes..

Still not sure about that flattr thing? Read the rationale again: Flattr on vvvv.org.

Very much looking forward to your votes,
devvvvs.

joreg, Sunday, Jun 14th 2015 Digg | Tweet | Delicious 12 comments  

dir lovvvvers of patching,

let us introduce to you: vvvv50 + the VL pack.
What the VL? Short version: VL is a new object oriented visual programming language embedded into vvvv that allows you to create compiled vvvv-plugins on the fly. Later it will also be available as a standalone version that will allow you to save patches as executables. Interested in the long story? Read our previous blogposts.

vvvv50 is now available with the latest alpha downloads and includes the VL pack for you to try.

Game logic patched in VL used as dynamic plugin in vvvv

What happened so far

To give you an idea of how the vvvv50 naming makes sense, a little history:

  • vvvv10: early inhouse at meso
  • vvvv20: early inhouse at meso
  • vvvv30: initial version with visual programming UI (still inhouse)
  • vvvv31: spreading revisited (inhouse)
  • vvvv32: with subpatches, undo (inhouse)
  • vvvv33: initial public offering
  • vvvv40: introduced the plugininterface
  • vvvv45: introduced dynamic plugins (ie. a C# editor)
  • vvvv50: introduces the VL editor

Interested in more history? Watch our NODE08 Keynode where we went into more details about the early days of vvvv.

Getting Started

Documentation is still very rough, we're on it. For now you have two entry points:

1) For getting started read the Dynamic VL plugin reference and then continue browsing The Gray Book. This is where we're going to put everything we know about VL. In order to help us focus on the right content for the book please ask questions in the alpha forum using the VL tag so we get an idea about the most pressing issues.

2) For just having a look check the girlpowers:

 \packs\VL\girlpower

The Road Ahead

Since VL is in its very early days and it will still see quite some (hopefully not breaking) changes we're still trying to keep this a bit low-profile, ie. just among us, the existing vvvv community. Only later when there'll be a standalone release we'll make some more noise about this.

For now we're hoping to get some of you interested in it enough so that together we can iron out the biggest buggers and prepare for a smooth standalone release we're optimistically targeting towards the end of the year.

Besides fixing bugs we also have tons of features planned and we want you to help us prioritize them. Watch out for a new blogpost with the title: "VL Feature Voting" that is still to come..

Licensing

For now, when using VL integrated in vvvv, no additional licensing terms/costs apply, ie. free for non-commercial use, commercial use requires a vvvv license. What an amazing deal!

Eager to support this? We always appreciate a flattr:
/downloads|vvvv?

joreg, Monday, May 11th 2015 Digg | Tweet | Delicious 3 comments  

hola,

here is the final 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 previous issues with the titles:

  1. 50: That-Next-Big-Thing.-An-Overview.
  2. 50: Colors
  3. 50: Properties
  4. 50: Generics
  5. 50: Custom Datatypes
All information given here is still preliminary and subject to change.

With little more than a week till keynode you might assume that by now we have a pretty good idea of what the initial release of 50 will look like. Well...of course. Sadly we also now know which parts we'll have to leave out because we're just not satisfied with it yet. We've definitely hoped for more but we're confident there is enough for you to get started and by the time you get bored we drop the next feature to keep you entertained. Think carrot.. on a stick.. in front of your eyes..

The past two weeks we got external testers support from bjoern and woei. They were hardly able to hide their disappointment after the first hours of working with 50 because there were just too many problems to deal with still. So we were very grateful for their patient bug-reporting and after two weeks we were quite happy with what they've achieved. Tons of fixed bugs later we believe to now have something we can call an alpha-candidate.

So let's recap what you will get to play with on April 29th:

Language

With 50 we are giving the world a new programming language. Its name is "VL", which in good programming language trivia also denotes the file ending of documents written in the language. ie. you'll work with files like: callmenames.vl

VL initially will allow you to:

  • define operations with (generic) input and output parameters
  • define datatypes with properties and operations
  • collect instances of your datatypes in spreads
  • run operations for-each slice in a spread
  • define delegates aka anonymous functions
  • use delegates as parameters of operations
  • observables..

We have a list of more language features still to come. Those are only the ones that made it to the first release.

User Interface

Did you notice we haven't spoken about the UI at all yet? The reason being that a lot of the UI design depends on the language design and as we've pointed out repeatedly thats where our focus mostly was in the past months. Thats the part of the UI that is inside the patch.

The other part of the UI is everything around the patch and is mostly related to document handling or navigating the structure of a project. Regarding this, here are some fresh news for you:

A typical simple VL project will consist only of a single VL document since now a single document can hold any number of patches. Of course at any point you can decide to create multiple documents and reference one from another, but by default you won't have to deal with multiple files.

So how is that related to the UI? Well, navigating a projects documents and patches is something the UI allows you to do and is what you'll do a lot while working on projects. A treeview would be the obvious choice here but since we're not best known for obvious, we have gone a bit experimental in that respect hoping to provide a faster access for most usecases (with the treeview only as a fallback for now). We'll see how that works out..

Navigation Menu

Library

Also not much library talk so far. And here you'll probably see your biggest disappointment with the initial release: There aren't many nodes yet. Certainly none that do any drawing or even a renderer of any kind yet. Instead we hope to get you covered with the basics for math, string, color and spread handling so you're able to get used to the new paradigms.

Still here some more library news: We created a tool that allows us to import datatypes and operations from any managed library out there and have them available as nodes in VL within just a few clicks. Thats quite crazy in theory. And yes, even in praxis. Only in praxis it also means that while we'll save years of time writing library-code we have to invest some time in curating libraries and make them work properly and intuitively within the VL world of thinking. Can you have that tool to import stuff for your self? Not now. Later? Of course!

Deployment

As we already demoed at node13 VL is a compiled language meaning that with any change you do to a patch, 50 in the background creates a new executable and instantly runs it. And really that should be none of your concern unless of course you're interested in running your creations standalone, ie. without the need for 50 being around.

Because thats what "compiled" also means: Create standalone executables from a project with a single click. And if one uses only dependencies to cross-platform libraries in a project, the executable will even run cross-platform. Only: Not with the initial release.

Also we demoed having 50 itself running on other platforms, which according to the survvvvey 39% of vvvv users are waiting for.. Anyway..not happening either. Not now.

Bummer..so with all that "not now" is there actually anything left to look forward to? Eeei god hasn't created the world in one release...

Still interested in a map of the road ahead? Don't miss the keynode where we'll try to lay it all out.

Appreciate what you just read? We appreciate a click: /downloads|vvvv?.

Looking fwd to seeing you all at node!

joreg, Friday, Apr 17th 2015 Digg | Tweet | Delicious 22 comments  

helohelohelo,

here is the fifth 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 previous issues with the titles:

  1. 50: That Next Big Thing. An Overview.
  2. 50: Colors
  3. 50: Properties
  4. 50: Generics
All information given here is still preliminary and subject to change.

Now please fasten your seat belt because this is a big one. Probably the single least asked for feature that could still become 50s unique selling point: Custom Datatypes.

There is a chance that for some of you it will now be enough to explain this in one sentence: In 50 a patch defines a datatype, horray! If that makes sense to you already, then cheers. There isn't much more to learn in this article.

Glad you're still reading. So you belong to the other group of people who are probably afraid that this may be the moment you're loosing it. It being your understanding of how it will be like to patch in the future? Fear not! "Custom Datatypes" only sounds abstract but is actually a very basic and intuitive concept. You'll understand and be happy to have them around soon, read on.

But before demonstrating how custom datatypes make our patchings easier with 50, lets first establish a problem in 45 to pave the road for the hype:

The demo scenario:

  • when the left mousebutton is pressed, particles (with random velocities) are added
  • when a particle reaches y < -1 it is being removed

In good old modular fashion here is how you could approach this:

A patch in 45 is merely a visual clue for the user

Step 1) A single particle

  • Create a patch called Particle that has a "Start Position" (2d), a "Velocity" (2d) and an "Initialize" input
  • Create a node of this Particle-patch, attach it to Mouse and Renderer and voila: A single particle moves as you click in the renderer
Left: the Particle patch that holds and manipulates the particles data in a framedelay loop. Right: a patch utilizing the Particle patch.
Click to enlarge.

Step 2) Multiple particles

  • Want multiple particles? Just spread them, right?. But how? If we'd just put a static randomspread to the Particles velocity input we'd get multiple moving particles, yes, but we'd not be able to remove individual ones once their y < -1
  • Intuitively we'd want to somehow create particles and put them into a spread as such. Only we don't really get hold of the particle itself. What we can get access to is its position and velocity properties. So lets put those in a spread
  • In order to be able to manage (ie. add/remove) individual particles we have to move the framedelay from inside the Particle patch (where we'd actually want it) to its parent patch. Now the Particle patch is degraded to a hull with the name "Particle" but it no longer holds the actual particla-data. That is bad.
Left: the Particle no longer holds the data. Right: the parent patch manages the particles data via InsertSlice and Select within a framedelay loop.
Click to enlarge.

The framedelay together with an InsertSlice and a Select allow us to easily (well,..) add and remove slices dynamically.

So far so 45. See the fact that we needed 2 framedelays here? One for Position and one for Velocity? Oh you can zip those two parameters into one spread, of course. But next you blink the boss demands the particle to have a Color and a Name and you already need 3 framedelays... See where this is going?

The general problem here is that, as mentioned in 50: That Next Big Thing. An Overview., 45 does not really understand subpatches. For 45 everything is just one big patch and when you carefully modularize the Particle patch, 45 does not get any of this. So Position, Velocity and any other parameters are just laying there but 45 does not understand that they all describe properties of a particle and actually belong together.

This is where in 45 we'd advise you to create dynamic plugins to join/split your custom datatype. Thats fine for a start, only it requires you to code. Also there are three contributions that I won't go into detail here but are worth mentioning in that respect: Message by velcrome, VObject by microdee and VVVV.Struct by woei & tonfilm.

So while you see there are ways in 45 to tackle such (still rather simplified) situations, they are all workarounds to that aforementioned inherent problem of 45 not knowing about subpatches. And we need you to be really frustrated about that, not about a missing grid or close-button in the UI. This is where we need you to chant in unison: "Go release the cat, we can't work like that".

Well, here we go:

A patch in 50 defines a datatype

What you really want to express when putting multiple properties in one patch is to wrap up all those properties into one entity that you can operate with. Which is exactly what happens in 50.

So just to make sure we got our terms straight, a quick recap:
Value, String, Color, Transform,... are all primitive datatypes we're used to.
Now when we create our own datatype we can think of it as a compound of multiple primitive ones. So for example our Particle could be a compound of:

  • Position (of type Vector2d)
  • Velocity (of type Vector2d)
  • Color (of type Color)
  • Name (of type String)

In other words: Those 4 properties (each of which has their own primitive datatype) together in a patch make our custom datatype called Particle. And of course this can be taken further. Think of a custom datatype called "Firework" that has a Spread<Particle> (meaning a spread of particles) and so on. So yes, datatypes can be compound and cascaded in any way. Apart from properties, datatypes also usually have one or more operations. Therefore the terms "patch" and "datatype" can be used synonymously.

To the point. We could of course exactly replicate Step 1) from above in 50 but we'll leave that up to your imagination and skip it here (as it would look exactly the same minus the framedelay). Instead we jump right into the definition of our custom datatype, which in its most simple form could look like this in 50:

Reading the patch:
In the (still rather rudimentary) listing on the left side you see that this patch has two properties called "Position" and "Velocity" and it has two operations called "create" and "update".

We've mentioned operations before, they are sections in a patch that can be independently executed. In 45 every patch has only one operation, therefore we never gave it a name, but think of it like "update" or "evaluate", ie. the operation that is called once every frame. In 50 a patch can have any amount of operations that can be executed any amount of times per frame (just dropping that here...more on it in a later posting).

So here the "create" operation is used to set initial values for a particles Position and Velocity properties. In further executions of "update" the velocity is always added to the position and the result is again stored in the "Position" property for the computation of the next frame. Also the result is being returned to the caller of the "update" operation as you can see via the little quad in the bar labeled "update".

Next: How do we create an instance?

Instantiating a custom datatype

ad step 1)
Lets again start with placing just a single particle in the patch:

By simply creating a "Particle" node in a patch, what actually happens in 50 is that we create a static instance of the type "Particle". Static meaning that it is instantiated when the program starts. The particle executes its "create" operation once and then repeats executing the "update" operation every frame until we delete the node or stop the program. We can of course create multiple Particle nodes next to each other and have multiple static instances.

Give it a velocity and it moves..done.

Creating dynamic instances

ad step 2)
The challenge now is to create multiple instances of Particles dynamically. But don't think 45 style SetPatch (VVVV), where you'd tell vvvv to actually create a Particle node and place it in a patch... no. This is where the 50 magic chimes in:

Instead of placing the "Particle" node as such in a patch we can also just call individual of its operations. Booom. In the patch below notice the "* Particle" node. This one is short for Particle.Create(), ie. calling the particles "create" operation to create and return a single instance. And then spot the double-decker ".update Particle" which is (not so short) for Particle.Update() that is called in the "For Each" region, ie. it is called once for each particle in the list.

Reading the patch:
When the left mouse button is pressed a new particle is added to the spread with the current mouse position as start position and a random velocity. Remember from the last posting about generics that the ".add Spread" is not specific to the particle! Then for each particle in the spread the update-operation is called so the particles move. Also for each particle a circle is created. The select node only takes particles that are still alive (ie. have an y < 500) and writes them back to the spread of particles. Finally all the circles are drawn in the renderer.

If you now once more compare the 45 and 50 approaches here is what you should note:

  • in 45 the data of the particle is mixed together in a patch with the parts that manage the particlesystem (ie. add/remove particles). That works ok-ish in this simple example but is hell in larger scenarios.
  • in 50 the data and functionality of the particle are conveniently wrapped inside a particle patch and another patch around the particle, which we could call ParticleSystem, simply manages multiple instances of particles. So when changing functionality in the particle nothing has to be changed in the ParticleSystem. This is big!

You still here?
yawnsmiley... let us digest this information for a while. I think it is enough for this time. Still more to come..
goodnite.

Appreciate what you just read? We appreciate a click: /downloads|vvvv?.

joreg, Sunday, Mar 1st 2015 Digg | Tweet | Delicious 10 comments  

anonymous user login

Shoutbox

~15h ago

joreg: PSA: This wednesday 11pm vvvv.org will be moving servers. If everything goes according to plan we should be back within a few hours.

~23h ago

joreg: Also as every 2 weeks: This Tuesday: Free introduction to the all-new #vvvv: free-vvvv-intro-workshops-this-summer-in-berlin followed by the regular vvvv meetup

~24h ago

skyliner: anyone at usbynight?

~1d ago

joreg: Reminder: This wednesday in #berlin: Getting Started with Data Visualization: https://nodeforum.org/announcements/workshop-getting-started-with-data-visualization/ vvvv #creativecoding #dataviz

~3d ago

joreg: @eglod vvvv is international! wenn du hilfe auf deutsch brauchst, dann komm am besten in unseren deutschen chat: https://riot.im/app/#/room/#vvvv-at:matrix.org

~4d ago

eglod: In allen möglichen Sprachen gibt es VVV. V4 ist deutsch, warum nicht in deutscher Sprache. eglod

~4d ago

eglod: In allen möglichen Sprachen gibt es VVV. V4 ist deutsch, warum nicht in deutscher Sprache. eglod

~5d ago

joreg: Reminder: First #vvvv meetup in #hamburg this friday: vvvv-hamburg-meetup-1 Hope to see some of you there!

~7d ago

AKa-visuals: Hi guys. Everyone guess when xenko engine would be avaliable to play around in vl ... Isnt?