Some new appearances on github/ideoforms:

• SuperCollider client for Processing: the library formerly known as p5_sc, cleaned up and rebranded ahead of the release of Processing 2.0.
• sc-monome: SuperCollider classes for interfacing with various Monome controllers, polished and belatedly version controlled.
• python-twitter-examples, a collection of examples using Python Twitter Tools for social data mining, developed for the Centre for Arts and Social Technology MA laboratories.

I don't make a habit of posting compilation gotchas, but this one was a phenomenally unpleasant time drain. Looking to interface python with MIDI on Snow Leopard, I came across pyPortMIDI, based on part of PortMedia.

Compilation seemed OK, following these hints (also found in pm_python/hints.txt in the portmidi dist), but running the pyPortMIDI test.py script returned the following:

Traceback (most recent call last):
File "test.py", line 11, in
import pypm
ImportError: dlopen(/Library/Python/2.6/site-packages/pypm.so, 2): Symbol not found: _Pt_Time
Referenced from: /Library/Python/2.6/site-packages/pypm.so
Expected in: flat namespace
in /Library/Python/2.6/site-packages/pypm.so

Following some excrutiating exploration with dtrace and nm, it transpired that it boiled down to an architecture issue: according to the portmidi xcode build file, /usr/local/lib/libportmidi.dylib was compiled as i386/ppc, but my system is 64-bit.

Solution:
* Open the .xcodeproj file in XCode, change the .dylib Target arch to x86_64, rebuild and install over the existing /usr/local/lib/libportmidi.dylib
* Clean up the pyPortMIDI build, rebuild and reinstall

Now working without a hitch.

Continuing the PEAL-related hackpact hacking, today saw the realization of the OSC protocol that the installation will use to communicate with the Processing visualization. As a testbed, this also entailed a Python script (making use of ixi's great simpleosc) to emulate the behaviour of the installation when it's in place - generating events such as clock ticks, bell chimes and aleatoric changes.

Coming from recent work in C++ and perl, it's continually surprising how things in python seem to just work - and moreover, how readable and maintainable the resulting code is. I saw a comment by somebody recently describing Perl as a "read only" language, which can be pretty on the money...

I'm out in the country for the next few days, mostly away from technology, so the next few hackpact entries will be manual hacks, broadcast via iPhone twitpics/twitvids - if signal reception permits.

As part of the Django/Twitter-based hackpact project mentioned yesterday, I need to be able to generically pluralize English nouns. This is a distinctly non-trivial job, given the vast array of irregularities and unusual inflections in the English language: think tooth/teeth, vertex/vertices, stimulus/stimuli, wolf/wolves, starfish/starfish, mother-in-law/mothers-in-law. The linguistics and algorithms behind this process process has been written about by Damien Conway for a related Perl module. Today, I have been porting the same process to Python, based on a simpler example from the Dive Into Python reference.

The datafile in its current format is attached. I'll publish the rest of the code (and reveal the underlying plan!) when the project is completely, hopefully in tomorrow's session...

It's rare for me to envy Windows users, but I have a long-harboured jealousy of the unofficial Python API for Ableton Live that's been available for the past year or so -- as I'm sure the reader would agree, there's little in life that could rival programmatical access to arguably the world's greatest DAW. So, it was to my joy that I discovered that an OS X version of this API was quietly announced just a few days ago, coinciding with me delving back into Python for an ongoing project.

Expect some monstrous hacks as soon as I have a free moment...