» 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

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  

helo patchers,

here is the fourth 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
All information given here is still preliminary and subject to change.

So "Generics", uff, sounds so serious, I know. Still we have to mention them now because it will help you understand things further down the road. And you'll be surprised how easy the concept is to grasp. Promised.

No generics in 45

In vvvv45 (45) we don't have generic nodes. What we have instead is a lot of identical nodes like eg. "Zip" available for different datatypes. There is a Zip (Value), a Zip (String), a Zip (Color)... and the nodebrowser is full of such duplicates for a lot of nodes, like GetSlice, Select, Queue,... all of which are nodes where the operation they do for us is actually independent of the datatype they handle. We can call such operations "generic" in the sense that if for example you think of the functionality of a Zip it is not really important to know whether it zips slices of a spread of strings or a spread of colors. Easy? Yep.

In a 45 patch nodes like Zip already look generic because precious screen-space is saved by leaving out information that would not help in understanding the functionality of a patch. Still the nodebrowser is full of duplicates you have to explicitly choose between.

Only recently we've introduced a way for plugin developers to easily create duplicates of those generic nodes for their own datatypes but that is really only a workaround to the fact that we don't have support for generics built right into 45. Still better than nothing, see: generic-nodes.

Generics in 50

Now when we say 50 has support for generics we can advertise that in two ways:

For the casual patcher

First, the nodebrowser will have less nodes to choose from because it can leave out many duplicates (well, it will have many more other nodes but at least no datatype-duplicates). If you want a Zip you don't have to decide for which type you want it. Just place it in the patch, connect anything to it and you're done. 50 will figure out what you mean.

In a 50 patch a zip is a zip is a zip and you can connect any datatype to it. So in this example the left zip is forced to operate on values and the right zip is forced to operate on colors only.

For the pro patcher

Secondly (and this is probably a bit more abstract to wrap your head around, but please try:) when you patch an operation you can be unspecific about the datatypes of its inputs and outputs. Sounds exciting? Here is an example: Consider someone patched the functionality of a Queue. This is what it could look like in 45 and 50:

Queue (Value) in 45 vs. Queue (Generic) in 50

Reading those two patches:
The Inlets and Outlets (Item, Insert, ..) of both implementations are the same and the FrameDelay, as we've already learned, is replaced by a property (called "Items" here). And while both kind of look generic, in the 45 implementation we see the Item obviously is a value IOBox. Therefore we know that this is a specific implementation for values.

In the 50 implementation you see all the operations (clear, insert, take) are working on the generic collection type Spread, ie. they have not yet been forced to operate on a specific type like Spread of value or Spread of color. And you can easily identify pins, in- and outputs and the property that are generic as they are visualized in a different way (ie. only showing their contour). So here is a single implementation of a queue that works for any datatype at a time, even ones that you create yourself (more on that in the next post).

What you take away here is that 50 comes with a set of generic spread operations (insert, take, zip,...) for handling any kind of data and the problem you sometimes faced in 45 where individual spread operations were only available for specific datatypes, is no more.


And the best of it all which is really only a side-note here:
For all those basic generic spread operations we don't have to write a single line of code. In 50 we can magically make use of that functionality as it comes with the .net library. Besides the fact that this saves us a lot of time it also means those basic operations can be assumed virtually bug-free, not only because we didn't write them but also because Microsoft has been taking care of testing that code since years.

That just for a little soothing happynew50 update. Now fasten your seatbelts for the next issue with the blockbuster title "Custom Datatypes".

If what you just learned makes you feel like inserting coin, don't hesitate and click: /downloads|vvvv?.

joreg, Thursday, Jan 29th 2015 Digg | Tweet | Delicious 8 comments  

This one is for all pixelpeople out there.

From now on vvvv can talk, control, send and receive images to and from your Adobe Photoshop started on any networked machine. Layers, Groups, Masks, Smart Objects, Adjustment and Filter layers, Tools, File Operations... you name it, everything can be controlled remotely.

If all you want to do is to stream images from a running Photoshop instance, just take the Photoshop (EX9.Texture) and you are done.

For more advanced cases, there are modules to send/receive commands (yes, Photoshop speaks JavaScript) and images. Open the NodeBrowser and type 'psd'.

The Photoshop nodes are coming with the addonpack and there is a special section in the girlpower folder, which is your first destination as always:

 \addonpack\girlpower\Photoshop

The possibilities of scripting Photoshop are endless, we're just scratching the surface and prepared an easy way to do so along with some examples and documentation.

At the moment DX9 is used for input/output of textures, but thanks to the modular structure there are only 3 modules waiting for a DX11 version:

  • AsTexture (Photoshop EX9)
  • AsRaw (EX9.Texture Photoshop)
  • Photoshop (EX9.Texture).

Anyone?

Available for testing in latest alpha.
happy photopatching.

robotanton, Monday, Dec 22nd 2014 Digg | Tweet | Delicious 10 comments  

helo patcherpeople,

here is the third 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
All information given here is still preliminary and subject to change.

Here is a simple one in that there is not really much new. We're basically trying to sell you an old idea from vvvv45 (45) under a new name, a better name. Together with a new visual representation this will make things easier to think and talk about: Properties (formerly ridiculously called FrameDelays)

45-style FrameDelay

45-style: whats going on here?

When in 45 we create a FrameDelay node and combine it with a link that goes back up the graph against the typical dataflow that wording and visualization describes very well whats going on internally. But do we care what vvvv is doing internally? Not really, so why make such a fuzz about it in the patch. Instead lets see how humans would think/talk about whats going on there.

50-style Properties

Obviously the patch has two properties best named "Velocity" and "Position" and there is an acceleration coming that influences the velocity which in turn influences the position. So instead of using the notion of "framedelay loops", 50 puts emphasis on the fact that besides operations (Colors) we also have properties that name the data held in a patch. A property has a user-choosable name and of course a datatype (eg, value, color, string,..) and we can set (write data to) and get (read data from) it.

50-style: ah someone clearly computes a position from velocity and acceleration.

In order to get or set a property you need so called Getters or Setters, represented in 50 by circles that you can connect from and to. True, that looks a bit like 45-style Send/Receive nodes but it is something different. Remember that there is no frame delay between S/R nodes in 45. Here though it is always made sure that each frame first all Getters are read from and only then all Setters are written to (causing quasi a frame of delay but you don't really have to think about it that way anymore).

Also note that by forcing you to choose a name for each property (if you're not too lazy and just keep the defaults) 50 can render you a fancy human readable overview of all data in a patch. This overview doubles as a central place where you can manage (ie, add, remove, rename, ...) all your properties.

So if someone asks, this is why you like properties:

  • they are now first class patching citizens when in 45 they have been disguised behind framedelay loops potentially hidden all over a patch.
  • they help you getting an overview of what data is actually part of a patch as opposed to data that only runs through a patch.

Thats already it for this episode. Liked what you learned? Insert coin: /downloads|vvvv?.

joreg, Friday, Dec 5th 2014 Digg | Tweet | Delicious 29 comments  

anonymous user login

Shoutbox

~19h ago

joreg: In case you missed: We're starting with free bi-weekly introductions to #vvvv next week in #berlin free-vvvv-intro-workshops-this-summer-in-berlin #creativecoding

~1d ago

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

~8d ago

joreg: @beyon too bad. but from now on we have a fixed schedule: every 4th tuesday in the month! hope this helps to plan evvvveryones visits

~9d ago

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

~9d ago

joreg: @beyon any chance you can add 2 days to stay? would be great to have you at the (not yet announced) #vvvv meetup on the 23rd!

~9d ago

~9d ago

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