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: .
Here we go,
turns out it is quite a hassle to get 48 workshops run by 58 hosts in 5 days in 7 rooms under a single hat. You see the gorgeous result above and can get the .pdf here. Now it is on you to find your personal path of interest through the week and get your ticket. Full workshop descriptions and booking of individual seats will be available by next week!
Here is an alternative view on the workshops sorted by some vague categories:
You have no idea how much we are looking forward to this! Roughly 9 weeks time to prepare for the rush everyone. Back to coding...
For the Third Edition of GLOWFestival we decided to give an even bigger and more exciting edition of Festival also because 2015 was proclaimed by the UNESCO International Year of Light . And the GLOWFestival was recognized by the IYL (International Year of Light)! with the patronage and moral support! Many news this year about the use of light in artistic form in GLOWFestival, like:
° The video mapping Open call, with the choice of one of three locations;
° Mapping4kids Open Call! May participate kids of all ages. We ask them to to reinterpret the path of Locations that we will provide and to create an image based on it. Imagination is the limit! So if selected, they will see their drawing projected on one of the three locations of video mapping;
° 3D Official Gadget Festival Open Call, create the 3d model of gadget and see it printed in limited editions;
° outdoor installations open call with theme of light;
° BYOB (Bring Your Own Beamer Ostuni - in the historic center of Ostuni) The GLOWFestival offers you a chance to let everyone see what you can do with your projector and computer!
° Talks on Digital Media during the days of GLOWFestival;
When Thu, Mar 12th 2015 - 20:00 until Thu, Jun 4th 2015 - 22:00
Where Local de Arte, Unión 221-B, Col. Escandón., Mexico City, Mexico
El objetivo del taller es iniciar a los asistentes en programación con VVVV y demostrar sus posibilidades creativas. El taller hará énfasis en la experimentación con imágenes digitales y la interacción con estas imágenes en tiempo real.
El taller va dirigido a artistas y/o diseñadores que les interesa el arte electrónico y quieren empezar a programar. No es necesario que tengan experiencia en programación, sólo conocimientos básicos de computación.
Más información acá:http://www.localdearte.com/talleres03/vvvv-1
We are a design studio based in Milan working on a huge multi-projection realtime dataviz.
We are looking for a vvvv pro patcher with this appreciated skills:
Period: form last week of February for 2/3 weeks
Working place: studio dotdotdot.it in Milano
For any further information please do not hesitate to contact me: alessandro(at)dotdotdot.it
due to my Master-Thesis, I developed a new textbook with a bunch of tutorials using vvvv & Arduino with smell. Big thanks to westbam, 2nz and sorik, who helped me with the technical part here: http://iurl.no/263e4
Next step is to prepare it for the public. But this will take a bit time due to finding nice possibilities and licensement issues. Feel free to follow this project on my other socialweb platforms! Hope you like it. ;)
"Smelling Data – Translating data into scents with Arduino & vvvv"
There is no sensory perception that holds so many unanswered questions as the smell. Every day we smell thousands of different odors, making it the essential companion in our everyday life. But can we design smell? Or design with smell? If so, what possibilities do we have to get creative with smell?
With the textbook "Smelling Data" a practical introduction to the world of creative usage of olfaction is offered. It aims to provide designers a first approach to design with odors in combination with analog and digital media – and this may raises us an awareness of odors.
A basic knowledge on the subject of "smell" as well as the programming environments "vvvv" and "Arduino" are mediated. In addition, a variety of odor scenarios are discussed exemplarily on the basis of 10 instructions. Starting from simple scent-emitters to an odor-printer to interactive prototypes with which you can convert any code into odors.
2015.1.24 Japan meetup vol.3
We held vvvv Japan meetup every month.
We have a workshop and information exchange.
1.For Beginner: Basic Operation
3.vvvv and difference in another language(Max/msp/jitter, Pd, Touch Designer...and so on)
Spread Sample Patch is here.https://drive.google.com/open?id=0B-aWXftvAHSxMURuQ2twMkpjczg&authuser=0
Who Tebjan Halm
When Sat, Jan 31st 2015 - 17:00 until Sat, Jan 31st 2015 - 17:00
Where RCA Kensington, 2-6 Jay Mews, SW7 2EP, London , United Kingdom
It is a pleasure to invite all vvvv interested people in London to a replay of the vvvv50 intorduction talk from scope sessions at the RCA Kensington in the Stevens Building.
It is on very short notice, but I hope that a few patchers can make it. So spread the word!
Big ups to hadasi who managed to find the date.
In the past few years we’ve been eagerly working on a complete rewrite of vvvv which lead to a new visual programming language in combination with a development and runtime environment. Tebjan Halm (tonfilm ) will give a short introduction into the key features of this new language we’re internally calling "50".
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:
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.
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.
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.
Now when we say 50 has support for generics we can advertise that in two ways:
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.
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:
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: .
look what i found: openFrameworks 2013 survey results. that made for an interesting read so i thought we can rip that off and have our vvvvery own. you in?
what struck me though is that they only got 368 respondents, which doesn't seem a lot. can we get more? here is the URL to promote:
looking forward to getting a better idea of who we're dealing with here all the time.
anonymous user login