So I deleted 97 feeds from my RSS reader.

What I’m bored of is people who don’t understand the difference between an artistic impulse and a technical idea. They are not the same thing. I also don’t have any great wish to see a large swath of poorly-done art, which is the category that a large amount of new media work falls into. This means that I can rule out seeing artworks that are described by any of the words “gestural control”, “GPS”, “Processing”, or “arduino”. These are technical terms, and as we don’t describe second-rate schlock movies as being an amazing use of processed nitrate film stock, those technical terms should be stricken from the description of any artistic endeavour.

*Disclaimer: there are some people whom I will still listen to their discussion about the technical nitty-gritty.

Spimes and RFID are only part of what I’m talking about here. Short-run publications, bespoke objects, and even distributed craft networks are also part of this new post-digital boom. There are going to be a lot of interesting tools for artists and designers to explore in the next decade, as we move away from computers being the site of the art (on websites) to being tools that enable interesting things to happen.

With this in mind, I’ve got three predicition for what the post-digital will be about:

1. It’s about fitting the digital into your workflow
2. It’s not venerating the things that are on our screens
3. It’s real-world hard work, and engaging with both hands

With this in mind, I looked back at my last decade and I thought about how my use of computers changed over that time. Do you remember using computers in 2000? I had to wrack my brains a bit, but here’s a personal timeline of digital use:

2000 – Started Foundation course. Used Kai’s Power Tools for the first time, made first video, got first real email address (by which I mean not a hotmail account)

2001 – First year of university. My first computer that was mine- a G3 desktop, zipdisks.

2002 - New computer – G4 eMac with OSX! Lots of browsing at uni, then taking software updates home on disks. Became expert on TWAIN, scanning, photoshop, and waiting for photoshop scanning to finish.

2003 – First external hard drive. Also brought Wacom tablet, midi keyboard (both mostly useless). Made videos, learnt non-linear editing software, wrote dissertation, stared out of the window a lot.

2004 - First broadband connection. Brought Max/MSP, downloaded Processing (alpha!), went on PD course. Still confused by all three ‘easy’ languages. Got Gmail account and my first laptop – a G4 powerbook.

2005 – Overused first broadband connection. Made some digital installations, brought Teleo card, got into electronics, nearly blew Teleo card up. Brought first iPod and Arduino.

2006 - Social networking via Flickr. Went on Arduino course in Barcelona with Massimo and David, gave up on Max/MSP and PD as patcher languages suck time, fun, and light from life.

2007 - Joined Twitter and Facebook. Facebook annoying from start. Finally buy proper domain name and start running my own website. Run the Glowbikes project, using SpokePOV’s as part of an art installation.

2008 – Powerbook dies, replaced with MacBook. Attended geek conferences, wrote and taught two courses for wordpress, made serious effort to learn Processing (which is then forgotten) and brought iPhone.

2009 – Discovered international roaming charges. Erk. eBay’d and sold things on Amazon, wrote thematic blog posts, and interviewed serious hacker-types.

2010 - Now.

Above: The Soul of a New Machine

Isn’t that what the world of programming is like though? It’s ninety-five percent unthreatening typing activities, with a final five percent of 1970’s punk behaviour. And I mean really punk – it could be anything from low-level annoyance to core-wars style worms that destroy all information. This makes programming mostly harmless, just like the pipe-wrench is mostly not deadly.

For me, the work on this project has been really slow going, and I’ve found it very long and arduous to work with the code in this fashion. One of the earlier references in this series of posts was the book Snow Crash by Neal Stephenson, where the major characters are confronted with a spreading virus that destroys the ability for people to speak, transfers a religious belief system into their mind, and makes them run off to join a weird cult. This gets referred to by one of the characters as neuro-lingustic hacking.

This project’s aim has been about using computer tools to examine my pattern of lingustic use. The resulting experimentation with code has convinced me that, in no small way, I should be concentrating on actually making bodies of text rather than dividing my time between attempting to code and and attempting to write. The idea of a reflective tool for text is still a fantastic idea that needs further experimentation, but I’m not sure that I can do it justice between my skill in programming and my desire to create well-crafted sentences.

To that extent, this module has been mostly harmless to me. I’m no longer interested in programming in the way that I was prior to starting it, but I’m not going to rule out the idea of finishing off this project (see the Evaulation PDF) later on in the year. But I can’t breathe true life into the project in the way that a good programmer can. The MV/8000, pictured at the top of this post, was made famous by Tracey Kidder in his Pulitzer Prize winning novel, Soul of a New Machine.

This book, so-titled because of the attention to detail that the dedicated team of engineers and programmers put into this early computer breathed life into a hard-pushed project, is a clear line of demarkation between between writing as an activity and programming. In-house documents from the producers of the MV/8000 (aka the Eagle) are nowhere near as exciting as Kidder’s prose, and would not have propelled either the Eagle, Kidder, or the cast of characters Kidder wrote about to anywhere near the level of fame and notoriety they still had twenty years later.

There will always be a need for textual framing of events, objects, and movements. In the next phase of my studies, I’ll be looking at the Star and Shadow’s volunteer workers, and framing that within a context of grass-roots arts activities, whilst working on the final project for the course. Both of these will projects will take the form of texts that can be read, so there’s good call for me to concentrate on something other than code. And, whilst one of my main aims when coming on the course was to develop my skills as a coder, finding out over the length of this module that I need to direct my energies into something else has been mostly harmless.

In this post I’ll be talking about the specific programming decisions and techniques I used. But don’t don’t get too excited – I’m pretty sure that the techniques I used are either hack jobs or very low-complexity stuff. My original idea was to create a program that read words and then sorted them. This is a very simple idea and does not have a great deal to explain; I wished to make the computer do the hard work of counting for me, rather than me doing the hard work for computers, as actually turned out in this module.

As the stated aim for the project was to read from a text file I assumed that the best way of doing this was to break apart the text and load it into a string array. One of the first big mistakes I made in this area was to assume that the string array would be a two-dimensional array – after all, I was counting lots of different things, rather than making something like a time-graph for one thing. Right?

No. A 2D array was far too complex for me, and didn’t actually do what I needed. If a regular (one-dimensional) array has storage for an item at each defined point, a 2D array has a list of arrays, each with storage at a defined point. That storage can be used for one defined type of data, like integers, floats, or strings. As I was determined to count specific words that I had chosen, the idea of a 2D array was overkill. Not only that, but the method I was using to break up the text and read it wasn’t really compatible.

Another big error was wandering into regular expression-land with a dazed look on my face. Perhaps if my project was more technically acute, there might have been some call for the use of regular expressions, but as the code was merely sifting through an array of strings it was much better to do a straight comparison using relational operators. In the current level of code I have been using an ‘if’ statement with a ‘directly equals’ (==) comparison.

I was convinced for a long time that regex was what I should be doing, but the documentation for regex is so dense and tough that I think you have to have some sort of special programming gene to be able to get your head round it. Every time I looked at it I found all of it so dense and unwieldy that I couldn’t get into it, and I found that the examples it came with were not something that really matched up with what Processing could use. The few times I did have success with regex and Processing were using the match() command, which seemed to behave in a way that I didn’t expect, although on closer reading of the documentation it was nearly as it said on the tin.

Moving onto discussion the actual production of a graphical output, this was something I started working on first. My working practice with Processing might not have been the most methodical, but I find that when I get stuck working on something within Processing I tend to pop open a new window and then start chewing on it in a separate bit of code. Pretty soon I have enormous amounts of windows open in Processing and I can’t remember what I was doing with half of them.

See what I mean?

For the graphical output I started working on modular blocks of code that I could call from elsewhere in the program. This approach mostly worked, but when I started compiling code together in one big bloc (what I’ve saved as version 3 in the repository of code) I found the way I had of fading in and out the text caused some sort of massive slowdown in the program.

After much experimenting the cause was not the fact that the text was fading in, but the fact that I had two different PFont’s being called, one inside a function, and one inside the main setup. Debugging this problem was pretty much the only time I felt successful at solving a problem during the entire run of the module, and after changing the way the typefont call worked the program was back up to speed.

Finally, after much unsuccessful toil and experimentation with what amounted to The Wrong Stuff, I ended up with a program that could count through a text and produce a small graph whilst doing so, and then output a text file that contained the ‘count’ of all the words searched for. This program, whilst technically fulfilling the brief I wrote for myself, is still a long way away from what I would like. For instance, the idea of changing the words searched for or the text would involve the user diving into the code and being prepared to edit it. This is not the ideal usage for most people, but as the code is written for a target audience of one (myself) I think I can handle it.

I have also not prepared a sketch to show what can be done with the output of the program as yet, despite making some mock-ups.  Here, however, is the original sketches from my notebook about the depiction of the program:

At some point in my research I experimented with using Apple’s Automator program to collate and collect text files from a specific directory. I was less than successful with this, and the results of the script actually ended up meaning I had to restart my machine. However, in the spirit of completeness, I am including those results along with my other code in this blog post.

Applescript application (OS X Only): basic-text-scan

Online repository of Processing Sketches for this project

ADDENDUM: Production list of Processing Sketches, in reverse order:

Buttons_test
Buttons_test-090428a.zip
I_dont_understand_match
basic_tech2
experimental_envisioning
fake_values
fake_values_2
match_test
orange_text_example
orange_text_example-090428a.zip
orange_text_test
orange_text_test.zip
printreader_again
printreader_again-090428a.zip
roma
roma_two
slight_succes2
slight_success
version_1
version_2
version_3
word_lines
basic_tech/.DS_Store
basic_tech2.pde
basic_tech/basic_tech2/basic_tech2.pde
Buttons_test.pde
conjoining_list.pde
data
basic_tech/Buttons_test/.DS_Store
basic_tech/Buttons_test/Buttons_test.pde
basic_tech/Buttons_test/conjoining_list.pde
Serif-200.vlw
basic_tech/Buttons_test/data/Serif-200.vlw
basic_tech/Buttons_test-090428a.zip
experimental_envisioning.pde
basic_tech/experimental_envisioning/experimental_envisioning.pde
conjoining_list.pde
fake_values.pde
basic_tech/fake_values/conjoining_list.pde
basic_tech/fake_values/fake_values.pde
applet
fake_values_2-090502a.zip
fake_values_2-090502b.zip
fake_values_2.pde
basic_tech/fake_values_2/.DS_Store
fake_values_2.jar
fake_values_2.java
fake_values_2.pde
index.html
loading.gif
basic_tech/fake_values_2/applet/fake_values_2.jar
basic_tech/fake_values_2/applet/fake_values_2.java
basic_tech/fake_values_2/applet/fake_values_2.pde
basic_tech/fake_values_2/applet/index.html
basic_tech/fake_values_2/applet/loading.gif
basic_tech/fake_values_2/fake_values_2-090502a.zip
basic_tech/fake_values_2/fake_values_2-090502b.zip
basic_tech/fake_values_2/fake_values_2.pde
I_dont_understand_match.pde
basic_tech/I_dont_understand_match/I_dont_understand_match.pde
match_test.pde
basic_tech/match_test/match_test.pde
data
orange_text_example.pde
basic_tech/orange_text_example/.DS_Store
Georgia-Bold-16.vlw
basic_tech/orange_text_example/data/Georgia-Bold-16.vlw
basic_tech/orange_text_example/orange_text_example.pde
basic_tech/orange_text_example-090428a.zip
conjoining_list.pde
data
orange_text_test
orange_text_test-090513a.zip
orange_text_test-090525a.zip
orange_text_test.pde
positions.txt
basic_tech/orange_text_test/.DS_Store
basic_tech/orange_text_test/conjoining_list.pde
Georgia-Bold-16.vlw
it.txt
terribletest.txt
basic_tech/orange_text_test/data/Georgia-Bold-16.vlw
basic_tech/orange_text_test/data/it.txt
basic_tech/orange_text_test/data/terribletest.txt
conjoining_list.pde
data
orange_text_test.pde
basic_tech/orange_text_test/orange_text_test/.DS_Store
basic_tech/orange_text_test/orange_text_test/conjoining_list.pde
Georgia-Bold-16.vlw
it.txt
basic_tech/orange_text_test/orange_text_test/data/Georgia-Bold-16.vlw
basic_tech/orange_text_test/orange_text_test/data/it.txt
basic_tech/orange_text_test/orange_text_test/orange_text_test.pde
basic_tech/orange_text_test/orange_text_test-090513a.zip
basic_tech/orange_text_test/orange_text_test-090525a.zip
basic_tech/orange_text_test/orange_text_test.pde
basic_tech/orange_text_test/positions.txt
basic_tech/orange_text_test.zip
data
positions.rtf
positions.txt
printreader_again.pde
positions.txt
basic_tech/printreader_again/data/positions.txt
basic_tech/printreader_again/positions.rtf
basic_tech/printreader_again/positions.txt
basic_tech/printreader_again/printreader_again.pde
basic_tech/printreader_again-090428a.zip
roma_movie
roma_movie.pde
basic_tech/roma/roma_movie/roma_movie.pde
roma_two.pde
basic_tech/roma_two/roma_two.pde
slight_succes2.pde
basic_tech/slight_succes2/slight_succes2.pde
slight_success.pde
basic_tech/slight_success/slight_success.pde
version_1-090422a.zip
version_1.pde
basic_tech/version_1/version_1-090422a.zip
basic_tech/version_1/version_1.pde
button_class.pde
conjoining_list.pde
data
version_2.pde
basic_tech/version_2/.DS_Store
basic_tech/version_2/button_class.pde
basic_tech/version_2/conjoining_list.pde
basic_tech/version_2/version_2.pde
button_class.pde
conjoining_list.pde
data
version_3.pde
basic_tech/version_3/button_class.pde
basic_tech/version_3/conjoining_list.pde
basic_tech/version_3/version_3.pde
conjoining_list.pde
word_lines.pde
basic_tech/word_lines/conjoining_list.pde
basic_tech/word_lines/word_lines.pde

This list was outputted using the command “find basic_tech -exec ls  {} ; | open -tf” in the OS X Terminal.

The grandiose title of this piece could be read as a sign that I’m going to write about things other than relevant to the course. In general, I’m going to steer clear of that sort of approach in this piece of text. I am slightly tempted to do a cross-comparative chart of my mental state versus the deadline of this module, but the time for that sort of navel-gazing isn’t now, and this isn’t really the place. So, what to do with such a grandiose title?

I know: we’ll talk about Lev Manovich.

Manovich is famous for putting together two things. First, his book, the Language of New Media, which was an early foray into series notions about the academic reception of New Media artworks. It’s aligning of the concepts behind computing as being analogous to early cinema was a masterstroke of metaphor, allowing humanities departments the world over to finally get their head around the fact that yes, really, we are going to be using these computer things for artistic purposes and we better get used to it.

The other thing that Manovich is famous for is his de/reconstructed film software “Soft Cinema”, which puts into practice the more theoretical notions that he talks about in his book. This work was, in fact, shown in the Baltic at an early stage in it’s gestation, where I walked in and then promptly walked out again (having a very low tolerance for the sort of abstract narrative found in most art films).

But these are not the features of Manovich’s practice that I’m going to discuss here. In his recent work, Manovich has looked at the way that society is pressurising all information onto a digital plane, and concluded that as more raw data is available in this form, it is the practice of data-mining that will become valuable. This is a conclusion actually being reached independently in several different structures at the same time, by researchers working in different fields.

This polyphyletic idea is ideally suited to Manovich’s position as somebody who can talk about the practice of art and computers in a way that those working in other fields can’t. For instance, whilst both Martin Wattenburg and Ben Fry are creating, promoting, and even working as artists in these fields, they still do not have the necessary academic chutzpah to propel the idea under discussion out of the ballpark. They are, essentially, knocking the idea around between a few like-minded friends.

Franco Moretti is not a like-minded friend, nor is he particularly interested in what we would term “New Media” (from what I can make out, which should be regarded as limited). However, what he is interested in, as a leading left-wing literary critic, is a method of understanding texts. And, as Manovich would point out, these texts are merely data awaiting transmutation into a computerised form. Therefore, coming to the point and the birth of yet another instance of our polyphyletic idea, Moretti suggests the use of quantitative data analysis for literature in his book “Graphs, Maps, Trees”.

I find the fact that infovisualization is being suggested as a research tool in the humanities as particularly interesting, and when I attended a recent afterparty for a Newcastle University conference on Crime Fiction I had a chance to quiz those doing stylistic analysis of texts in other fields. It was regarded as impossible that a visual program could be analysed by a computer (not so, either by using jit.cv or by web services such as Mechanical Turk). But I’m not sure that these people were participating in leading edge research, and besides, I was being plied with mohitios at the time.

The final point of this is, however, that there will be an expanding bubble of interest around these themes of data-mining and the humanities, and that Newcastle University already has some projects and researchers that are interested in this field (by which I am not referring to myself, but rather people working within the English department whom I’ve met very briefly). There needs to be a way of gathering the tools, or creating accessible tools for these researchers, and as soon as possible, so that Moretti’s idea of quantitative tools for qualitative purposes can become a reality.

Having said that, I’m now ready to share my own set of quantitative tools. Be aware that this is a rough and ready – but working – version, and merely produces a small line-graph and a text files that counts specific words. In the next section of this (essay? Series of blog posts?) I’ll discuss the road not taken, by which I mean the false starts and horrific crushing disappointments of working in code.

orange_text_test

I’m putting this up because my mum told me she liked it. Thanks! It’s a video made with the programming language Processing, inspired by the work of Douglas Coupland.

It doesn’t work.

However, this is a defeatist attitude. Not quite as defeatist as I’ve been considering (it doesn’t work, I’m never going to understand regex, and I’m going to stop bothering with programming being the other considered viewpoint).

On the other hand, sometimes the ways that it doesn’t work make no sense to me. For instance, one piece of code I wrote matched the string being read to a specific string, and incremented a counter once using the ‘++’ function. Except that it didn’t, it decided to increment the counter 559 times, and then it decided that all the words I was looking for were all there, 559 times.

Back to the drawing board from that code then. I really thought that loop was going to work as well; it had all the indications of when and where, as it cycled through the newly created string array that contained the compartmentalised (granulised?) longer string.

Then, when that failed I was back at regex. And I now hate regex deeply and purely, for being such a dense science that needs introduction. A big ‘thanks’ to everybody who pointed me at the same damn impenetrable tutorial. I sort of wish I’d chosen to do a project with Arduino controlled rockets instead, because whilst rocket science might have a reputation for being hard it never involves typing a string of impenetrable characters into a search box and hoping against hope that this would be the last leap. (http://www.youtube.com/watch?v=1XBwWAu2a5U)

Even the more seasoned programmers threw some askance glances at my code when they saw the way that splitTokens() works – ie, you throw all the tokens you want to use to split up the text together in a big line. For me, this was the lump of code ” ,.?!;: “, which I’d inherited from Daniel Shiffman’s example code in “Learning Processing”. This actually made a lot more sense to me than the output of match().

According to it’s documentation, Match() outputs an array if the sequence searched for matches what is in the inputted string. It outputs a an array “if the sequence did match, an array is returned. If there are groups (specified by sets of parentheses) in the regexp, then the contents of each will be returned in the array. Element [0] of a regexp match returns the entire matching string, and the match groups start at element [1] (the first group is [1], the second [2], and so on).”

Okay: first problem. Putting parentheses in doesn’t make it work with multiple choices. I guess we can swap over to matchAll() for that, but without multiple parentheses and therefore multiple choices, what point is the items returned as an array? It could, surely, be a yes/no answer? In fact, it returns an array which flummoxed me for several days as I realised that no matter what I put into the string as input, it always returned the same value. Two.

Searching for the word ‘will’ in the phrase “Inside will a tag, you will find will will content” will only ever return the value of two. Or rather, the value of ‘yes’ transmuted into ‘two’ by way of the length of an array, which is an entirely erroneous way of doing it. Almost as erroneous as the previous way of counting through the text as a string and looking at each individual part and then counting them (again, erroneously – to the tune of 559). Balls.

In my presentation – which I guess I’ll be covering in Basic Tech II (The Poptart at the End of the Universe) – I was told by Atau that I was only a half step away from solving a few of the problems. Maybe. I can see a functioning end to this problem, just not from here. Should I use the match function and the logic structure that I’ve been working on? There’s no guarantee that the logic structure will even work (559!) Five-five-nine! My least best guess is that my Macbook wants to emigrate to the People’s Republic of China and move to computing division 559.

As part of my basic techniques module I wanted to work on something quite simple. I’ve broken it down into lots of smaller chunks, and this chunk that I’ve been working on refers to how you would move the data gathered from counting words within a text to a graphical display.

Here I’ve used a ellipse to represent a number between zero and three-hundred and sixty. The finished project won’t have that sort of word limit, and the use of an ellipse would not be a good design feature, but for the purposes of this sketch it works pretty well. Some of the important parts are that the sketch communicates the values from inside a for loop (which, in the final project, will count through the words of the document as an array), it uses rollover style data display, and it has a selection of choices from which you can pick to display different data.

Obviously, this is a mock-up in several different ways, and the data doesn’t actually mean anything – it’s more an experiment to see the data and see how it would be crafted in Processing. Some things that I’m not happy with are the immense amount of code that it takes to do the rollover affect (should that be a class by itself?) and the placement of the text above the smaller arcs. I also think that the actually main display could be better, by rounding off the value to a straight int rather than a four-point decimal.

Click on the image above to see the sketch in action and to download the source code.

What is the best way of storing a number next to a word?

I want to scan through a document and look for specfic words. I’ve stored the words in a string array. I thought that the best way to deal with the storage of the words would be to create a two dimensional array and store the words in the first array, and the amount of the word searched for in the second array.

This is not so good, actually, because I made a fatal misunderstanding about two dimensional arrays. The first array is more like an index, so where I thought I was creating…

word searched for     count
(and) (one)
(if)    (six)
(or)    (two)…

etc

I was actually creating a grid like so…

1 2 3 4 5 6 7 8 9 (number of words in conjoiner)
0 0 0 0 0 0 0 0 0 (first thing)
1 1 1 1 1 1 1 1 1  (second thing)

I’m still not at the stage where I’m understanding what is completely going on, but after a brief chat with Tom Schofield, whose project is doing much the same thing as mine (but perhaps more complicated) he pointed me to some examples in the Orange processing book.

Still not quite getting it to match though. Will have to work on that.

One of the things that I’m worried here is that I’m not getting enough room to play. I’ve come into the project with a defined outcome already, and that means that there is very little exploration. In some ways that is a good thing; I don’t end up messing around with for loops again, but in other ways it’s bad as I don’t get to, say, spend time creating a lovely fading display of all the words in the “pieces” array.

On the other hand, the side project with the buttons has made some forward progress. Using the same void bigtext() that I’ve written for the main project, I’ve linked the program together in a way that allows the buttons to change colour. So far, so plain… but! I’ve also solved the horrible slow text problem.

You see, I had two different types of text font, and I think that was slowing down the program immensely. I might do some tests to work out if this is so, but if it is the case, I might use a png file to generate the larger text wanted for the project, and fade that in and out using transparency.

orange_text_example-090428a

buttons_test-090428a

printreader_again-090428a

James Hugonin is an artist who lives in Northumbria, and makes paintings that reflect his surroundings by taking the predominant colour for each day and painting a square in that colour. This is very procedural art, and therefore it lends itself very well to make a computer program that does the same thing.

This would probably annoy the bejesus out of Hugonin. Sadly, this is not my concern, as this is another exercise set my Jamie Allan, my tutor. Obviously, if you’ve seen my last piece of work for him, you might be getting concerned that Jamie is actually running some form of art world Project Mayhem, and that all graduates of the DM course will be changing their name to Bob soon. This is probably not the case.

I am Pete’s complete lack of surprise.

If you’re going to procedurally fake something, why just fake one? Therefore I set the program to stop cranking out fakes at a thousand. The colour’s a bit off, as if Hugonin had suddenly found his Northumbrian idle surrounded by flesh tones, but it holds together. The video ends up being 8.20 long, with two “paintings” every second.