Blog
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.
Introduction
The latest VL comes with a revised 'Primitive' category in the nodebrowser. This category holds the most basic data types which the system has build in. As amazing as it sounds all other types are made out of them.
There are:
- Integer and floating point numeric types for calculations
- Boolean for logic
- Char and String for text
- A few system types like Exception and Object
In this article we will focus on the numeric types and which operations VL ships for them.
Overview
Primitive numeric types come in two flavors: integer and floating point. The number after the type name is the size of the type in bits. The number of bits also defines the value range that the type can hold.
The VL default types are Integer32 and Float32.
Operators and Types
| Numeric Unary | Numeric Binary | Bit Unary | Bit Binary | Bit Shift | Bool Unary | Bool Binary |
| + - |
+ - * / % < > <= >= == != |
~ | & ^ | |
<< >> |
! | == != && || & | ^ |
You should know most of them from math class but there are a few computer specific ones:
Division for integers is called DIV and it outputs an integer again. The "/" operator on integer types returns a floating point number.
The "%" operator is called MOD in VL and returns the remainder of a division.
For integers there is a combination of DIV and MOD called DIVMOD which outputs both the result of the division and the remainder. A practical usage is 2D column/row index calculation.
"~" is the ones complement, it inverts all bits of a value.
">>", "<<" are the bit shift operators, they move all bits of a type to the left or right. New bits are padded with zeroes.
The following table gives an overview of all types and their operators:
| VL Name | Bits | Unary | Binary | C# Name |
| Integer8 | 8 | num/bit | num/bit/shift | sbyte |
| Byte | 8 | num/bit | num/bit/shift | byte |
| Char | 16 | num/bit | num/bit/shift | char |
| Integer16 | 16 | num/bit | num/bit/shift | short |
| Integer16 (Unsigned) | 16 | num/bit | num/bit/shift | ushort |
| Integer32 | 32 | num/bit | num/bit/shift | int |
| Integer32 (Unsigned) | 32 | num/bit | num/bit/shift | uint |
| Integer64 | 64 | num/bit | num/bit/shift | long |
| Integer64 (Unsigned) | 64 | +, ~ | num/bit/shift | ulong |
| Float32 | 32 | num | num | float |
| Float64 | 64 | num | num | double |
| Boolean | 1 | bool | bool | bool |
Value Range
Integer types
| Type | Range | Size |
| Integer8 | -128 to 127 | Signed 8-bit integer |
| Byte | 0 to 255 | Unsigned 8-bit integer |
| Char | U+0000 to U+ffff | Unicode 16-bit character |
| Integer16 | -32,768 to 32,767 | Signed 16-bit integer |
| Integer16 (Unsigned) | 0 to 65,535 | Unsigned 16-bit integer |
| Integer32 | -2,147,483,648 to 2,147,483,647 | Signed 32-bit integer |
| Integer32 (Unsigned) | 0 to 4,294,967,295 | Unsigned 32-bit integer |
| Integer64 | -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 | Signed 64-bit integer |
| Integer64 (Unsigned) | 0 to 18,446,744,073,709,551,615 | Unsigned 64-bit integer |
Floating point types
| Type | Approximate range | Precision | Size |
| Float32 | ±1.5 * E45 to ±3.4 * E38 | 7 digits | 32-bit float |
| Float64 | ±5.0 * E−324 to ±1.7 * E308 | 15-16 digits | 64-bit float |
This also means that the maximum consecutive integer that can be represented is 2^24 = 16,777,216 for Float32 and 2^54 = 9,007,199,254,740,992 for Float64, keep that in mind when connecting integers to float inputs.
Conversions
Between Numeric Types
Smaller integer types can directly be connected to bigger integer types that can hold the range of the smaller type and to floating point types.
For all other conversions a node is required since information might get lost.
However, sometimes you want to trick the VL type inference system or you explicitly want a specific type and therefore the complete list of conversion nodes are available.
Checked
Checked conversions throw an error if the value to convert exceeds the range of the target type. This can be helpful if you want to make sure to assign correct values to bytes.
The naming scheme of the nodes is ToTargetType and they are located in the category of the source type. For example a conversion from Integer32 to Byte is called ToByte (Integer32). Unsigned types are abbreviated with an 'U', so a conversion from Float32 to Integer32 (Unsigned) is called ToUInt32 (Float32).
Unchecked
Unchecked conversions do not throw errors and just copy appropriate bits from the source type to the target type. This results in value wrapping. For example converting an Integer32 with value 256 to a Byte will result in a value of 0, an integer with value 257 in a value of 1 and so on...
Because they directly copy the bits, the naming scheme of the nodes is BitsToTargetType in the category of the source type. For example a conversion from Integer32 to Integer64 (Unsigned) is called BitsToUint64 (Integer32) or a Byte to Char BitsToChar (Byte).
Type -> String
The conversion form machine representation to human readable string is of course essential for programming. There is a general node ToString (Object) which tries to convert everything plugged in to it to a string. This node works for all numeric types and Char because the system knows what to do.
However if you want your value in a specific string representation you have three more advanced nodes for all numeric types:
ToString (Format)
This is the most powerful node. It allows to input a format string which acts as template for the output string of the value. See these two documentation pages for the vast amount of possibilities (thanks microsoft!).
Standard Format Strings
Custom Format Strings
ToString (Binary)
Quite helpful when working with low level device protocols and other bitwise operations. Nerds ahoi!
ToString (Hex)
Hexadecimal is a compact representation of the bits where one digit can represent 16 values from '0' to 'F' which is 4 bits. You know this probably from html colors. Medium nerdy.
String -> Type
Parsing strings to a numeric type is also often required. When getting user input from or reading data from a text file for example. Since the parsing can go wrong quite easily the nodes are called TryParse and have a boolean output 'Success' which indicates whether the input string could be parsed into a numeric value that makes sense.
TryParse (Hex)
Version to parse hexadecimal strings into a numeric type.
TryParse (Binary)
My personal favorite, parsing binary strings. (Didn't you ever want to just type ones and zeroes into your computer?).
Conclusion
This might be some heavy detailed stuff for the average user, but it gives us a solid core library that is ready for all tasks and can solve even the problems on the lowest level.
And rest assured, most of the time you will just deal with the standard types Integer32 and Float32 and don't have to worry about the others. But in the 1% case when you need to shuffle the bits its all there for you.
yours,
devvvvs
For years now vvvv is shipping with little helper modules like the AxisAndGrid (EX9), Camera (Transform Softimage), PointEditor (3D)... and some more that are hopefully saving you a lot of time while patching. In fact the Camera was the very first module i ever built when we introduced the concept of subpatches. It didn't work well, so gregsn took it over, fixed it and made it a Softimage one as this was the software he was used to at that time...
Anyway, we maintained those modules over time but kinda failed to review/consolidate them. Not least because they were always a bit tricky to handle. While they look quite simple from the outside they are rather complex internally. And as you may have noticed, at certain complexities vvvv patches become a bit tedious to maintain...
Entering VL. With VL we now allegedly have the right tool at hand to tackle such complexities. To put it to a test we thought it would be a good time to rework those Camera and Editor modules. So we went ahead keeping the following things in mind:
Design Goals
- Modularity: a clear line between Model and View allows
- easy reuse of individual parts in custom editors
- a simple way to adapt the look of an editor by simply providing an alternative View node
- to easily provide DX9 and DX11 versions of all editors
- Persistence: editing state can be saved to and loaded from disk
- Boygrouping: editors can be used in boygrouping scenarios by simply putting a halfboygrouped module (provided) between Editor and View
- Undo/Redo: editing steps can be undone/redone
Performance
By building them with VL (which, remember, is a compiled language) we were hoping for improved performance because the existing modules were actually quite CPU hungry. And indeed we got better results immediately even though there's not been put too much effort in optimization on the VL side yet.
Drawbacks?
Of course! Mainly one though. A little one. More an annoyance. Not a big deal really. You may not even notice it..well..after a while.. in fact some people may even love it..niiiooaaa.. here is the thing: The first time you're using one of those new modules, VL is loaded, which takes a while. That really only happens once per session though, so lets for now pretend it is not that bad...
Here is what you get
- PointEditor
- BezierEditor
- BezierPatchEditor (was: GridEditor)
Each of the above come in two flavors: 2D, 3D
Besides the above design-goals here is what changed with the modules for the user:
- no more need to connect Mouse/Keyboard
- no more need to tag points before moving them
- no more need to press different mousebuttons for operating on different axis. interact with on-screen pivot element instead
- better handling of point-dragging with extreme camera views
- on-screen-display informing about the current transformation
- MeshEditor (EX9) now also modifies normals
- AxisAndGrid now has pins to show/hide axis and grid
Bonus:
- ArcLength (2d/3d) a replacement for https://vvvv.org/contribution/pathvectors-%283d%29 and https://vvvv.org/contribution/arclength%283d-generic%29
- a generic Undo (3d) module (as used in MeshEditor)
Next Steps
The editors still need a bit of finetuning in terms of interaction and also their internal architecture is not yet exactly optimized for readability. Then the DX11 versions of the views need to be patched but that should be rather trivial since it is really only about drawing. So now you please give it a spin and feed back your findings before we're going into a second round..
Available now in latest alpha builds.
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
- download: vvvv alpha downloads
- demos: see \packs\vlpack_..\girlpower
- learn: VL quick reference
- discuss: alpha forum
(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.
Mapping in VL
Let's see if we can improve on that in VL.
First we make three important observations:
- 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.
- The mapping mode almost never changes during run-time for a particular use case
- 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:
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 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
The map node itself got pretty simple and just does what its name says, mapping the input from one range to another:
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!
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.
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?
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 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
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,
devvvvs.
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.
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?
anonymous user login
Shoutbox
~7d ago
~1mth ago
~1mth ago
~1mth ago
~1mth ago
~2mth ago
~2mth ago
~2mth ago
~3mth ago