forking a sketch

Forking a Sketch: How the OpenProcessing Community Uses Remixing to Collect, Annotate, Tune, and Extend Creative Code

Blair Subbaraman, Shenna Shim, Nadya Peek

Machine Agency, University of Washington

Slides: https://rb.gy/3jdyb

If you're unfamiliar with creative coding, it might look something like this. Creative coders create programs, called sketches, that generate visual output. In this video, I'm editing a sketch posted to the website OpenProcessing, created by the author Roni Kaufman. We can see that the effects of editing existing parameters in code can immediately be seen by running the sketch. Here, I'm editing the number of sides of a polygon and the number of bumps which are animated within it. I could then choose to publish my edits as a new sketch; this repurposing of an existing artifact into something new is called remixing. Remixing facilitates this sort of iteration on existing code, but we have yet to understand how creative coders use remixing in practice. Moreover, given the focus on expressivity over functionality, we suspect that code reuse in creative coding is distinct from other programming contexts.

What remixing strategies do creative coders employ to reuse code?

Remixing Creative Code

Understanding High-Level Remixing Practices

Dataset

1.2 million sketches available
336,069 sketches in remixing graph

30% of all sketches

Dataset

1.2 million sketches available
336,069 sketches in remixing graph

30% of all sketches

Network Analysis

79,453 subgraphs
2749 nodes in largest subgraph
49% of all remixes are self-remixes

Not every remixed sketch is related to each other; the overall remixing graph is made up of 79,453 subgraphs. The average sketch isn't highly remixed, but the dataset is unsurprisingly skewed; the largest subgraph consists of nearly 3000 total sketches. Much of these findings align with prior studies of remixing communities. A key finding distinctive to OpenProcessing, however, is that we find authors remixing themselves. We found that almost half of all remixes are involved in what we call self-remixing. We take note of this behaviour throughout our analysis. This data provides useful high-level insight, but to answer our research question, we are especially interested in what has actually changed between these antecedents and remixes. We collated 350 antecedent-remix pairs sampled from the remixing graph for in-depth analysis.

Antecedent-Remix Pairs: A Worked Example


								function myCircle (x, y, rad) {
									let numLayers = 200
									for (let i = 0; i < numLayers; i++) {
									  let vertices = []


									  for (let theta = 0; theta < TAU; theta += TAU / 20) {
										  ...


								function myCircle (x, y, rad) {
								  let numLayers = random(100, 300)
								  for (let i = 0; i < numLayers; i++) {
								    let vertices = []
								    let flick = random(10,11)
									  // for (let theta = 0; theta < TAU; theta += TAU / random(10,30)) {
									  for (let theta = 0; theta < TAU; theta += TAU / flick) {
										  ...


									function myCircle (x, y, rad) {
										let numLayers = 200
										for (let i = 0; i < numLayers; i++) {
										  let vertices = []
	
	
										  for (let theta = 0; theta < TAU; theta += TAU / 20) {
											  ...


									function myCircle (x, y, rad) {
									  let numLayers = random(100, 300)
									  for (let i = 0; i < numLayers; i++) {
									    let vertices = []
									    let flick = random(10,11)
										  // for (let theta = 0; theta < TAU; theta += TAU / random(10,30)) {
										  for (let theta = 0; theta < TAU; theta += TAU / flick) {
										    ...


								function myCircle (x, y, rad) {
									let numLayers = 200
									for (let i = 0; i < numLayers; i++) {
									  let vertices = []


									  for (let theta = 0; theta < TAU; theta += TAU / 20) {
										  ...


								function myCircle (x, y, rad) {
								  let numLayers = random(100, 300)
								  for (let i = 0; i < numLayers; i++) {
									let vertices = []
									let flick = random(10,11)
									  // for (let theta = 0; theta < TAU; theta += TAU / random(10,30)) {
									  for (let theta = 0; theta < TAU; theta += TAU / flick) {
										...

tuning


								function myCircle (x, y, rad) {
									let numLayers = 200
									for (let i = 0; i < numLayers; i++) {
									  let vertices = []


									  for (let theta = 0; theta < TAU; theta += TAU / 20) {
										  ...


								function myCircle (x, y, rad) {
								  let numLayers = random(100, 300)
								  for (let i = 0; i < numLayers; i++) {
									let vertices = []
									let flick = random(10,11)
									  // for (let theta = 0; theta < TAU; theta += TAU / random(10,30)) {
									  for (let theta = 0; theta < TAU; theta += TAU / flick) {
										...

tuning, extending


								function myCircle (x, y, rad) {
								  let numLayers = 200
								  for (let i = 0; i < numLayers; i++) {
								    let vertices = []
									
									
									  for (let theta = 0; theta < TAU; theta += TAU / 20) {
										  ...


								function myCircle (x, y, rad) {
									let numLayers = random(100, 300)
									for (let i = 0; i < numLayers; i++) {
										let vertices = []
										let flick = random(10,11)
										// for (let theta = 0; theta < TAU; theta += TAU / random(10,30)) {
										for (let theta = 0; theta < TAU; theta += TAU / flick) {
											...

tuning, extending, annotating

tuning, extension, annotation

collecting, tuning, extending, annotating

Collecting

Annotating

Sketches by *Aaron Reuland (a_soluble_fish)*


						/* 
						ok, this texture algorithm I definitely stole. 98% sure it was from
						**Che-Yu Wu (openprocessing.org/user/139364)** an amazingly talented 
						artist, who also adds lots of in-progress stuff to openProcessing-
						nice to learn from (not that I learned from this at the time I made this,
						so much as I copied and pasted it) creates a nice papery texture by applying
						noise to the pixel array, that is blended with the rest of the ’art’ later on.
						*/

Not all changes to code necessarily affect the visual output. While comments seem like a boring or uninteresting part of a usual programmers practice, we see annotating code using inline code comments used in a diversity of ways. I'll highlight a couple of the ways we saw annotations being used which diverge from what we might expect out of inline comments. We see annotations which log personal process. A year after posting their original sketch, the author remixed themselves. In the excerpt shown, they describe where they sourced the code snippet to create a “papery” texture. While they say they copy-pasted it at the time of the original sketch, in their annotation they take time to explain its use. Comments like these wouldn't usually be found in production code, but in a creative coding context, they reveal process in a public setting.


						/* 
						ok, this texture algorithm I definitely stole. 98% sure it was from
						**Che-Yu Wu (openprocessing.org/user/139364)** an amazingly talented 
						artist, who also adds lots of in-progress stuff to openProcessing-
						nice to learn from (not that I learned from this at the time I made this,
						so much as I copied and pasted it) creates a nice papery texture by applying
						noise to the pixel array, that is blended with the rest of the ’art’ later on.
						*/


						var length = 150;          var length = 100; // 150

Tuning


								margin = mySize / 100;
								for (let i=0; i < int(random(50, 100) ); i++) { ... }
								theShader.setUniform('u_time ', millis () / 1000);
								let version = random ([1 ,2 ,4 ,6 ,8]) * 100;
								let c = random (2000 , 5000) ;
								colorMode(HSB, 360, 100, 100, 100);


								margin = mySize / 10;
								for (let i=0; i < int(random(500, 100) ); i++) { ... }
								theShader.setUniform('u_time', millis () / 1);
								let version = random ([200,150,77,50,140] * 100;
								let c = random (1000, 2000);
								colorMode(HSB, 21, 10, 10, 10);


								margin = mySize / 100;
								for (let i=0; i < int(random(50, 100) ); i++) { ... }
								theShader.setUniform('u_time ', millis () / 1000);
								let version = random ([1 ,2 ,4 ,6 ,8]) * 100;
								let c = random (2000 , 5000) ;
								colorMode(HSB, 360, 100, 100, 100);


								stroke (244 , 37 , 37 , 60); // red


								margin = mySize / 10;
								for (let i=0; i < int(random(500, 100) ); i++) { ... }
								theShader.setUniform('u_time', millis () / 1);
								let version = random ([200,150,77,50,140] * 100;
								let c = random (1000, 2000);
								colorMode(HSB, 21, 10, 10, 10);


								stroke (0, 0, 0); // red

Extending


								vertex(xPosition , yPosition);


								curveVertex(xPosition,yPosition);


								function randomShape(x_, y_, w_, h_, col) {
									let grfx = createGraphics(w_, h_);
									let rnd = int(random(6));
									let num = int(random(1, 4));
									...
									for (let i = 0; i < num; i++) {
									  let w = random(5, w_ * 0.35);
									  let h = random(5, h_ * 0.35);
									  let x = (random(1.4)-0.2)*grfx.width;
									  let y = (random(1.4)-0.2)*grfx.height;
									  ...
								  }


								function drawTrees(x_, y_, w_, h_, col) {
									let grfx = createGraphics (w_, h_);
									count = int(random(30));

									...
									for (let i = 0; i < count; i++) {
									let w = random(2, 10);
									let h = w * random (2, 5);
									let x = (random(1.4) - 0.2) * grfx.width;
									let y = (random(1.4) - 0.2) * grfx.height;
									...
									};

Finally, the remixes we've seen so far have involved one antecedent and one remix. We see authors can explore multiple creative directions in a family of remixes. Shown here is a subgraph of remixed sketches beginning with on called “Square packing study” by Roni Kaufman, but we're only showing sketches by the original author. We see the author remixes the original sketch in three different ways, but the relationship between sketches in distinct chains is obscured without this top-level view of the whole subgraph. We noted in our network analysis that almost half of all remixed sketches are involved in self-remixing. Filtering the self-remix graph by subgraph size, we over 90% of subgraphs involved in self-remixing have 5 nodes or more. This statistic speaks to the frequency with which authors manage families of versions through remixing.

Key Takeaways

Understanding Existing Creative Communities
Design Provocations
Applicability to Other Contexts

Understanding Existing Creative Communities
Design Provocations
Applicability to Other Contexts

Understanding Existing Creative Communities
Design Provocations
Applicability to Other Contexts