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.
previously on VL: VL Summer Update
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:
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..
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:
Of those we wrapped the following for your convenience into plugins for vvvv:
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..
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:
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:
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:
(Don't be alarmed by the fact that the alpha-downloads are huge at the moment. That'll be improved at some point..)
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':
So far, so easy.
Let's see if we can improve on that in VL.
First we make three important observations:
So we separated all functionality in VL to gain flexibility in the following way:
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:
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:
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:
The map node itself got pretty simple and just does what its name says, mapping the input from one range to another:
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:
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.
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.
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.
In 2d the definition is straightforward. A position is defined by the distance to the origin and one angle. We just need the:
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:
and the way around:
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:
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 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:
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.
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:
With trigonometric substitutions a direct conversion between geographic and cartesian coordinates can be derived:
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:
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:
For geographic coordinates:
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.
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:
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.
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.
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:
and the way around:
Converting that to left-handed system with y-axis up gives:
and the way around:
As for the other conversion nodes we use:
As usual in the alpha builds.
dir lovvvvers of visual programming,
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.
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:
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:
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..
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:
And yes, much more to be done..
Also languagewise a few things have happened. Here are some of the highlights:
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:
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.
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.
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?
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,
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.
To give you an idea of how the vvvv50 naming makes sense, a little history:
Interested in more history? Watch our NODE08 Keynode where we went into more details about the early days of vvvv.
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:
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..
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:
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:
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:
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:
We have a list of more language features still to come. Those are only the ones that made it to the first release.
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..
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!
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!
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:
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:
In good old modular fashion here is how you could approach this:
Step 1) A single particle
Step 2) Multiple particles
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:
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:
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?
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.
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:
You still here?
yawnsmiley... let us digest this information for a while. I think it is enough for this time. Still more to come..
Appreciate what you just read? We appreciate a click: /downloads|vvvv?.
anonymous user login