Information
Technology
Software
Java applet
Descriptions & Essays
enter the project here:
Scroll down to launch Project
Please adjust your Java Security Settings in order to launch the Programme.
Commissioned by the Whitney Museum.
ADA Editor 16-06-2015
Comment by John Klima:
"I love how the code "eats itself." The writing style is not as smooth as Golan's, for example -- in code, if not in drawing, I definitely favor the "easy on the eyes," but in the case of this work, it seems the only way to get the job done is through brute force. It's a fascinating piece because as I write code, I always have an image in mind of how the routines are calling each other, passing control here and there and back again, and it's great to see an actual picture of this happening. Not surprisingly, it is as boggling an image in actuality as it often is in my head."
ADA Editor: Code Profiles, 16-06-2015, in: Archive of Digital Art Comment by John Klima:
"I love how the code "eats itself." The writing style is not as smooth as Golan's, for example -- in code, if not in drawing, I definitely favor the "easy on the eyes," but in the case of this work, it seems the only way to get the job done is through brute force. It's a fascinating piece because as I write code, I always have an image in mind of how the routines are calling each other, passing control here and there and back again, and it's great to see an actual picture of this happening. Not surprisingly, it is as boggling an image in actuality as it often is in my head."
ADA Editor 16-06-2015
Martin Wattenberg:
I decided the most natural way to comment on Brad's profiler was to profile it by creating a remix. He did a pretty amazing job of showing the sequential movement and rhythm of the execution point... so I tried to show the opposite in my remix, exploring the parallel operations happening at any given moment.
http://artport.whitney.org/commissions/codedoc/CodeLayers/MetaProfile.html
Watch my program profiling his program profiling itself.
My remix is a subclass of his and follows the same protocol, so the other instrumented programs can be plugged in as well... on the page above you'll also see links to profiled versions of Scott's applet and mine. (It actually shows distinct differences between all of our approaches to threading, although this may be of interest only to programmers!)
ADA Editor: Code Profiles, 16-06-2015, in: Archive of Digital Art Martin Wattenberg:
I decided the most natural way to comment on Brad's profiler was to profile it by creating a remix. He did a pretty amazing job of showing the sequential movement and rhythm of the execution point... so I tried to show the opposite in my remix, exploring the parallel operations happening at any given moment.
http://artport.whitney.org/commissions/codedoc/CodeLayers/MetaProfile.html
Watch my program profiling his program profiling itself.
My remix is a subclass of his and follows the same protocol, so the other instrumented programs can be plugged in as well... on the page above you'll also see links to profiled versions of Scott's applet and mine. (It actually shows distinct differences between all of our approaches to threading, although this may be of interest only to programmers!)
ADA Editor 16-06-2015
Comment by Golan Levin:
Brad has cannibalized his popular TextArc piece http://www.textarc.org/ and come up with a few interesting variations in how it can be applied. What I like about his contribution is the fact that it's purely reflexive: a system visualizing itself. On a technical level, I also admire his homebrew implementation (and interpretation) of computational introspection. I could imagine another version of his piece in which it decompiles its own bytecodes, in order to obtain the "real" (in quotes) line numbers of its execution. His remix of Scott's piece, which portrays the live execution of Scott's simulation, is reminiscent of integrated programming environments like John Maeda's DBN http://dbn.media.mit.edu/ and Ben Fry & Casey Reas's Processing https://processing.org/, yet suggests an interesting extension to these in which the line-by-line execution of the code itself is visualized. There are Java compilers for Java... Brad could actually make such a thing... and then I'd have to wonder out loud how a system like that could be more completely bi-directional, where changes to the image produced changes in the code.
Brad says "look how little the filter is doing!" but I disagree, and can't let him off so easily. I think the filter is the subject here -- and there are a tremendous number of aesthetic choices in his application: his selection of colors, the use of Bezier curves, details about how the typography is layered and scaled, the rate at which things animate, etc. etc.
My only real question concerns the size of Brad's source code, which exceeds the problem statment by a factor of 5. I don't personally have a problem with this (my code is large, too, because it contains a hard-coded database); rather, I would just be curious to see the smallest possible program which could still visualize its own execution. In this regard, I think Brad's solution is attractive but baroque.
Brad Paley:I was concerned myself about running over the 8K limit and planned to squeeze the code's size down when our curator indicated there was no need to. Also, it's 18% past 8K as compiled code. I think you measured the source--our commission allowed either measurement.
ADA Editor: Code Profiles, 16-06-2015, in: Archive of Digital Art Comment by Golan Levin:
Brad has cannibalized his popular TextArc piece http://www.textarc.org/ and come up with a few interesting variations in how it can be applied. What I like about his contribution is the fact that it's purely reflexive: a system visualizing itself. On a technical level, I also admire his homebrew implementation (and interpretation) of computational introspection. I could imagine another version of his piece in which it decompiles its own bytecodes, in order to obtain the "real" (in quotes) line numbers of its execution. His remix of Scott's piece, which portrays the live execution of Scott's simulation, is reminiscent of integrated programming environments like John Maeda's DBN http://dbn.media.mit.edu/ and Ben Fry & Casey Reas's Processing https://processing.org/, yet suggests an interesting extension to these in which the line-by-line execution of the code itself is visualized. There are Java compilers for Java... Brad could actually make such a thing... and then I'd have to wonder out loud how a system like that could be more completely bi-directional, where changes to the image produced changes in the code.
Brad says "look how little the filter is doing!" but I disagree, and can't let him off so easily. I think the filter is the subject here -- and there are a tremendous number of aesthetic choices in his application: his selection of colors, the use of Bezier curves, details about how the typography is layered and scaled, the rate at which things animate, etc. etc.
My only real question concerns the size of Brad's source code, which exceeds the problem statment by a factor of 5. I don't personally have a problem with this (my code is large, too, because it contains a hard-coded database); rather, I would just be curious to see the smallest possible program which could still visualize its own execution. In this regard, I think Brad's solution is attractive but baroque.
Brad Paley:I was concerned myself about running over the 8K limit and planned to squeeze the code's size down when our curator indicated there was no need to. Also, it's 18% past 8K as compiled code. I think you measured the source--our commission allowed either measurement.
ADA Editor 16-06-2015
Comment by Scott Snibbe:
Code Profiles is a self-reflexive look at code text. The program reads itself, closing the loop between reading, writing, and execution. The CODeDOC project reveals that programs are merely text files that are animated by the compiler, interpreter and computer. Most readers of code won't fully realize the multi-dimensional connections that the linear text actually represents. Code Profiles reveals the three ways of reading the code -- the linear read that most viewers will see; the developmental order -- how the writer breaks code up in their mind; and finally the execution order -- how the code actually runs. Even the code writer often has only a vague understanding of the actual execution order, so these three views are really completely distinct. Seeing all these views together is revealing for all parties -- writer, reader and the executor too -- the computer doesn't get to actually operate on its own code any more. Modern computers separate program and data memory, so that the "errors" or a program modifying itself can be avoided. Clever programmers in the early days actually wrote programs that were "self-aware" and selectively changed parts of the program memory itself to change the execution of the program on-the-fly.
Brad Paley: I'm glad that people appreciated the self-studying nature of my code, but wanted to say *why* it studies itself -- the point of the piece may have gotten lost. It wasn't written to be computer-clever, nor postmodern reflexive (though I admit I refer to those tropes). It reads itself because that was the clearest way I could address the commission's curatorial intent: to address process by focusing on code writing and reading, and almost incidentally execution. My piece simply tries to expose how my code (and Martin's, and Scott's) was written, read by others, and finally executed by the computer.
ADA Editor: Code Profiles, 16-06-2015, in: Archive of Digital Art Comment by Scott Snibbe:
Code Profiles is a self-reflexive look at code text. The program reads itself, closing the loop between reading, writing, and execution. The CODeDOC project reveals that programs are merely text files that are animated by the compiler, interpreter and computer. Most readers of code won't fully realize the multi-dimensional connections that the linear text actually represents. Code Profiles reveals the three ways of reading the code -- the linear read that most viewers will see; the developmental order -- how the writer breaks code up in their mind; and finally the execution order -- how the code actually runs. Even the code writer often has only a vague understanding of the actual execution order, so these three views are really completely distinct. Seeing all these views together is revealing for all parties -- writer, reader and the executor too -- the computer doesn't get to actually operate on its own code any more. Modern computers separate program and data memory, so that the "errors" or a program modifying itself can be avoided. Clever programmers in the early days actually wrote programs that were "self-aware" and selectively changed parts of the program memory itself to change the execution of the program on-the-fly.
Brad Paley: I'm glad that people appreciated the self-studying nature of my code, but wanted to say *why* it studies itself -- the point of the piece may have gotten lost. It wasn't written to be computer-clever, nor postmodern reflexive (though I admit I refer to those tropes). It reads itself because that was the clearest way I could address the commission's curatorial intent: to address process by focusing on code writing and reading, and almost incidentally execution. My piece simply tries to expose how my code (and Martin's, and Scott's) was written, read by others, and finally executed by the computer.
ADA Editor 10-06-2015
Commissioned for the Whitney Museum of American Art's "CODeDOC" exhibition, CodeProfiles explores the space of code itself: the program reads itself into memory, prints itself on the page, then traces three points as they once moved through that space. The written code stacks like unkempt piles of books; three colored lines bind it all together tracing three different interpretations. A paper-white line traces the writer's insertion point. It is lightest in scribbles toward the middle-right, where the most recent code (the code that produced the print itself) was added. A warm amber line simulates the fixation point: where the human eye might jump as it reads; left to right, top to bottom. And cathode-ray-tube green traces the execution point of the program; showing what parts of the program the computer read constantly, overlapping to make wide swaths of light; or rarely, in a choppy web.
ADA Editor: Code Profiles, 10-06-2015, in: Archive of Digital Art Commissioned for the Whitney Museum of American Art's "CODeDOC" exhibition, CodeProfiles explores the space of code itself: the program reads itself into memory, prints itself on the page, then traces three points as they once moved through that space. The written code stacks like unkempt piles of books; three colored lines bind it all together tracing three different interpretations. A paper-white line traces the writer's insertion point. It is lightest in scribbles toward the middle-right, where the most recent code (the code that produced the print itself) was added. A warm amber line simulates the fixation point: where the human eye might jump as it reads; left to right, top to bottom. And cathode-ray-tube green traces the execution point of the program; showing what parts of the program the computer read constantly, overlapping to make wide swaths of light; or rarely, in a choppy web.
Literature
Marchese, Francis T.. »Software Archaeology and the Preservation of Code-based Digital Art.« In Proceedings of Archiving Conference 2013, edited by Society for Imaging Science and Technology, 25-30. Springfield, VA: 2013.
Reisinger, Gunther. »0 oder1? Computerkünstlerische Spiele mit dem binären Zufall.« In SpielKunstGlück. Die Wette als Leitlinie der Entscheidung, edited by Johann Konrad Eberlein, 181-192. Wien/Berlin: Lit-Verlag, 2011.
Colson, Richard. The Fundamentals of Digital Art. Lausanne: AVA Publishing, 2007.
Paul, Christiane. »CODeDOC II: curator's statement.« http://www.aec.at/CODeDOCII.
Exhibitions & Events
2003
Festival :