Final Project Meeting Report

Met with Phil today, and I believe the talk went well

I was between my LSystem project from the life project and the "Playing with Chaos" project I just finished for complexity-based.

With some reservations and concerns, I have tentatively decided to go forward with the complexity progress.

Per my Complexity Project Final Presentation post, I'll be touching on as many areas as I can under the "Future Work" heading.

For the final, projects should have strong Aesthetic, Technical, and Conceptual aspects. While all areas could certainly use improvements (and many are addressed by my Future Work roadmap), I'm most concerned about the conceptual.

My feedback from the project suggests that the interaction is still a bit tacked-on, so my biggest challenge will be researching alternatives for integrating user interaction, or really to consider more fully the role and necessity of the interaction for the piece and its purpose.

Full disclosure: I find this daunting, but I'm willing to try.

More than anything else, I want this project to allow its audience exploration and leave them preferably with a sense of wonderment and understanding of the nature of chaos. I still feel this can reasonably be achieved through user interaction, perhaps touch, but I'm just at a loss for how....

Nonetheless, I'm reassured that Phil considered the previous project a good first iteration to bring in for the final. More in the coming days.

Complexity-based Systems Presentation

"Playing with Chaos"

Purpose & Concept

Playing with Chaos is an interactive touch-based application built in Processing that encourages interaction between observers and mathematical chaos through play. It aims to visually inform about the nature of chaotic systems and allow users to spawn their own instances of chaos within the system.

This project is intended to be installed on large touch screens monitors at least 5 to 6 feet wide, but preferably in a much larger array. The idea is that if only one user is present, she should be able to stretch and not reach the edges of the screen. Sweeping motions and play are encouraged.

Playing with Chaos (Progress Demo) from Justin Sheehy on Vimeo.

Future Work

• Test on touch screen devices to work out any potential bugs
• Add ambient sounds to create a more immersive environment
• Explore alternative random algorithms that might better map to the color space with a more normal distribution
• Utilize the HSL color space so that the perceived brightness does not fluctuate without explicit instruction
• Improve grid code to fit better on a multitude of displays
• Unify timers (since all code is synced to the same tick) to save on processing and allow for larger grid arrays.
• Add modes for responsive interaction ("attract" mode, smooth, live "restart" transition)
• Explore additional gestures for user interaction

Complexity-based Systems Project Update 05

I am actually quite please about the progress I was able to make. The sketch is now touch enabled (though it's not like you could tell from looking at it). Using the SMT library was pretty painless, though they could have been MUCH more clear about NOT actually supporting Android just yet. There goes my easy way of testing it out.

No matter, the Mouse fallback will do just fine for now.


I rendered out the current piece without any interaction, though the framerate is a bit off because of how saveFrame works. If I have time I'll make a true render using a method James and I talked about last week.

edit:

Here's an actual render of 45 seconds of the test seed. I found out by trial and error (and ok, some math) that my poor laptop can't hold much more in memory than that. In a perfect world, this would be as easy as just adding saveFrame to my draw method; in practice, that slows the sketch to about half speed. While the playback looks just fine because my clocks are reasonably framerate independent, the reality is that Processing undergoes a variable frame rate that is roughly half as slow but inconsistent, and the resulting videos are not terribly informative.

Playing with Chaos (Progress Demo) from Justin Sheehy on Vimeo.

Complexity-based Systems Project Update 04

Grid system is working now!

Just need to add a few more touches in the morning and set it to full screen.

Note: for some reason it was really difficult to get shots without cool colors, but there's plenty of frames that show the warmer and even some cooler parts of the spectrum. Perhaps I should later add a debug feature to allow you to scrub through to a to a certain iteration...

The Sine of Chaos

The current randomization function is simple, perhaps even too simple. Here she is, in all her glory.

value = (0.5 * (1.0 + Math.sin(value * TWO_PI)))

The main thing I see about this that is potentially problematic is that sine will oscillate and visually seems to favor the edges of the spectrum over the middle. The piece as a whole also seems to be either mostly warm or mostly cool at any given time. Given user interaction, this may be completely negated, but it's not the "true noise" I was originally trying for at any rate.

Also, the brightness of the piece seems to oscillate almost arbitrarily; I was hoping that using HSB would allow me to just change the hue independently?

edit:

^ Minor brain lapse. If I wanted to have the same perceived brightness I should use a different color space that deals with luminance, such as HSL. I may backlog that for future work.

Complexity-based Systems Project Update 03

Components

1. Timers that can use the delta time of the application, frame-rate independent
2. DuelingCalculator class/structure
• Seed
• Value
• Deterministic algorithm that can take the previous random value as input
• Mapping for value into color
3. Grid structure based on desired box pixel width, dynamic scalable to display dimensions
4. Touch interface (with Mouse compatibility for testing) that is grid-aware

After looking at both Processing and OpenFrameworks, I've decided to go with Processing for this piece.
Though I have more of this code already written in C++, 

My brief survey of both languages seems to suggest that

• The workflow in Processing will be faster (for me) as the project will neither be memory intensive or complicated in design
• Processing has a well-vetted, long supported, straightforward library for Touch/Mouse interfacing called SMT
• Porting my code from C++ to Java will be relatively quick

While I prefer openFrameworks, there's a lot of extra plumbing there I haven't figured out, and to date, the ratio of projects I've done in Processing to oF is still 3:1. I don't have much time, to finish, so that's as good a reason as any for a presentable prototype

Progress

Ported my ofxDeltaTimer utility from C++ to Java

Set up "Dueling Calculator" system to generate sample values

Version control!

Sample value subset (showing 34 of 150):

Initial: 0.5030686
Initial: 0.5030687
Initial: 0.5030688
Initial: 0.5030689
Initial: 0.503069
Initial: 0.5030691
Initial: 0.5030692
Initial: 0.5030693
Initial: 0.5030694
Initial: 0.5030695
Initial: 0.5030696
Initial: 0.5030697
Initial: 0.5030698
Initial: 0.5030699
Initial: 0.50307
Initial: 0.5030701

...

Initial: 0.5030817
Initial: 0.5030818
Initial: 0.5030819
Initial: 0.503082
Initial: 0.5030821
Initial: 0.5030822
Initial: 0.50308233
Initial: 0.5030824
Initial: 0.5030825
Initial: 0.50308263
Initial: 0.5030827
Initial: 0.5030828
Initial: 0.50308293
Initial: 0.503083
Initial: 0.5030831
Initial: 0.5030832
Initial: 0.5030833
Initial: 0.5030834
Initial: 0.5030835

Complexity-based Systems Project Update 02

Honestly I haven't been able to work much until tonight's class block, but I think I've gotten a bit more clarity over the past week.

Purpose

Gathering my thoughts from the original presentation, I thought about what attracted me to the idea and explore my original motives. From the beginning I've been very interested in this idea of empowerment and exploration, particularly teaching people to learn and explore complex phenomena that they believe or have been led to believe they aren't smart enough to understand. There's this stunning side of the natural world that's so difficult for many (myself included) to grasp until its visual, and I think that's what this project is really about.

It's about playing with chaos (oh the puns).

Play

One of the most epiphanic experiences of my undergraduate studies was the discourse Katie Salen and Eric Zimmerman present in Rules of Play about the subtle differences between "games" and "play".

I think that's why I was so reluctant to let this project become a game (besides the fact I don't like the idea of being the carny) is because it's not a game to me, it's so much less structured. 

The user interaction felt tacked on because it was; the way I presented it, it wasn't the objective of the piece, much less a supporting element. But I think it should be the objective, it should be the primary interaction of my audience, first to look, then to play.

No gradual subdivision

In this context, I don't think the progressive subdivision makes sense. I don't think having only two blocks makes sense either. I think it needs a reasonably subdivided array of same-colored squares to start. Pop open MS Paint, there you go:

Over time, I imagine it would shift colors ever so slightly, maybe like this:

Gross, I know, I'll fix the colors later. Obviously each block would also be a solid color. Maybe I should have done this in Illustrator... this is faster.

From there, I'm not really sure what will happen. I think that's largely dependent on the chaotic algorithm I use, but the end result should be fairly noisy regardless, so I think that's kind of just what I find aesthetic.

Complexity-based Systems Project Update 01

I've decided to go with the dueling calculators idea (honestly though, I'd pretty much decided it by the time I was presenting it). After the presentation feedback, I've got a few decisions to make.

Clear Purpose

Feedback made me realize I still need a bit stronger purpose and concept. I want user interaction, but why?My original idea suggested starting from one square and subdividing over time, but is this actually necessary? Is the only way to make the project more meaningful to make it an explicit game (something I was trying to avoid)?

Feedback:

1. Does the user interaction [allowing users to click on on rows to start them over] make sense in the context of the project as a whole? It feels tacked on.
2. Maybe it's as simple as a game, though that makes you a bit like a carny, rigging the end result by the nature of the "game"
3. What actually is the point of subdividing squares other than to show they've reached their tolerance? It's still not clear how, when, or why you would do that.

I've got a few things to think about, more next time

Complexity-based Systems Project Brainstorming

Thought dump

Interests:

• An art installation that exhibits hysteresis; each user visits it in the discrete state the last user left it but no one user is aware of how it got there.
• The visual quality of strange attractors
• A project that does more than literally visualize some aspect of complexity

Ideas:

• A "tunnel fly-through" that is following the path of a strange attractor or doubled pendulum. (it'd be slow, don't want to make people nauseous)
  The environment might also be driven by chaos, or by parametrizing whatever state space the attractors are in.

 

          https://www.shadertoy.com/view/XdXGD4

• A "duelling calculators"-esque visualization. Example: two adjacent squares are separated by a solid line. The squares are arbitrarily assigned a seed value. This value is the same for both but could even vary by the slightest magnitude. These values may map to different attributes, say, the colour of the square.
  As the program goes on, the value evolves chaotically. When the values diverge more than a set tolerance, subdivide the squares and pick one of the colours as the new seed. Repeat. Chaos ensues.

Eventually this would probably end up looking like noise, but phases and patterns might emerge

It might be cool to allow users to draw across to set rows and columns, or to touch individual squares sequentially to reset the colors.

Life-based Systems Project Update 05

Since I'd like to carry on this project for my final, I began looking for more references and previous work for exploration. Here's a short list from the massive amounts I've culled off Google Scholar searches.

More references

http://www.csse.monash.edu.au/~jonmc/research/Papers/L-systemsMusic.pdf

http://portal.ku.edu.tr/~megunal/articles/cellular.pdf

http://teacher.kfcdc.edu.tw/kf94008/design-history/algorithm1.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.6.3882&rep=rep1&type=pdf

Life-base Systems Presentation

Note:

Unfortunately I've had to roll back my past two days worth of work on this project, so the presentation images are still from Monday. There was a lot of work that needed and still needs to be done to isolate all of the data structures I have, and I just kept running in to errors. I will continue to iron those out in the coming days.

Concept

Create a sound "garden" where plant-like structures are interpreted as musical notes and chords.

The installation takes up considerable gallery wall-space and is meant to feel immersive.

The sound played back by each of the "L-Sound-Systems" is panned relative to their position on screen

The structures are drawn in real time, and visualize leaf-like structures at the nodes of each note

Progress

A single structure can be drawn and shown at once. Only the pitch is currently driven directly by the L-system. The empty space should be filled by other structures.

Future Work

• Bug fixes
• Draw (i.e. reveal) plant structure in real time as it is "played"
• Allow for multiple plants to grow
• Match note groups from parser with node groupings in visualizer (incorrect green circles are currently drawn due to mismatch)
• Time MIDI events properly
• Draw radial sine "leaves" (or other visualization) instead of debugging circles
• Expand the L-system grammar and parameters to be more flexible and carry more information
• Add genetic wrapper to evolve variable input structures according to pleasing chord structures, note progressions, rhythms, etc.
• Explore audience interaction via keyboard, where users can input short sequences or entire pieces and watch them grow in to a forest.
  alternatively:
• Consider allowing input of midi files to be interpreted 
• Consider audience interaction via touchscreen to allow users to draw out their own plants