Information
Technology
Software
C
Descriptions & Essays
enter project here:
Scroll down to the bottom of the code to launch its results.
Commissioned by the Whitney Museum
ADA Editor 16-06-2015
Comment by John Klima:
"Something I have always loved about C is all the white space there is in the code, and Camille seems to have taken it to the extreme with her style. You open a page of C, and it's like a breath of fresh air. No offense intended, Camille, this is about conventions: I must say I find the naming convention of "MyFunction..." a bit annoying, perhaps because it reminds me of working for Microsoft where Hungarian notation was forced down my throat. Every stupid loop integer had to be named "for intI = ..." instead of just "i" and every string had to named something like "strFileBuf" rather than simply "buf." And the "My..." thing I've always found so infantalizing, "My Computer," "My Documents," my my my me me me. In all fairness however, the use of the "My" prefix does clearly indicate which functions are the programmer's overloaded ones, what are plain utility functions, etc. I just wish there were another way to effectively indicate it. Obviously, its a personal thorn in my side, stuck there by Bill Gates circa '93."
Camille Utterback:I think it's really fitting that you commented on my function naming (and that naming conventions have annoyed you in the past), given that your CODeDOC project was partially about playing with these conventions. I agree with you that the "MyFunction..." convention is a bit annoying. It was more of an attempt to distinguish what I had written from the ungainly Windows code for people that weren't used to looking at such nonsense. I'm curious how you normally name your functions -- given that it's something you have feelings about. Are your functions simple pared down descriptions, or do they always err on the side of humor (even when you're the only one to see them)? I often find myself coming up with odd amalgams of code/nature for my drawing functions: 'PeacockArray' or 'BezierFlower' for example.
ADA Editor: linescape.cpp, 16-06-2015, in: Archive of Digital Art Comment by John Klima:
"Something I have always loved about C is all the white space there is in the code, and Camille seems to have taken it to the extreme with her style. You open a page of C, and it's like a breath of fresh air. No offense intended, Camille, this is about conventions: I must say I find the naming convention of "MyFunction..." a bit annoying, perhaps because it reminds me of working for Microsoft where Hungarian notation was forced down my throat. Every stupid loop integer had to be named "for intI = ..." instead of just "i" and every string had to named something like "strFileBuf" rather than simply "buf." And the "My..." thing I've always found so infantalizing, "My Computer," "My Documents," my my my me me me. In all fairness however, the use of the "My" prefix does clearly indicate which functions are the programmer's overloaded ones, what are plain utility functions, etc. I just wish there were another way to effectively indicate it. Obviously, its a personal thorn in my side, stuck there by Bill Gates circa '93."
Camille Utterback:I think it's really fitting that you commented on my function naming (and that naming conventions have annoyed you in the past), given that your CODeDOC project was partially about playing with these conventions. I agree with you that the "MyFunction..." convention is a bit annoying. It was more of an attempt to distinguish what I had written from the ungainly Windows code for people that weren't used to looking at such nonsense. I'm curious how you normally name your functions -- given that it's something you have feelings about. Are your functions simple pared down descriptions, or do they always err on the side of humor (even when you're the only one to see them)? I often find myself coming up with odd amalgams of code/nature for my drawing functions: 'PeacockArray' or 'BezierFlower' for example.
ADA Editor 16-06-2015
Comment by Scott Snibbe:
Your piece brings back the fondest of memories from my childhood. One of the earliest graphical works that inspired me was a simple moire of diagonal lines, connecting respective x and y coordinates, that came with my apple ][. Your piece also reminds me of the videogame "Quix" where one had to slowly steal territory away from a line that is an early relative of your piece. Your work is a lot more sophisticated, of course. The fact that I still can't quite predict how the rectangles will be created from my clicks makes it interesting -- sometimes the most interesting work never quite resolves into a complete logical package. The code makes it clear that I'll never be able to predict the effect -- you add a random element into the choice of rectangle to manipulate. The way you wrote the code is so respectful -- your comments are like little poems that interact also with the poetry of your code -- it's really quite tender! Some of your other work involves poetry on the screen, but now I see you try to make your code poetic too. One note -- I struggled the first time I ran your program to quit! None of the usual ways of quitting worked for me - ESC, ctrl-q, ctrl-c, alt-w, alt-f/x. The code showed me I only needed to press return, which also makes poetic sense.
ADA Editor: linescape.cpp, 16-06-2015, in: Archive of Digital Art Comment by Scott Snibbe:
Your piece brings back the fondest of memories from my childhood. One of the earliest graphical works that inspired me was a simple moire of diagonal lines, connecting respective x and y coordinates, that came with my apple ][. Your piece also reminds me of the videogame "Quix" where one had to slowly steal territory away from a line that is an early relative of your piece. Your work is a lot more sophisticated, of course. The fact that I still can't quite predict how the rectangles will be created from my clicks makes it interesting -- sometimes the most interesting work never quite resolves into a complete logical package. The code makes it clear that I'll never be able to predict the effect -- you add a random element into the choice of rectangle to manipulate. The way you wrote the code is so respectful -- your comments are like little poems that interact also with the poetry of your code -- it's really quite tender! Some of your other work involves poetry on the screen, but now I see you try to make your code poetic too. One note -- I struggled the first time I ran your program to quit! None of the usual ways of quitting worked for me - ESC, ctrl-q, ctrl-c, alt-w, alt-f/x. The code showed me I only needed to press return, which also makes poetic sense.
ADA Editor 16-06-2015
Comment by Golan Levin:
"Camille calls her piece an "inadvertent homage to string art," but I think there's more than that going on here. Her piece (and Mark's, as well) operates by linking a fundamental element of visual design (the Line) to a fundamental affordance of computation (Iteration). Both Camille and Mark make this link clear by treating its results accretively, i.e., by incrementally building up an image with each iteration of the loop. John Maeda has written about how the computer is a 'tireless workhorse,' equally content to repeat something a billion times as ten. For artists, the consequences of this simple observation are so profound that it is only natural for each generation to rediscover it. Thus iterated lines like Camille's have a venerable history in computational design, whether in video games like "Qix," the popular designs of online artist Lia, or the works of other pioneering artist/programmers like Charles Csuri or John Whitney. And as computers show few signs of slowing down, this iterative economy they afford is likely to remain a theme, or a tool, for some time to come."
ADA Editor: linescape.cpp, 16-06-2015, in: Archive of Digital Art Comment by Golan Levin:
"Camille calls her piece an "inadvertent homage to string art," but I think there's more than that going on here. Her piece (and Mark's, as well) operates by linking a fundamental element of visual design (the Line) to a fundamental affordance of computation (Iteration). Both Camille and Mark make this link clear by treating its results accretively, i.e., by incrementally building up an image with each iteration of the loop. John Maeda has written about how the computer is a 'tireless workhorse,' equally content to repeat something a billion times as ten. For artists, the consequences of this simple observation are so profound that it is only natural for each generation to rediscover it. Thus iterated lines like Camille's have a venerable history in computational design, whether in video games like "Qix," the popular designs of online artist Lia, or the works of other pioneering artist/programmers like Charles Csuri or John Whitney. And as computers show few signs of slowing down, this iterative economy they afford is likely to remain a theme, or a tool, for some time to come."
ADA Editor 10-06-2015
linescape.cpp is a piece of software created for the CODeDOC project on the Whitney Museum’s Artport site. Twelve artists were commissioned by Christiane Paul to code a specific assignment—to ‘connect and move three points in space’. The main code was not to exceed 8KB. All the artists then exchanged works and commented on each other’s code. The goal of CODeDOC was to “take a reverse look at ‘software art’ projects by focusing on and comparing the ‘back end’ of the code that drives the artwork’s ‘front end.’”
linescape.cpp moves and connects 3 dots (as per the assignment), but each of the 3 dots moves along the perimeter of a different a rectangle. The 3 dots are connected in their current location by a translucent white triangle, and blue triangles connect the 3 dots in places they used to be. The traces of where the dots have been accumulate and fade over time. By clicking anywhere on the screen, a user can change the rectangles, and therefore the trajectories of the dots, and therefore the patterns created over time.
All motion implies time, and time and motion can create complexity out of very simple things. This is illustrated in linescape.cpp where a simple shape (a triangle) repeated over and over again, following another simple shape (a rectangle) creates a complicated network of lines. Through a simple set of rules, curves mysteriously emerge from the accumulation of straight lines. The layering begins to create foreground and background planes—recalling traditional, yet dynamically changing, landscapes.
ADA Editor: linescape.cpp, 10-06-2015, in: Archive of Digital Art linescape.cpp is a piece of software created for the CODeDOC project on the Whitney Museum’s Artport site. Twelve artists were commissioned by Christiane Paul to code a specific assignment—to ‘connect and move three points in space’. The main code was not to exceed 8KB. All the artists then exchanged works and commented on each other’s code. The goal of CODeDOC was to “take a reverse look at ‘software art’ projects by focusing on and comparing the ‘back end’ of the code that drives the artwork’s ‘front end.’”
linescape.cpp moves and connects 3 dots (as per the assignment), but each of the 3 dots moves along the perimeter of a different a rectangle. The 3 dots are connected in their current location by a translucent white triangle, and blue triangles connect the 3 dots in places they used to be. The traces of where the dots have been accumulate and fade over time. By clicking anywhere on the screen, a user can change the rectangles, and therefore the trajectories of the dots, and therefore the patterns created over time.
All motion implies time, and time and motion can create complexity out of very simple things. This is illustrated in linescape.cpp where a simple shape (a triangle) repeated over and over again, following another simple shape (a rectangle) creates a complicated network of lines. Through a simple set of rules, curves mysteriously emerge from the accumulation of straight lines. The layering begins to create foreground and background planes—recalling traditional, yet dynamically changing, landscapes.
Literature
Wójtowicz, Ewa. »Error 404. Noise in Electronic Media Arts.« HA!Art , no. 4 (December 2012): 1.
Apter, Emily S.. The Translation Zone. A New Comparative Literature. Princeton, NJ: Princeton Univ. Press, 2006.
Paul, Christiane. »CODeDOC II: curator's statement.« http://www.aec.at/CODeDOCII.
Stocker, Gerfried and Christine Schöpf, ed. Ars Electronica 2003: Code -The Language of our Time. Ostfildern-Ruit: Hatje Cantz, 2003.
Mirapaul, Matthew. »Secrets of Digital Creativity Revealed in Miniatures.« The New York Times (September 16 2002).
Exhibitions & Events
2003
Festival :