When starting this project, we really didn’t think that retrieving and inputing data would be the main issue we would come across. But of course, what you don’t think will go wrong, will go wrong. The main problem is around translating data into Open Sound Control (OSC) so it can be sent to Isadora where we are triggering sound clips that give instructions (the score). We want this to happen in real time and use a score of data where the information is updated regularly.
One idea in the beginning was to try to use Temboo, which is a website that has a library of APIs and will actually write code for you to use that API in a number of coding languages (SDK). One SDK is Processing, which in turn could then turn that API into OSC data. Or at least that was the hope. But the problem with Temboo is that most of the available APIs are not updated in real time or regularly or the ones that are require permissions. For example, one idea was to use Google Analytics and use the amount of traffic on a specific site as way of generating a number that would in turn play an instruction in the dance. However, getting permissions for Google Analytics actually prevents using this as a system. We would need to find a heavily trafficked sight that would be willing for us to use there data. Some of the Temboo APIs which are available and update in real time just don’t send enough data. One of these is the weather (temperature or severe weather warnings). But there is just not enough information coming in to change the score of a 15 minute dance piece. This data might work in other contexts such as determining something about the piece before it starts, or perhaps in a longer durational work. But in the process of changing a score in real time it is not as useful.
Other forms of data
Another approach we considered was GPS and how location of a person could change the score. However, GPS trackers tend to have a 60-200 feet of distance from the actual location. This means that location in a small space, such as a dance studio or theatre would not be tracked. But if someone was to get on a bus or travel around another place in the world, their information may be useful. But then there is a question of what these numbers are and if they are just slightly increasing and decreasing, would this make an interesting dance?
We found a source of satellite data from NASA that tracks the location and speed of various satellites. This site actually takes a list of data (http://science.nasa.gov/media/sot/tle/SMD.txt) and then calculates where the satellites are based on this data. It’s not real time but a real time simulator. So we found this data and we see how it changes on the website (the real time aspect is a seperate issue that we will need to address) but now we need to take this information and find a way to produce OSC data with it in order to create (trigger) the score within Isadora.
When it all works
Once we have this bridge from the web to OSC then we can open up more explorations of data sources. For example, there is a txt of Solar Wind from NOAA (http://www.swpc.noaa.gov/ftpdir/lists/ace/ace_swepam_1m.txt) that updates every minute. This could use the same technical set up but send a different data set (this is also the data used in Helen White’s piece Solar Wind Chime http://blogs.wcode.org/2013/08/solar-wind-chime-listening-to-the-sun-using-spacecraft-electromagnets-and-x-osc/). But of course, this leads us back to one of our original questions in this work – what kind of data do we need? And how will that data effect our score?