Chance-based Systems Presentation

Presentation Critique

edit:

Based on feedback, I would like to add further explanation that I thought I had posted explicitly prior, but indeed, had forgotten. Screenshots and planned future work still follow.

Concept and Purpose

Microscopic Monumentality: 

One of my inspirations for this project was the feelings I experienced when I encountered these large hung canvases of chip art only to discover that they were taken of actual microchips. It was an interesting change of perspective that was provocative, at least personally. Part of this project was my hope to recreate this experience for others, but without access to a larger display that wouldn't also block my motion tracking, I wasn't able to achieve this.

Systematic Aesthetic

I'm rather fond of mechanical, rigid, rectangular and angular aesthetics that drew me to using chip art as the vehicle for this expression in the first place. My biggest qualm with myself during the project was that I could not further the aesthetics; I simply didn't start early enough to have the time, but it's on my roadmap.

Artistic Participation in the Technical

Lastly, an idea I've been exploring in a more literal fashion is how to allow those who are daunted by the technical to be able to participate and enjoy it in a way that bridges that fear gap. This is the hardest of my goals to implement for two reasons:

1. The aesthetics have to be far more representational and evocative of something actually technical. If they don't look technical, why would anyone necessarily consider them technical?
2. Because the project hinges on chance, there's a difficult balance in allowing for audience participation without direct influence. If the crowd drives the simulation knowingly, it loses much of its chance; if they do not feel any influence over the system at all, how do they actually experience it? How does one keep an audience interested enough to evoke wonder and yet perplexed enough that they never encroach actual understanding?

I look forward to the opportunity to resolve these issues in the future, perhaps for a gallery type installation.

end edit.

Screenshots:

Without Outlines:

Analogous Color and Hue rules:

The following were generated on successive runs of the system for approximately 1.5 minutes

Planned Future Work:

• Work around opacity problems inherent in Processing 2.0 (right now)
• Fix fading functions to quickly fade new items and outlines in and out
• Parameterize color profiles instead of selecting random ranges for more interesting palettes
• Add perlin noise textures to improve visual complexity and aesthetic appeal
• Experiment with adding lines on randomly selected objects to move toward visual target
• Make or find a back-lit projector so a monitor does not need to be used
• Use depth-based tracking instead of image-based tracking
• This might help the system react much more effectively in the presence of larger crowds, where it appeared to falter. I had designed the system to work well with casual viewers, but I didn't anticipate such a large group being so close and enthralled ;]
• Make fullscreen
• Create system to more quickly/easily test and simulate so I don't have to wait for it to fully run

Chance-based Systems Project Update 05

Today, I found myself exceedingly frustrated with the flob library I'm using. Originally I chose it on the recommendation that it worked out of the box and would scale well to my project, but there's several weak points in its implementation, and the API is somewhat lacking in documentation. Reading the source helped, but not by much.

I was getting strange problems the longer my system ran, and I noticed it especially when there was little to no movement on the system. Turns out, when there's no movement, flob actually resets the id counter for all of its blobs, which I had been caching and using in a number of situations. Ultimately it was causing a lot of blobs to be selected but then ignored and never drawn.

Rather than try to figure out how to recompile the libraries without messing up the rest of the implementation, I wrapped the blobs in a wrapper class and stored my own id on each.

The system is finally stable, and I think most of the remaining tweaks will be for aesthetics.

Here's some shots from today in Studio A (my twin came along as well):

While I really wanted to use the projector I checked out, I remember my original reasoning for wanting to use a screen (besides being easier to test on and truer to color) is that if people are supposed walk in front of this, then it needs to be back projected or projected from the ceiling, and both of those sacrifice visual fidelity, time, and flexibility. It's still my intention to make the project work as a projected installation, but I really just need more time.


I'll finish cleaning up the aesthetics and post some screenshots on a final blog post for the presentation tomorrow. Until then!

Chance-based Systems Project Update 04

Today is a smaller update, but the good news is COLOR!

I started looking through Processing's color utilities, which fortunately are much more user-friendly than the default Java ones. For now I'm just building up the system with the needed parameters so that tomorrow I can tweak the color ranges and palettes as finely as I choose.

A couple problems arising are that a lot of the blocks are being drawn over, so the data structures will need to be refactored to sortable ones. I would like to sort based on the visual "size" of the chips, and I think area will be enough. I could factor in the diagonals as well, but I don't think it will be necessary, and I'd rather not do more work if the aesthetic of the simpler solution works just as well.

Yesterday I checked out a projector and booked time in Studio A to get the feel of how the project might actually be set up as an installation, and tomorrow I'll hopefully be able to find a few people to help me test it in Studio A.

Chance-based Systems Project Update 03

Since Wednesday's critique I've been able to move a bit further. Currently, I'm tweaking the values for the tracked blogs and building the data structures I'll need to track and display them properly. It's taking me a little time to remember my Java, but it's not too bad so far.

The major steps today were identifying all the debugging information I'd need and getting them reliably and correctly output onto a debugging screen. The red and light green boxes you see above are blobs that have been selected by my random/fitness check, and will be used for mapping onto the parameters of my chips.

Lastly, It took a bit to grok how to make a stopwatch/timer based on the frameRate, and adjusting to the little tricks Processing pulls behind the scenes was... fun. Now that I have it though, accomplishing animations and timeouts will be much easier.

Now I just need to start making designs!

Chance-based Systems Project Update 02

Things seem finally to be coming together

Preparing my thoughts for crit tomorrow:

• The project is interactive (dynamic)
• Audience will interact with it over time
• Preferred audience is a crowd because it will enhance movement
• Audience should understand they are effecting the system indirectly, but it should not be able to understand the underlying process directly (to keep things feeling random. They should feel like more of a trigger than an influence (even though they actually are)
• Final images should be projected (and printed if static images are interesting, we'll see...)

idea

Using an implementation of blob detection, randomly select some blobs with movement above a threshold (crowd or individual movement, not noise). Draw selected blobs to screen with varying color based on any data available from blobs library (depends on blob implementation). Auxiliary shapes can be generated as necessary, will test.

edit

The flob package was on of the ones Thomas mentioned awhile back. It has trackable blobs that give both lifetime and velocity of a blob, which were two important variables I was hoping for to map to size/color/opacity of my blocks. It also works in both oF and processing2+

Thomas also had a single image of the reference art from our trip to the post tower

Fortunately, that's one of the more representative images, and I can just make out the letters "ARITHM" which of course (as Laura was trying to remind me) means these images are from an exhibition in the Bonn Arithmeum. Searching there site was almost futile, but I found a few helpful things:

http://en.wikipedia.org/wiki/Very-large-scale_integration

       

Hopefully that will give a bit more direct insight into how to draw these objects effectively.
Also, flickr is helpful

http://www.flickr.com/photos/bibi/5939565186/sizes/z/in/photostream/
http://www.flickr.com/photos/bibi/5939007795/sizes/z/in/photostream/
http://www.flickr.com/photos/mitko/2210284854/sizes/z/in/photostream/

Chance-based Systems Project Update 01

Today has been a bit worrisome as far as project ideas go. I'm stuck in brainstorming world, but fortunately I've enough patient classmates to help me wade through my lack of ideas.

Today we saw critiques of three works, which all made me think that the weekend and my internal dialog have skewed my understanding of "chance-based" into "it must have a pseudo-random data source". Maybe I should work more at the lab...

Talks with classmates were helpful, so I think I can get my wheels turned back to the right direction before Wednesday. I'm going to look for my photos from Germany (where I saw the art that's my current, exclusive inspiration) so hopefully I can make some progress.

edit:

Good News: I found my images from the Deutsche Post Tower.
Bad News: I have one, not so good, skewed image of the art pieces I wanted for reference.

Maybe Thomas (Storey) took more than I did. It's a bit ironic, considering the lasting impression these things have had on me.

Chance-based System Project Brainstorm

Potential Sources of Chance

Slit-scanning video

Motion detection

Crowd proximity (I'd need stereo or a kinect)

Filesystem

Twitter / other social media with a public API / graph

I've been thinking about dataviz and about project with really long experiences for the audience. Often I'm getting caught up on the "how do you make it different from existing projects". 

I liked the Filesystem idea because it's both, and people would indirectly affect it, but it doesn't really make for much of an experience that can be seen by others. It's more like a screensaver, something that might be cool but would be privately appreciated. I do think it would be funny though to have a Filesystem TreeMapper that gave no useful feedback about the filesystem itself.

http://kdirstat.sourceforge.net/kdirstat.html#screen_shots

http://wiki.laptop.org/go/Filesystem

http://www.cs.umd.edu/hcil/treemap-history/index.shtml

It seems there are quite a few libraries for treemaps. The real trick would be making the resulting images chance-based but still retain the compelling aspects though...

Motion detection could get interesting. If so, I'd use oF or Processing, whichever had a more out of the box setup. I remember Thomas showed me a few libraries he used, I'll have to find them in my Github "starred" projects.

I'll probably save the kinect until I've got a little less pressure and a little more time.

There's been a lot of interesting stuff done already with slit-scan, so it might be more difficult to innovate

https://vimeo.com/7878518

http://seriss.com/people/erco/2001/

Forget social media. I'm embarrassed I even brought it up.

edit:

TreeMaps might take longer than I can afford to grok. Might be shelving the filesystem idea.

Chance-based Systems Project

Today I became aware of the Chance System project. I say "became aware" because the project was most definitely introduced Monday, but apparently the immediacy of it just didn't click in my brain until today. in class. right before crits.

To be honest, I'm pretty nervous about the actual project aspect of the course, mostly because this is my first foray into the "art" aspect of "generative art". Nonetheless, immersion in this project is the best thing for me; let research and brainstorming ensue.

Sources of Randomness

Being more familiar with the programming side of the class, naturally my mind drifted there for interesting sources of perceived randomness and chance. I like the idea of the audience of a piece being its source of input, especially if its indirect and furtive, and that fit in with the "chance" aspect well enough

Needing to get ideas flowing, I threw an idea out after class to Phil about using garbage values from C programs to parameterize some later form of art. I appreciated his frank, direct, genial criticism of the idea.

Critical Questions

1. Who is your audience?
2. How might/should/etc the audience interact with the piece?
3. Is the piece an interactive (i.e dynamic) or static experience.
4. Is the piece better realized through, or without, software?
5. What is the generative system (the part where I give up control over the work)?
6. Do I view the piece from an Art or Design perspective (i.e. process, product, purpose, experience)?
7. Is it important/crucial that the audience know the process, or is that process evident by the work itself?
8. Where and how is the aspect of "chance" introduced?

At first, all of these questions at once felt like my idea was being shot down, but my emotions will soon catch up with my reason and realize that's not the case. These questions form an excellent framework to help me explore a project idea.

Thankfully, Phil is as fond of "calendar time" as I am.