Registration to the workshops and conferences ends soon.
For the Urban Feeds cluster we are working with Libelium and Urbiotica to provide participants with the unique opportunity to work with some great technology which allows us to engage the complex conditions of the city. This information will be fed into Grasshopper (a generative modeling platform for Rhinoceros) via gHowl, and set of interoperability components which allow users the ability to interact with sensor data feeds.
We are very much looking forward to an intense and interesting cluster session!
You can download the components here: gHowl_r46
gHowl is developed by:
Here are the components included in this release:
UDP Components now have the ability to send and receive to a Multicast group. To send or receive to a Multicast group, make sure you use the IP Range of 188.8.131.52 – 184.108.40.206.
OSC functionality is provided by the Bespoke OSC Library by Paul Varcholik.
Network Source – Tests the connection of your machine to a network.
UDP Send – Allows the sending of UDP messages over the network. Also allows the sending of OSC messages to OSC enabled software and hardware devices.
UDP Receive – Allows the sending and receiving of UDP messages. Also allows the reception of OSC messages and bundles (from Reactivision for example).
OSC Channel – This component allows the storage of a single OSC Channel. Change the component’s nickname to store that address’ data.
OSC Dispatch – This component allows the storage of data from multiple OSC addresses.
The spreadsheet components leverage the Open Office Calc engine. You must have Open Office Calc installed in order for these components to work. These components read and write *.ods, *.xls, and *.xlsx files. Supports numerical values and strings.
AppChecker – Checks to see whether Open Office Calc or Excel are installed on your computer.
Spreadsheet In – Retrieves spreadsheet data from a file stored on your computer.
Spreadsheet Out – Allows you to write a spreadsheet file.
These components retrieve xml data from local and web sources (such as RSS feeds).
Pachube – Retrieves data from a Pachube feed. Must have a valid Pachube API key.
XML Parser – This component parses an XML file stored on your computer or on the web.
Barcelona / LaN / LaN RECOMMENDED NETWORK EVENTS / News / Parametric Design / Research / Scripting / Workshops
Images from the second day of the Live Parameters workshop being held at the Institute for Advanced Architecture of Catalonia (IaaC). What you see here are images of the first LaN Urban Sensing Kit (working title). This kit was designed by Felipe Pecegueiro do Amaral Curado, Oriol Carrasco, and Alba Armengol Gasull and includes a temperature sensor, light sensor, motion sensor, noise sensor, and electromagnetism sensor. It is run by an arduino and can be used to control Grasshopper definitions through gHowl+Processing or Firefly. Today Felipe introduced us to the sensor kit by demonstrating how to capture data into a spreadsheet through gHowl. Tomorrow we will take the kits out into the field, measuring data from the Poble Nou area of Barcelona. The kit will be evaluated and refined for further versions.
Current exploration into alternative interfaces for presenting and interacting with associative models. Here we see two examples of communication from an iPod Touch 2g to McNeel’s Grasshopper plug-in for Rhino. This is made possible by Open Sound Control (OSC) and the User Datagram Protocol (UDP). In these examples, a Processing interface was utilized to show what was going on with the iPod during the screencapture. In Processing, Stephane Cousot’s UDP library was used, as well as Andreas Schlegel‘s OSC library. More to come!
In a collaboration with Shajay Bhooshan, Autodesk Maya 2009 can communicate with McNeel’s Rhinoceros::Grasshopper. The work on communicating to and from Grasshopper via the user datagram protocol (UDP) was to effectively speed up communication between programs without the use of each program writing and reading a text file. This investigation was begun to open up Grasshopper to the outside world and eventually use it to drive physical associations via arduino and other interfaces. Processing was used initially as a testing platform for communication to and from Grasshopper. The first objective of the investigation was to eventually connect up with a custom plugin which Shajay Bhooshan has been developing.
On the Maya side, Shajay is controlling and augmenting this already vast platform with custom C++ API Nodes. His work can be seen on We Work 4 Her. This particular ‘fluid_UDP_Node’ transmits fluid data per voxel over UDP. Shajay has also taken advantage of the Open Frameworks, leveraging some of the code within the Maya plugin.
On the Rhino Grasshopper side, I have developed a very simple UDP receiver component in vb.net. The data is transmitted as one long string of comma separated values. Currently Shajay can send me fluid density and velocity information per voxel, but really, any type of information could be sent out. This information is parsed in the GH component and used to visualize the fluid as a Surface. As with the rest of the UDP experiments, Giulio Piacentino’s “The Engine” component made the refreshing of the Grasshopper canvas possible.
As you can tell, running all of these applications (including screen capturing) start to have an effect on this single processor machine. Maya can effectively optput the data between 8 – 12 frames per second depending on how many applications are running. The promising aspect of using UDP is that data can be sent from one computer to another via a network. This could effectively distribute the workload of complex combinations of processes to many devices. Videos are in real time on a single Pentium M processor @ 2.26GHz and 2GB of ram.
Here is an example of continuous data being fed into Grasshopper from Processing via the User Datagram Protocol (UDP). Very simple data, very simple result…but its a promising step in this investigation. In addition to the vb.net receiver, I am using Giulio Piacentino’s “The Engine” component to continuously refresh the GH canvas. You can find that component at his site:http://www.giuliopiacentino.com/grasshopper-tools/. The processing sketch was hacked together from a simple processing animation found at processing.org and the UDP library by Stephane Cousot: http://ubaa.net/shared/processing/udp/.
This video shows a connection between Grasshopper and a WebCam through Processing. On the processing side I am using Josh Nimoy’s (http://www.jtnimoy.net/) “JMyron,” a webcam library for processing (http://webcamxtra.sourceforge.net/download.shtml) and Stephane Cousot’s UDP library (http://ubaa.net/shared/processing/udp/). On the Grasshopper side I am using the same .net receiver as previous videos in conjunction with Giulio Piacentino’s “The Engine” C# Component (http://www.giuliopiacentino.com/grasshopper-tools/). The idea is to begin sending more complex data through…here I am sending x and y coordinates from Processing to Grasshopper.
With so many definitions focusing on an attraction point, why not go one step further and make it ‘real time’ action. In this case, you see my simple single processor machine from 4 years ago is starting to have some issues keeping up with everything. This video is the same setup as before, just with a more extensive GH definition.
Here is an example of a definition being driven by the position of the mouse over the processing sketch. Same setup, in this case, just using a simple mouseX and mouseY in processing as the message to transmit.