tdat v3-6

Look to my previous two blog posts for details, if you're confused or would like to see some more background.

The Data and Tension (hereon abrev. 'tdat') has gone through several more iterations of sourcetexts and accompanying rulesets. I've tested almost all of these on groups of four, and a few on groups of two and three, despite that the rulesets are designed with four in mind. Using fewer players than the rulesets provide for causes problems like loops and truncations. To come up with rulesets, I used some simple software tools for frequency analysis of words in the source text, but the vast majority of the work was done by hand on graph paper.

an example of my awful handwriting

an example of my awful handwriting

The process of crunching these matrices out by hand is extremely labor intensive. However, this proved to be the best method as it gave me the most hooks into the ruleset. Slight changes in the balance of these matrices can sometimes yield very different (and occasionally unuseful) results. Designing the game is a game itself!

another hand drawn matrix

another hand drawn matrix

It had been suggested a few times that a piece of software could be designed to write these rulesets. While at first, the thought of doing so seemed ridiculous (the piece is, after all, meant to pull me out of the computer!), after doing eight or so of these (with six different sourcetexts), I have decided that there must be a better way.

Plus, drawing the matrices is the easy part, believe it or not. The hard part has consistently been testing rulesets for brokenness. It is surprisingly difficult to find two to four people who want to give you the amount of time and effort it takes to test one of these, and even when there's support, finding a suitable space to do this in is equally daunting, if not more so. There must be a better way.

So I've written a SuperCollider class library for simulating these pieces. It may be found here. It consists of two classes: a player and a game. Games contain an array of their players, and the source text. Players contain their rulesets, and information about their reading state.

The important aspect that distinguishes this game from other games is that turns are not taken synchronously. Players are instructed to read "over" one another and many times the rates at which they read are potentially variable and unique. The solution to this was to implement a "turn" method for players that encompasses all aspects of taking a turn (ie saying a word) and allow forked processes to call this method decoupled from each other. Since SuperCollider is interpreted, the classes are compiled to the interpreter while the hook into the controlling processes is interactive. Here's an example of an application script, which gets run interactively from within the SC environment.

This is going to totally invert the way I've been working. Instead of starting with the sourcetext and arriving at dynamic behaviour through rulesets, I can engineer and test the kind of dynamics I want, and fill in the words later.

As far as representing the data meaningfully, I am currently looking at sonification as a strategy. Visualizing may also work, but it's going to have to be multi-threaded. The test script is pretty unclear because each player posts to the same window. For now it's a lot easier to detect loops and other issues.

On Tuesday, I tried out version 6 (my favorite sourcetext) with a group of four players, with the sections projected rather than on printed paper. While this had the potential to be more intelligible to the audience, the lack of space kept the players from really moving around. Instead, the effect of having the text projected was to cause people to speak louder as the activity became more dense. Two points proved salient from that experience: first, the text should be in outline form, like the first few iterations of the piece, and second, to try rules that forced players to stop reading.

Leave a Reply