frey

Sun Run Sun

Yolande Harris, Netherlands Media Art Institute Amsterdam, Artist in Residence project Sun Run Sun, http://sunrunsun.nimk.nl.

I was brought on board this project to help out with Pure Data patch development and porting patches to work with PDa. Specifically, I was to:

• write a parser for NMEA data in Pd;
• help Yolande translate existing Max/MSP patches to Pd;
• figure out how to connect the NMEA parser to the sound patches (networking protocol);
• ensure sound works on the PDa version of Pd.

Development process

Early on we needed to get started on sound development and translating Yolande’s existing Max/MSP patches to Pd, but in order to do this we needed an NMEA data stream to use as input. Since the Pd NMEA parser at that point in time was not working, I decided that the best way to go about this was to do the parsing in the existing Max/MSP patches, and communicate the data via this networking protocol to Pd. The protocol thus designed would then be used in the Gumstix version of the patches to communicate between the Gumstix’s GPS system and parser, and PDa, and could be suitably tested and prototyped in Pd on a Mac without needing a live data stream.

After beginning this step, I focussed on implementing the NMEA parser in Pd. As it turned out, the Pd NMEA data parser took at least 50% of the time, and went well over its time budget. This was for several reasons. First, the existing Pd NMEA parser was significantly more broken than anticipated, and had to be recoded from scratch. Second, Pd as a language is not at all suited to parsing text data, and so there were numerous issues and small bugs that were difficult to track down and resolve.

Messaging protocol

The protocol that we designed uses Pd’s FUDI protocol (messages sent as strings, terminated by ;<lf> (semicolon then line feed)). The actual message format is a key-word followed by one or more items of data, separated by spaces.

Messages are received on port 3005, UDP, and can have one of the following seven keywords: gsvframe, gsvsat, latlong, time, date, tracking, altitude. The format for each keyword follows.

• gsvframe <number of satellites in view>
• gsvsat <PRN> <elevation> <azimuth> <signal strength>

One gsvframe message is sent per GSV ‘frame’ (about one per second). Multiple gsvsat messages are sent immediately after this message, one per satellite in view.

• latlong <lat degrees> <lat minutes, integer part> <lat minutes, fractional part * 1000000> <N|S> <long degrees> <long minutes, integer part> <long minutes, fractional part * 1000000> <E|W> <A|V>

With the latlong message, the minutes is split into integer and fractional parts to preserve the accuracy of the reported data, given Pd’s 32-bit float limitation.

• time <hh> <mm> <ss>
• date <dd> <mm> <yy>
• tracking <speed> <track angle true>
• altitude <altitude in metres>

PDa and sound

I had previously built a version of PDa to work on OSX by downloading a source version, editing the makefiles (thus making them unusable on other platforms), and ignoring some errors that came up as best as possible. The resulting OSX version of PDa is not really in a suitable state for distribution because of these issues.

But once this was working, with sound working via the Darwinports version of the Esound Daemon, it was a relatively simple step to get the patches working under PDa. We had some issues with some parts of the patch not making sound. By a labourious debugging process (involving connecting [env~] objects to [print] objects and feeding in audio sources to test whether they were getting good data) we were able to trace the issue to what seemed to be a broken [vline~]. Having determined this, I put together a pure-Pd abstraction that imitated the part of [vline~]’s functionality that we were interested in by using [line~] and [delay] objects instead. That solved, all our other sound issues were resolved.

Patch Design

I attempted to design the patches as modular and decoupled as possible, making as much use of externals as I could. To achieve the decoupling, the pure Pd NMEA parser is kept as a separate patch to the sound patch, and even when running in Pd-only mode the parser communicates with the sound patches through Pd’s [netsend] object.

The patches themselves are built in such a way that any repeated code has been abstracted out. For example the GSV sonifier part of the sound patch use multiple instances of the same [gsvtrackerlogic] abstraction, and the NMEA parser uses the [parsefloat] abstraction whenever it needs to parse a number from an incoming ASCII stream.

It seems, however, that at the moment the Gumstix version of PDa won’t load abstractions, and needs the patch it as running as a single monolithic patch with no abstractions. If this issue is not resolved it could make code maintenance much more difficult, as bugfixes made to one [pd gsvtrackerlogic] subpatch inside the main patch would have to be copied by hand to each other place that subpatch appears, manually, which leaves too much room for oversight or error.