[previous post wiped]
Good lord I'm so retarded. There's nothing wrong with saveStrings or my program. I was looking at the screen counter in the text files. They were still 20,000 lines long.

I'm saving four values each time a box goes off of the screen. Just now the program has poured out 14 files at 300k a pop in one minute. I'd like the program to run all day. Is that possible (will saveBytes cut things down?) or am I just dreaming?

My understanding of these things is hideously basic. I'm confused by the three saveStrings functions in the mother code. I know about being able to call methods the same name providing the parameters are different but I can't figure out which way the ball is being passed.
Code:

public void saveStrings(String filename, String strings[]) {
  try {
    String location = savePath(filename);
    FileOutputStream fos = new FileOutputStream(location);
    saveStrings(fos, strings);
    fos.close();

  } catch (IOException e) {
    e.printStackTrace();
    throw new RuntimeException("saveStrings() failed: " + e.getMessage());
  }
}
static public void saveStrings(File file, String strings[]) {
  try {
    String location = file.getAbsolutePath();
    createPath(location);
    FileOutputStream fos = new FileOutputStream(location);
    saveStrings(fos, strings);
    fos.close();

  } catch (IOException e) {
    System.err.println("error while saving strings");
    e.printStackTrace();
  }
}
static public void saveStrings(OutputStream output, String strings[]) {
  PrintWriter writer =
  new PrintWriter(new OutputStreamWriter(output));
  for (int i = 0; i < strings.length; i++) {
    writer.println(strings[i]);
  }
  writer.flush();
}
 

I gather if I keep streaming to the file I'm going to have to close it at some point. I may just have to go with hammering the hard-drive with data, since my variable numbers are too big to byte-wise. (I will have to stop the screen counter at 2147483647 anyway).

Incidentally I noticed a ZipOutputStream class as I was sifting through Java documentation for ideas. Would that work in a similar fashion to the saveString methods above?
More importantly, have you ever thought of adding this to Processing? This is a very nice platform for creating lots of data about graphic operations and such. (I'm also thinking that my understanding of compression and archiving is probably, err, definitely naieve).

http://www.robotacid.com/PBeta/boxdemo.html

It's a Golan Levin (Messa Di Voce) Jared Tarbell (Box Fitting) Angela Bulloch type piece. The idea is that viewers will interrupt a blank projection and see mouths emerge and boxes rise up based on the darkness of pixels. (I had to change the code to read the distance to the mouse as PGraphics2 was being a git.) I also hope to have microphone disturbances push the colour selection round. When the boxes rise off screen their parameters are written to file.
Code:

if(!calibrate){
  //screenCount, x location, size, colour
  record[recCount] = scrCount+","+b[i].x+","+b[i].size+","+b[i].c;
  //println(scrCount+","+b[i].x+","+b[i].size);
  if (recCount == 20000){
  System.arraycopy(record, 0, saveBlock, 0, 20000);
  saveStrings("log"+(++saveCount)+".txt", saveBlock);
  println(saveCount);
 }
 if (recCount == 0){
  System.arraycopy(record, 20000, saveBlock, 0, 20000);
  saveStrings("log"+(++saveCount)+".txt", saveBlock);
  println(saveCount);
 }
 recCount = (recCount+1)%record.length;
}
 

So viewer interaction with the piece creates one great long ticker tape spew of colourful boxes.

Problem is... I ran the program for a minute and it chucked 14 300k files into the sketch folder. Screen count goes up forever, x location is limited to a possible 20 locations (the number of emitters), size goes upto 10 or 20 and colour has 256 values. I could turn the latter values into bytes, but I don't know about the screen count.