all registered for the semester now. as mentioned on twitter, in at 11:00:03, done by 11:00:45. classes filled up very quickly. i’m really glad that i went to gordie’s registration session…he had some great tips which i think were crucial (although i won’t mention here – i may need them next semester :) )

after the past few days of getting to meet the other first-year students and fostering a collaborative community the though of cut-throat competition to get into my first-choice classes leaves me feeling dirty…

so, the schedule is pretty cool, classes tuesday – thrusday; some mornings, some evenings. now, let me get this freelance work out the door so i can focus on school next week.

today was orientation for ITP…all of us first year students got together to be welcomed by Red Burns and to introduce ourselves to everyone. there are so many really smart, really interesting people in this class, from all backgrounds and from all over the world. it’s quite inspiring to be a part of this community.

after the orientation pockets of folks hung around and got to know each other. we had some brainstorming, including creating a tattoo-based delivery system for generative drawings…it’s about the volunteer trusting the software with creating a permanent mark on them…intense…maybe we’ll prototype with a sharpie marker :) fun

finally got the iBike CSV file support added to Golden Cheetah. the issue revolved around line endings on the iBike file that a user supplied. the file had CR (old-style Macintosh) line endings, and QTextStream::readLine() doesn’t honor them…reading the entire file at once.

the solution was pretty simple: use readLine() THEN split(‘\r’) and loop through each piece. files with LF endings will be read in correctly, and the split will only result in one element. files with CR will be read incorrectly (as one big chunk) and then split into lines. the rest of the code is agnostic to the differences. snippet for reference:

        QString linesIn = is.readLine();
        QStringList lines = linesIn.split('\r');
        // workaround for empty lines
        if(lines.size() == 0) {
            lineno++;
            continue;
        }
        for (int li = 0; li < lines.size(); ++li) { 
            QString line = lines[li];

ok, back to packing for the move.

another headache with GoldenCheetah. trying to implement a new feature – support for iBike CSV files. these files have a bunch of configuration data at the top, which is easy enough to skip, but for some reason the QTextStream::readLine() function is loading the entire file rather than line 1 (at least according to what i gather from gdb).

i’d figured that it was a line endings thing (\r rather than \n or \r\n) however changing up the line endings in both a GUI editor nor via the command line (cat oldfile.csv | tr “\r” “\n” > newfile.csv) corrected the problem.

opening the file in TextWrangler, replacing the line endings AND trimming the trailing zeros from the data DOES work though…so what else is going on here? is the regex replacing other hidden characters? is the file write process doing something?

at the very least, i’m getting more comfortable with gdb.

i enjoyed reading about lissajous curves in brendan dawes’ “analog in, digital out”. specifically he was speaking about iteration and how altering one of the parameters of the algorithm can create vastly different output.

inspired by that here’s a sketch expanding the algorithm into 3d. not groundbreaking but it certainly looks pretty. following other’s example i was able to get openGL working in a browser, so the script runs quickly. the instructions and files for jogl are at https://jogl-demos.dev.java.net/applettest.html. i used the versions of jogl.jar, gluegen-rt.jar and applet-launcher.jar as found at java.net.

click-dragging the mouse will tumble the figure. zZ,xX,cC will decrease/increase the multipliers for the x,y,z components of the algorithm. the spacebar will clear the screen.

Lissajous 3D

playing with the 3d game of life sketch. i’m still looking to get the rules right, but in the meantime i’ve added a mutation. occasionally the upper rule changes which causes the cells to birth/die in sometimes drastically different ways.

also, the colors reflect the age of each cell; they progress from red to blue in the first 5 seconds of their life and stay blue until death.

the exercise for adding the colors was to see if adding additional properties to the “world” array would slow down the sketch. it seems to be running well. i think that i’d be able to store many more properties for each cell in the array. i’m not sure how much more i want to tinker with this current code…i’m going to do some research into other attempts at 3d game of life to see what successful rules have been determined.

in the meantime, does anyone have a 30x30x30 led matrix they’d like to run this on? (or any size really, the code is scalable).

I am coming to believe that the atmosphere at ITP is infectious. Every time I pass through there I come away with this bug to work on another project. I stopped by yesterday while I was in New York, ran into someone I had met at the spring show and had a good chat about the new games venture he and two fellow ITP alums have just started developing for the iPhone platform. I also finally introduced myself to Tom Igoe and did my best not to sound like an idiot. Also, also…I got a glimpse “under the hood” of the Wooden Mirror. While cleaning up my bookshelf I found a Computer Graphics magazine from 1999 which had Daniel Rozin and the Wooden Mirror on the cover. The inside blurb mentioned that it was being driven by a Macintosh Quadra. I was really curious if they really still had a Quadra running to power it or if it’s been upgraded to some type of embedded microcontroller in the past 9 years…well, it’s been upgraded, to a beige G3 tower.

Anyway, this time around after leaving ITP I wanted to play with Conway’s Game of Life. Although it’s been done many times before, I was looking to do it myself to practice working with arrays. Specifically, when working with images (and video) you can store the value for each pixel in a one-dimensional array by appending each row of pixels into one very long array. There is some math involved convert from x,y cordinates to the arrax index, but it’s nothing too difficult after you’ve done it once.

Back to Life (….back to reality?). Keeping track of all the cells in a Conway game of life in a one-dimensional array is very similar to working with video. It wasn’t too much trouble to work out by reading the rules and looking at other examples. I am far more interested in a 3D version of the game. This has also been done…but my challenge was to track all the cells for the 3D matrix in a one-dimensional array. The sheer number of values started to make my head swim when doing the mental math, but in hindsight it wasn’t much more complicated than working with 2D data.

So, in the end, the Game of Life isn’t the focus of this experiment as much as figuring out how to store 3D data in a one-dimensional array…which seems to be much faster than using a multi-dimensional array…but who knows…I never studied comp sci.

A link to the sketch is below, but for reference here is the math for converting between coordinates and the array index (sx,sy and sz are the respective sizes of the axes):

int coordsToIndex(int x, int y, int z){
  //convert from coordinates to the array index
  //use the plane first (z), then the row (y), then the column (x)
  return  z*sx*sy+y*sx+x;
}

int[] indexToCoords(int index) {
  //convert the index to x,y,z values
  int z = index/(sx*sy);
  int y = (index%(sx*sy))/sx;
  int x = (index%(sx*sy))%sx;

  int[] coords = {x,y,z};
  return coords;
}

Game of Life 3D
(Hint, use the up/down and left/right arrow keys to alter the minimum and maximum life rules, respectively)