The idea was to develop something Arduino-based, but, you know, it’s not so easy to stuff an XMPP-based lib into 14K of memory (leave it alone the connectivity and TCP-IP stack), and this made me think that, even if OS will have a bright future in the embedded/mobile field, we needed to put up something fast. Ok, but what?
Then somebody (Riccardo Cambiassi aka Bru, if I am not wrong) talked about noise pollution… and I realized that, if we were confortable in getting some QUALITATIVE audio data, and not real decibels and real noise, every laptop had a microphone…

I am quite good in playing with audio stuff, being a musician, and I knew I would have had an impressive reference in Antonio Tuzzi, another OS registered developer, which BTW was busy writing CoreAudio in Cupertino some ten years ago, and then wrote other stuff like Protools (from which comes his nickname, “Protuzzi”). Damn, I thought, I HOPE both of us will be able to measure an audio RMS value, huh? :)

The demo, which I called NoiseSpime (some says I have a knack for names…), was really fast and fun to write. I usually write in C++ and Digital Mars D (never heard DMD? have a look, trust me), and sometime in Java, having seen Python just every now and then. But, to write such a simple code, you don’t need to be a language guru, let’s face it. And, oh my, Python just WORKS… and there are LOADS of libraries over there…

I wanted something cross-platform, so I preferred the somewhat clunky pyAudio library to other audio libs because this one is supported under OsX, Win and Linux. Then, in the first version, the NoiseSpime had a GUI, based upon pyWidgets (which is the Python port of wxWidgets), which I developed cutting and pasting example code. I LOVE cut and paste and DUMB, BEER PROGRAMMING… :) I usually write harder, bigger stuff (eye-tracking apps right now, for the records), so writing small things is a joy.

Too bad, we had to drop the GUI because of some problems with OpenSpime library, which is also why it is good to write demo code. So we decided to go naked for the show. We removed the GUI and Rob fixed my code and turned it in a decent OpenSpime command-line app.

He also put up the scopenode and mashup with Google Maps, in which you can see the RMS level collected by the NoiseSpimes running around the world.

And, guess what? It Works. It worked out of the box, guys. This is somewhat strange for a C++ developer: NOTHING works out of the box, normally. I LOVE this stuff. I was so amazed I even believed for some minutes I could go Python, and Ruby, and all those too-easy-to-use languages, but then I remembered we are here to suffer and got back to C++ (just kiddin’! Hey, pythonists over there, don’t get me wrong… I KNOW no language is “too easy to use”… :))

Finally, we put all the stuff under SVN on Google Code here:

http://code.google.com/p/noisespime/

and made a really nice ZIP for David Orban, which he installed and excellently demoed at Frontiers ‘08 in his speech about OpenSpime. Mission accomplished!

At last: because the NoiseSpime has no GUI anymore, but I wrote a decent text for the About Box, I think I will end this article with another cut and paste… Good Spiming everybody!

Aaron Brancotti aka Babele Dunnit
http://www.babeledunnit.org

————————————————

This is a small app to (somewhat) measure noise pollution and send data to OpenSpime servers.

It uses the microphone of your computer to sample ambient sounds, calculates the RMS value of the noises and sends the value to the servers (the RMS only, NOT the sounds… please check your microphone and set levels with the audio tools of your OS)

Also, it sends geolocation info, i.e. the latitude and longitude of the spot being monitored, which you specify in those two nice fields (yes, YOU must figure out the coords… Google Earth is your friend!)

So what?

Well, the idea here is to use the OpenSpime protocol for data communication… which is a standard, secure, encrypted, robust, reliable, flexible, open source and FREE (is that enough?) way to approach the forthcoming Internet Of Things.

This is just a demo: the numbers you will send are NOT decibels, so this is just a QUALITATIVE approach. A REAL noise pollution measurement device would imply calibration, filtering, certification etc.

So, just pretend this is one of THOUSANDS of small hardware devices, scattered around with impressive geographic density, detecting and sending data where you want, the way you want.

This - geolocated ambiental monitoring - is just one example application. But OpenSpime is much, much more powerful. Who know which sensors will your cellular phone soon have?

We Love Being Open. So, if you plan to put on the Internet your fridge, some thousands of sensors, or just another rabbit, please don’t reinvent another closed, proprietary protocol. Do yourself a favour and take a look to OpenSpime.

————–

I’ve been working on a Sourceforge project called ScenConnect, and I am interested in investigating OpenSpime as a prime component its intercommunication layer.  First, I’ll briefly describe ScenConnect. Then, I will explain why OpenSpime could meet ScenConnect’s intercommunications needs.  Finally, I’ll describe a partnership for further building the spime ecosystem.

Scenario connectors are tools for rapidly constructing scenarios out of tags, scoring the desirability of scenario outcomes, and then matching those tags with those found on spimes, providing information about decisions needing to be made that match the surrounding environment.  ScenConnect is a Sourceforge project that is attempting a preliminary implementation of such a scenario connector.

Scenario connectors have many distributed communications needs.  Scenario connectors need to be able to receive authenticated information from spimes.  The scores (opinions and preferences) attributed to a given user have to be verifiably from them.  Scenarios might only be shared with a limited group of other users, and need to be encrypted.  The secure lightweight namespace provided by OpenSpime can be employed to these purposes to an extent, and it seems clear that further development of the capabilities of OpenSpime may lead it to being a reasonable underlying protocol for scenario connectors, generally speaking.

The development of each project only adds to the capabilities of the others.  C2O sensors and other OpenSpime content providing projects only add to the content that can be tagged, scored, and deliberated in a scenario connector.  Furthermore, the analytical capabilities of the scenario connector only improve the likelihood of important data to be indexed, evaluated, and deliberated in its proper context.  Given these mutually reinforcing capabilities, I promote the development of a project that will plug into ScenConnect’s distribution interfaces implemented on top of OpenSpime.  Furthermore, I see the OpenSpime project as a partner project in implementing the spime vision, and hope to work with OpenSpime project developers in situating their data.