Imran Rashid
4/30/01
    Please note that this document isn't really completely polished up as a presentation -- its just a rough summary of the work I've done, including all the code.  I hope its useful to future developers.

Some of Wolfram's Work

Setting Up Initial Conditions

The state of a cellular automaton at each step is represented by a list of integers.  The cellular automaton starts from a list corresponding to its initial state.

This function generates a random list of n 0s and 1s.

This function generates a random list of n digits between 0 and k-1.

This function generates a list of length n with the sequence a in the center, surrounded by 0's.

Here is an example.

Elementary Cellular Automata

Introduced by Stephen Wolfram in 1982, the elementary cellular automata are the simplest class of one-dimensional cellular automata. They have two possible values for each cell, and rules that depend only on nearest neighbor values. There are a total of 256 distinct elementary cellular automata.

This function decodes the rule specification, and applies the rule for t steps.

Here is an uncompiled definition for the evolution at each step.

Here is a compiled version.

This shows an example of 5 steps in the evolution of rule 90, starting from a single 1 cell.

Visualization Functions

This generates graphics to represent the evolution of a cellular automaton with just two possible values for each cell.

This generalizes to the case of k values, each represented by a gray level.

This function uses hue instead of gray level.

examples

Here is a cellular automaton with a rule that makes a particular cell black if either of its neighbors were black on the step before.  The behavior is very simple.

This is what happens with a rule that makes a cell black if either of its neighbors, but not both, were black on the step before.

This is what happens if one runs the same rule for a long time. The pattern is a fractal.

Here is another simple cellular automaton rule that produces a fractal pattern.

As Wolfram discovered, however, not all simple cellular automata generate simple patterns,  Here are a few steps in the evolution of rule 30.

Here is 50 steps in the evolution of rule 30. The behavior appears in many respects random.

Here is another rule with behavior that appears in many respects random.

Here is a cellular automaton whose behavior shows a complex mix of order and randomness.

My Cellular Automata Work

Stephen's code is faster and very clean.  Why write my own?? he makes a few assumptions that make it hard to extend the code to more dimensions and to include Sound.  I'm not very good at optimizing code, so this stuff definitely runs slower -- however, I feel its very clear and also it is easily extendible to more complex CAs.

setup

This applies func for t  steps.

This applies func for t steps, but only returns the results from last steps.

Rules

The setup functions define the framework for the Cellular Automata, but most of the actual work is defined by the code here, that defines the Rules.

1D, Black and White

This is the most basic cellular automata, the classic example that is normally given.  Each cell has 2 states, represented by black and white.  If we use a radius of 1, than there are exactly 256 possible rules.

This definition of this rule is a little complicated -- it uses some Mathematica tricks for optimization.  The first argument to this function is the rule number (from 0 to 255), and the second is the previous state.

To see what this Rule does, first convert the number to a binary.  For example, for 57

These 8 digits define what to do for each of the 8 different input conditions.  Number each of those digits, from right to left, 0 to 7.  Each of the 8 input conditions correspond to a number from 0 to 7 in binary.  For example, input condition 011:

Corresponds to position 3.  So in the above example,go to position three in this list:

And we see that the rule says the next element should be a 1.

1D, RGB

This incorporates color into a Cellular Automata.  But instead of just taking a normal cellular automata and coming up with some method to colorize it, I wanted color to be an inherent part of the automaton -- for it to be another dimension.  So each point is actualy represented by three values -- its Red, Green, and Blue values.

The way I have this set-up, the next Red state depends on previous red neighbors, previous Blue Neighbors, and previous Green Neighbors.  This means there are 9 inputs for each state.  If you calculate it out, this means there are:

possibilites. Thats a LOT.  In fact, this number is so big, that I think its aboslutely ridiculous to try and continually number all the possibiltes.  Maybe later, I will extend so that more are possible.  But for now, i just decided to take the simple approach, and chose a rule at random:

Another possibility might to say that the values on depend on their left neighbors, not the right ones.  This would give

possibilites, which is much smaller, but still pretty huge.

In any case, the Rule I chose is defined by this:

	R	G	B
L	a	b	c
C	d	e	f
R	g	h	i
next

That rule is obtained just by going diagonally from top left to bottom right.  Note that the sums will taken mod 2, as they can only have values 0 or 1.

Rendering

1D, Black and White

Just outputs a Graphic which shows the cellular Automata.

1D, Black and White -- Sound

Here is a function that "plays" a row of a cellular automaton, effectively treating each cell like a key on a piano, with black cells being pressed.  This code will probably look very weird to non-Mathematica users.  The key thing to know is that is takes the position of the cells that are "1", takes to that power, multiplies that result by 1000, and makes that the frequency for the sound.  Then it adds together all the Sine waves, and plays the result.
The one thing you could easily change is the 0.1, which determines how long the sound plays

1D, RGB

just outputs a graphic with the Cellular Automaton

1D, RGB -- Sound

This is similar to the B/W version. For details on this code, see the explanation for the BW sound generation.   The only different is that here, the sum of the color values are obtained, and the "key" is played whenever the sum  is 2.There is no special reason I chose that method -- it just seemed interesting.

Driver Functions

This just defines some driver functions, to make a nicer user interface.

1D, Black and White

For visual rendering, the function called is visual1DBW, and for Sound rendering, the fucntion called is sound1DBW.

By default, Visual Rendering is on, and Sound rendering is off, the starting conditions are all 0's except for a single 1 in the very center, and the entire thing is rendered in a large graphic.

This function generates a list of length n with the sequence a in the center, surrounded by 0's.

This function generates a random list of n 0s and 1s.

1D, RGB

For visual rendering, the function called is visual1DBW, and for Sound rendering, the fucntion called is sound1DBW.

By default, Visual Rendering is on, and Sound rendering is off, the starting conditions are all 0's except for a single 1 in the very center, and the entire thing is rendered in a large graphic.

This function generates a list of length n with the sequence a in the center, surrounded by 0's.

This function generates a random list of n 0s and 1s.

examples

Combining CSound w/ Cellular Automata

1D BW

Different instruments are chosen based on the length of the "run" of black keys.
1 -- bell-like sound
2 -- normal beep
3 -- sound w/ some vibrato, sine waveform
4 -- sound w/some vibrato, sawtooth waveform
5 or more -- pluck

The frequency of each sound is determined by the leftmost key for each "run".

internal code

    This function goes through a state and returns a list of Sound Objects.  I used a container called SO for each of these sound objects.  The first argument to the SO is which type of SO it is (the length of the run), and the second is the starting index.
    If you want to use some different idea for when different instruments should be played, change this function around.

    This takes a list of SO (SoundObjects) and writes out the corresponding CSound code to the score file.
    Even if you change the way SO's are generated, you might not need to change this function.  You'd only need to change this if you want to change how many parameters (or what the order of the parameters is) in your orchestra file.  Even if you're instruments are setup completely differently, even if you use a completely different algorithm to decide when to play which instruments, if they take the same parameters, this code will work.  And if you decide to add parameters, it should be rather trivial to add a line or two to this code.

Outputs header information for my CSOUND orchestra files.  This is basically just the lines at the top where I define SineWave and SawTooth waveforms

driver function

Creates the Cellular Automata, then renders appropriately.

examples