First beacon
This simple server, that I now call a 'beacon' and which stores and broadcasts a sequence of nine integers, was developed for my project imposition. The idea was simply to be able to reflect certain states of a digitally mediated literary process and then allow an arbitrary number of other such processes to subscribe to the server or beacon, collect the states, and so respond concurrently - allowing for indeterminate network lag - to the states of the focal process. When imposition was made, I initially thought of the focal process - the one that generated the main projected and sonified display - as sending its states to the beacon from which they were then selectively collected by 'listening' processes running on any networked device. Specifically, networked laptops in the audience or in the vicinity of an installed focal display could be linked to the piece as part of its system, coordinated by the beacon. My collaborator for imposition, Giles Perring, composed a musical schema for the piece such that it would always be harmonically engaging when arbitrary numbers of listening processes were paying selective attention to the shared states of the system and responding in terms of organized sound.
Later I realized that it would be simpler and more efficient if the beacon itself generated the shifting patterns of states that I had contrived to match the literary and sonic structures of imposition's constituent parts. But this was strange. Now, what I'd been calling the focal process - the one driving the main display - was also, itself, 'listening' to the beacon. In the case of imposition the only difference of response between the focal process and the other listening processes was that the focal process responded to all of the state variables whereas imposition's other listeners only paid attention to one or two of eight.
It seemed possible to think of the main engine of the work as being the beacon itself and then, because the beacon was and is so simple, it was possible to conceive of it as having listeners of any imaginable kind, responding in any conceivable way.
Today the beacon still runs, more or less continuously, on a server at Brown University, although it could, of course, be anywhere on the Net. If you hit <http://beacon.literalart.net> you will first be redirected to the current location of the server and then your browser or other networked process will receive back a string in the following form:
<n>0</n><n>2</n><n>1</n><n>0</n><n>1</n><n>0</n><n>2</n><n>1</n><n>1</n>
... nine numbers delimited by xml-style tags.
Below I will give a relatively abstract description of what, in terms of an articulated temporal process, these numbers represent, in the hope that anyone so inclined may make 'listening' processes of whatever form and in whatever media that are responding to the beacon but in a manner that is appropriately articulated in terms of the behaviors of the listener's own particular process. If a number of makers produced different works in different media that all listened the beacon, they might then exhibit loosely coordinated, concurrent behaviors.
For the gallery and realtime writing event 'Streamflow Conditions: charting a poetics of language, code, and networks' + 'Timestamp: 24 hours of networked writing' both curated by Judd Morrissey at the invitation of Subito Press in Colorado <http://streamflowconditions.subitopress.org/>, I myself, for example, developed a new process that responded to the beacon while also engaging with the procedures of 'Writing to be Found' that I continue to explore as a practice of writing with=against the Google search engine and its corpus <http://netpoetic.com/2009/10/an-edge-of-chaos/>. This is just one more example of innumerable processes that could be constructed in relation to the beacon. It occurs to me that someone could build a physical computing device or program an existing device to respond to the beacon. If this speculative device had been operating during my beacon-driven performance for 'Timestamp' (Sunday, Dec 6, 2009 2:35pm-6:35pm US:Eastern Time; UTC-5) there would have been a coherence between its behaviors and the ways in which I was writing.
<n>#</n> - The Numbers
The first of the nine numbers refers to or changes the state of the beacon itself. You may access this number in certain ways using a simple webpage called the lightHouseKeeper <http://lhk.literalart.net> further described below, but, for the moment, I would prefer that listening devices simply polled the beacon and collected the other states, ignoring this first number.
The remaining eight numbers are divided into two groups of four. (If we call the first number between <n> tags element 0, then the first group of numbers consists of elements 1 thru 4 and the second 5 thru 8.) Within each group of four the rules for the way that the numbers may change are the same. Thus (and this is for contingent reasons relating to imposition) you might think of the numbers as articulating the states of either four similar sub-processes with the beacon providing two of its states (paired elements 1 and 5 for the first of the four sub-processes, for example) or, if you preferred, eight sub-processes, four of which have a certain range of states and the other four a different range (although you should note that they are interrelated as described below).
In any case, elements 1 thru 4 may have integer values between 0 and 5 inclusive. Within this range, 0 thru 2 occur with significantly greater frequency (see the weightings in the grammars below) than 3 thru 5.
Elements 5 thru 8 may have integer values between 0 and 2 inclusive.
Periodically, the values of all the elements 1 thru 8 change, and the interval during which they remain the same varies, depending on the values themselves. There is a nested structure of intervals before changes occur. After shorter intervals, relatively subtle, grammatically controlled changes occur, but these are overridden by more 'dramatic' changes occurring after longer intervals.
In more detail: It is easier to begin with the elements 5 thru 8. Whenever a shorter interval comes to an end, so long as a longer interval has not also come to an end, these change their values according to a grammar that is based on a key composed from the previous two values of each element, as follows:
{ <00> [2] 0 | 1 | 2}
{ <02> 0 | [2] 2}
{ <01> 0 | [2] 1}
{ <20> [2] 0 | [4] 1 | 2}
{ <22> 0 | [4] 2}
{ <21> 0 | [4] 1}
{ <10> [2] 0 | 1 | [4] 2}
{ <12> 0 | [4] 2}
{ <11> 0 | [4] 1}
The keys are in <> brackets. Thus, the first rule means: if the past two values of the element were 0 then new value will be 0, 1, or 2 but another 0 will be twice as likely as either 1 or 2. This is the meaning of the figures in [] brackets which allow us to weight the probability of a replacement value. As another example, the final rule means: if the past two values of the element were 1 then the new value will be 0 or 1, with 1 being four times more likely.
The values of elements 1 thru 4 also change after each shorter interval unless a longer interval has ended, but according to a slightly more complicated grammar. Here the key is made up from the key for the past two values of the correspond 5 thru 8 element (element 1 corresponds with 5, etc.) plus the past value of the 5 thru 8 element in question. The complete grammar is at the end of this text. Here, for now, are the first and last rules with explanation:
{ <000> [4] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
...
{ <115> 0 | 1 | 2 | 3 | 4 | [4] 5}
First rule: if the past two values of the corresponding element in the range 5 thru 8 were both 0 and the last value of this element from the range 1 thru 4 was also 0 then this element will be one of 0 thru 5, with weightings indicated in [] brackets, i.e. another 0 is 4 times as likely and either of 1 or 2 are twice as likely. The other (last) example rule is the same except the the past values of the corresponding 5 thru 8 element were both 1 and and the value of the element in question is 5 with the result that it will be replaced by any value between 0 and 5 inclusive, with 5 being 4 times more likely than the others.
Once the new values are assembled the shorter interval of time until the next change of state is calculated as: 20 seconds plus 5 seconds for every value of 1 and plus 2.5 seconds for every value of 2 in the range of elements between 5 and 8.
Every 120, 150 or 180 seconds or so, there will be a more dramatic change in the values for all the elements. The length of any subsequent longer interval of 120, 150 or 180 seconds is chosen pseudo-randomly. I say 'or so' because after the longer interval has past, there will be a relatively indeterminate remainder of some concurrent overlapping shorter interval that has not yet ended and so no dramatic change will take place until this also runs out. When a dramatic change occurs all of the elements 1 thru 4 are set to the same pseudo-randomly chosen integer between 0 and 5 with the constraint that the value chosen must previously have been that of at least one of the elements in question, and all of the elements 5 thru 8 are set to the same pseudo-randomly chosen integer between 0 and 2 with the same constraint as for elements 1 thru 4. In addition the length of the shorter time interval is doubled so that this 'dramatic' state will persist for at least 40 (if 5 thru 8 are 0), 80 (if 5 thru 8 are 1) or 60 seconds (if 5 thru 8 are 2).
That is a more or less complete description of the beacon in expository prose, seemingly far more complicated and elaborate than the beacon per se. My hope is that this description will not be too daunting and that other practitioners may be tempted to make processes that listen to the beacon and respond in a way that, if it does not, in itself generate significance and affect, nonetheless structures any significance and affect pertaining to the processes themselves in a manner that will, necessarily, correspond with any and all processes that are also listening to the beacon. At stake is the possibility that such correspondences might, in turn, be themselves generative of further significance and affect.
In case this in not already clear, this description is an invitation addressed to other makers to produce work for the beacon and to correspond with me in order to set up events and installations during which processes in widely various media may perform in relation to the beacon.
There is also a webpage with a simple interface to the beacon at <http://lhk.literalart.net>. Using the interface's 'poll' button you may simply watch what the beacon does. You can also start or rather reset the beacon (to 000000000) and stop it or rather set it to the special value (of 000002222) for 30 minutes. (Please use this stop button with discretion - someone might be using the beacon for a performance.) Some of the legends on this webpage relate to my own recent uses of the beacon for imposition and may not be very helpful for you. The six buttons at the bottom of the interface set the beacon to various dramatic states, all with the 5 thru 8 elements set to 1, and values of the 1 thru 4 elements being selectable by each of the six buttons.
— John Cayley, Nov 25, 2009-Nov 2010.
Note: As an example of how I have used the beacon, in the case of imposition, the 5 thru 8 elements indicated what I called, metaphorically, the legible 'buoyancy' of four separate passages in the piece: 0=floating, 1=surfacing, and 2=sinking. The 1 thru 4 elements indicated, for the values 0 thru 2, three possible language states: 0=German, 1=French, and 2=English. The values 3 thru 5 in these same elements evoked alternative, less frequently seen texts in the same three languages: 3=alternative German text, 4=alternative French, and 5=alternative English.
Complete Grammar for the 1 thru 4 elements:
{ <000> [4] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <020> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <010> [4] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <200> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <220> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <210> [4] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <100> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <120> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <110> [8] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <001> [2] 0 | [4] 1 | [2] 2 | 3 | 4 | 5}
{ <021> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <011> [2] 0 | [4] 1 | [2] 2 | 3 | 4 | 5}
{ <201> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <221> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <211> [2] 0 | [4] 1 | [2] 2 | 3 | 4 | 5}
{ <101> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <121> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <111> [2] 0 | [8] 1 | [2] 2 | 3 | 4 | 5}
{ <002> [2] 0 | [2] 1 | [4] 2 | 3 | 4 | 5}
{ <022> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <012> [2] 0 | [2] 1 | [4] 2 | 3 | 4 | 5}
{ <202> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <222> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <212> [2] 0 | [2] 1 | [4] 2 | 3 | 4 | 5}
{ <102> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <122> [2] 0 | [2] 1 | [2] 2 | 3 | 4 | 5}
{ <112> [2] 0 | [2] 1 | [8] 2 | 3 | 4 | 5}
{ <003> 0 | 1 | 2 | [4] 3 | 4 | 5}
{ <023> 0 | 1 | 2 | [2] 3 | 4 | 5}
{ <013> 0 | 1 | 2 | [4] 3 | 4 | 5}
{ <203> 0 | 1 | 2 | [2] 3 | 4 | 5}
{ <223> 0 | 1 | 2 | [2] 3 | 4 | 5}
{ <213> 0 | 1 | 2 | [4] 3 | 4 | 5}
{ <103> 0 | 1 | 2 | [2] 3 | 4 | 5}
{ <123> 0 | 1 | 2 | [2] 3 | 4 | 5}
{ <113> 0 | 1 | 2 | [4] 3 | 4 | 5}
{ <004> 0 | 1 | 2 | 3 | [4] 4 | 5}
{ <024> 0 | 1 | 2 | 3 | [2] 4 | 5}
{ <014> 0 | 1 | 2 | 3 | [4] 4 | 5}
{ <204> 0 | 1 | 2 | 3 | [2] 4 | 5}
{ <224> 0 | 1 | 2 | 3 | [2] 4 | 5}
{ <214> 0 | 1 | 2 | 3 | [4] 4 | 5}
{ <104> 0 | 1 | 2 | 3 | [2] 4 | 5}
{ <124> 0 | 1 | 2 | 3 | [2] 4 | 5}
{ <114> 0 | 1 | 2 | 3 | [4] 4 | 5}
{ <005> 0 | 1 | 2 | 3 | 4 | [4] 5}
{ <025> 0 | 1 | 2 | 3 | 4 | [2] 5}
{ <015> 0 | 1 | 2 | 3 | 4 | [4] 5}
{ <205> 0 | 1 | 2 | 3 | 4 | [2] 5}
{ <225> 0 | 1 | 2 | 3 | 4 | [2] 5}
{ <215> 0 | 1 | 2 | 3 | 4 | [4] 5}
{ <105> 0 | 1 | 2 | 3 | 4 | [2] 5}
{ <125> 0 | 1 | 2 | 3 | 4 | [2] 5}
{ <115> 0 | 1 | 2 | 3 | 4 | [4] 5}