Obsolete!

From now on: Firmata Second Service.

Good news everyone, from now on you're getting a brand new set of nodes able to talk to your loaded-with-firmata Arduino Boards:

• ArduinoUno (Devices)
• ArduinoLeonardo (Devices)
• ArduinoMega (Devices)
• ArduinoLilyPad (Devices)
• ArduinoDue (Devices)
• ArduinoYun (Devices)

Together with jens.a.e (author of the original Arduino (Devices StandardFirmata 2.x) ) we've looked for a more convenient, easier and faster way to patch Arduino related ahhmm... patches.

With this implementation:

• Just plug a DigitalWrite (Firmata), AnalogWrite (Firmata) or ServoWrite (Firmata) node to the Arduino node (or concatenate them together) to set the pins of the Board.
• Connect DigitalRead (Firmata) and AnalogRead (Firmata) nodes to get the values from the Board's pins.
• Use the Sysex Messages output to receive different 'Sysex Messages' sent back by the Arduino Board. Some Sysex decoders are already there (see StringDecoder (Firmata), CapabilityDecoder (Firmata)). Sending custom 'Sysex Messages' is easy as well.
• Your board is not listed in the NodeBrowser? The Arduino nodes are easily adaptable for other controllers running Firmata. Hello teensy...

Easier than ever before:

• no need to supply a spread for all 20 pins and then SetSlice some of them to particular values.
• no need to define the 'PinMode' for each pin.
• no need to define which pins should report their values back.

Thanks:

Hardware for the development was kindly provided by QUADRATURE.

p.s.
Oh, by the way, these new Arduino nodes are fully implemented in VL.

p.p.s.
And of course there are some caveats.

• The Cons (Firmata) has only 5 input pins which are interleaved with 'BinSize' pins. But note that you can cons multiple cons nodes... (for now)
• The VL nodes eat more processor ticks as their C# counterparts. Working on it...

The nodes are now available in Alpha Builds.

Short Version

vvvv now has native support for both sending and receiving TUIO messages!
The following nodes are available in latest alphas:

• TUIOCursor (Network Join/Split)
• TUIOObject (Network Join/Split)
• TUIOBlob (Network Join/Split)
• TUIOBundler (Network)

For receiving TUIO messages the individual split nodes can be used directly. The TUIOBundler is used for combining different types of TUIO messages in order to send them in one bundle.

Some Background

vvvv has long had support for TUIO, a protocol for receiving data from multitouch surfaces. The TUIODecoder (Network) was contributed to the addonpack by Abomb years ago.

It did what it was supposed to with only two caveats:

• since it used an input of type String it had troubles on windows systems with non-standard string encodings
• it was only a decoder, lacking an encoder to also be able to send TUIO messages

Enter VL: While preparing the standard library for VL it was a good exercise to create probably the worlds-first implementation of the TUIO protocol in a visual programming language. And since we can make nodes we have in VL available as nodes in vvvv it was a just a few more clicks to make the new implementation even useable for non-vl patchers. You're welcome!

There is more to the nerds pleasing: TUIO is based on the OSC protocol which meant that before being able to implement TUIO, we needed an implementation of the OSC protocol. As we've pointed out before, in VL we have the possibility to import .net libraries. So one way to support OSC in VL would have certainly been to import one of the many existing OSC libraries for .net. In fact we did that and it was good to see that it just worked. Still the real challenge of course was to also create possibly the worlds-first implementation of OSC in a visual programming language. So here we are..

If you're interested in the implementations have a look at the VL files in:

 \packs\VL.IO.OSC
 \packs\VL.IO.TUIO

Otherwise just go ahead, use the nodes in vvvv and please report your findings in the comments or in the alpha forum.

This is to announce proper Spout support for vvvv (finally).

What the Spout?

Spout is a realtime video sharing framework for windows. Basically what Syphon is for OSX. It allows different applications that handle video (or textures) to share them. That includes TouchDesigner, Resolume, AfterEffects,... to name only a few. For a full list see the Spout website.

How to Spout?

While you've already been able to use Spout so far, it was a bit of a hassle to set it up. Now vvvv ships with two simple nodes which should be all you ever need:

• Spout (EX9.Texture Sender)
• Spout (EX9.Texture Receiver)

Both modules are also available as DX11 versions.

Internally the sender module uses the new SpoutSender (System) node to register a sender name with Spout. If you're interested in a list of all available senders on your system, use SpoutSenderNames (System).

Can I has Network?

Indeed! Check the brilliant TCPSpout and share your textures via network and even to applications on OSX by using TCPSyphon on the other end. Watch this video to see TCPSpout/Syphon in action:

Available in latest alphas now. Many thanks to the creators of Spout and TCPSpout! Please test and report your findings.

The Workshop

We had a 3 day VL workshop at resonate (belgrade) and this was just plain fun! In fact when thinking about that event some weeks ago i was still quite frightened by the idea of talking VL for 3 days straight. VL is still in an alpha phase and therefore sometimes harder to explain than you would want to. Of course it's less didactic if you need to also teach to work around glitches...

But then, just in time before the workshop, we remembered what learning a new system is about. It is about understanding how to apply it for "real world problems", so we made up a "problem" which we worked on as a team.

Our problem we named VLOsmos, after the game that we wanted to clone: Osmos.
http://www.osmos-game.com/
The goal of the game is to get to be the biggest bubble. You get bigger by eating smaller bubbles. But beware of getting eaten by a bigger one. To prevent this you sometimes need to flee, by accelerating into a direction. But alas by accelerating you loose mass, very much the same way a rocket does. You emit small bubbles... So you get smaller by changing direction, but you have the initiative which helps you get bigger earlier than others...

So our idea was that we actually want to work, and not do frontal teaching so much of the time. So we split up into three teams.
Every team had a helping hand (there were Elias, Dominik and me) and each team got one VL document to work on. We split up the work like this:

• Controller
• Game Logic
• Display

Controller

The controller team was responsible to hand over controller data to the game logic team. They also got the world state of the last frame from the game logic department. Here is what they did: They allowed to slip into the next free bubble and control it via mouse. I also saw this working with two mice (or track pad and mouse). But they also allowed to create several A.I. instances that slip into one of the next free bubbles and controlled them based upon the bubble world around the respective controlled bubble: try to accelerate into the direction of smaller bubbles (if those are not too small) and also run away from bigger ones...

Game Logic

The game logic team did the core logic of the game:

• Emit new small bubbles, loose weight and in turn accelerate (all based upon control data for the respective bubbles, therefore independent of who is generating this control data)
• Eat, grow, shrink in a fair manner
• Update the world in a frame based manner that also is fps aware. Output a description of the world for display and controller team.

Display

The display team was there to make it look nice. They got a description of the world with all bubbles and all currently happening collisions. For each collision a new collision effect got created, to have a bit of VL typical lifetime management in there. But in the end the display team also had to get the data back into vvvv to do the rendering here. Luckily this was obvious from the beginning and we found a way so that everybody got her/his amount of VL treatment.

All in all

We did not only work on a real project, but also had a try on how to synchronize the work of typically ten people, all working on the programming department of that project.
So we solved that by separating the job into those 3 main blocks and designed the interfaces between them = the types of data that flows between. In VL terms we created the data types "World" and "ControlData", which we put into a core VL document that every other VL document could reference.
After sketching the rough game structure and the interfaces in between each team had its own VL and vvvv document. We synchronized via a public git repository: https://github.com/gregsn/ResonateVLWorkshop

All in all we basically had a proof of concept regarding lifetime management and object oriented dataflow programming with VL embedded in a vvvv project.

The lecture

was about visual programming, its roots, sister projects, push and pull based dataflow, synchrnonous and asynchronous dataflow, object orientation, control flow via regions within a strict language and the playful culture and work environment where vvvv got created.
We also had a look onto the game that we created. The presentation was patched in vvvv for easily embedding video playback and game.

https://www.youtube.com/watch?v=NLyIYmPfCps
http://meso.net/download/filename/49/ok_spektral_meso_email.pdf