Each node in the state graph represents a particular landing state.
There are two special nodes.  The state graph is hooked into the
juggler, so it makes sense to talk about which state the juggler is
currently in.  This node is marked blue.  It will be called the
Juggler Node.  It is also possible for the user to select any node he
wishes.  This is the Current Node.  It is colored red.  For obvious
reasons, if the Current Node and the Juggler Node coincide, that node
is colored purple.  This will be called the Both Node.  All other
nodes will be termed General Nodes.

The user has no control over the Juggler Node.  It moves in unison
with the juggler.  It is purely informative.  There are only three
ways to stop the Juggler Node from moving around the graph 1) pause
the juggler 2) Have the juggler be in a one-state pattern, such as
"5". 3) Find a bug in the code that leads to this behavior.

The user has complete control over the Current Node.  This is the node
which accepts all user input into the state graph.  Currently this
input consists of the following types:

0) 'k' will kill the Current Node.  All incoming and outgoing edges to
   this node will be removed.
1) 'c' removes all nodes.  
2) If the Current Node doesn't currently exist, hitting the spacebar,
   ' ', will set the Current Node to be the Juggler Node.
3) 'd' to create the node that corresponds to dropping a ball
4) The user can type a throw such as "5".  If the throw is valid, the
Current Node will be moved to the new node corresponding to this
throw.  If this new node does not exist, it will be created.  If the
necessary edge does not exist, it will be created.
5) 'l' will delete all nodes that don't have the same number of balls
   as the Juggler Node.  It also removes the corresponding edges.
NOTE: 3 and 4 only create nodes in the state graph; they do not affect
the juggler.

Clicking on the Current Node will cause it to become a General Node.
In this case, you will not have a Current Node anymore.  You can get
it back by clicking on a General Node.  This will cause that node to
become the Current Node.  Clicking on the Juggler Node will cause the
Juggler Node to become the Both Node.

There are two different modes the state graph can be in which pertain
to the Both Node.  In Follow Mode, the Current Node is following the
Juggler Node wherever it goes, thereby ensuring the continued
existence of the Both Node.  In Static Mode, the Current Node ignores
what the Juggler Node is doing.  The Current and Juggler nodes may
coincide for an arbitrary number of beats, but as soon as the juggler
goes into a different landing state, the Both Node will be no more
since the Juggler Node is now elsewhere.  Note that hitting ' ' as
described above turns on Follow Mode.

If you click on the Both Node while in Follow Mode, you will go into
Static Mode.  If you click on the Both Node while in Static Mode, you
will go into Follow Mode.  If the Juggler Node is not moving around
the state graph, say in the pattern "5", there is no way to tell if
you are in Follow Mode or Static Mode.

Support for the following does not currently exist:
0) inputting throw modifiers.
1) inputting multiplexed or synchronous throws.
2) deleting edges.
3) adding edges (as opposed to typing a throw, this would keep the
   Current Node where it is).
4) Creating all outgoing edges up to some reasonable height from a
   node.

Slightly confusing aspects:
0) You need to click very close to the center of a node to select (or
deselect it).  Clicking on the leftmost edge of the Node
"xxx-xx-x-xxxx-xxxx" will either 1) be ignored or 2) select some other
node that you're actually closer to the center of.  This is considered
a bug and will be fixed eventually.

1) Switching from synchronous to asynchronous patterns does some
counterintuitive things.  In an asynchronous pattern only one hand is
shown for each point in time.  An example might help (at least, if it
were a good example and clearly written): Say you are in the state
"xxxxxxxxx".  You are a good juggler, congratulations.  Anyway, at one
point in time, the first "x" might correspond to a ball landing in the
left hand.  A beat later, this "x" will correspond to a ball landing
in the right hand.  Vanilla siteswap notation does not care about such
things.  If it did, we would have to represent the state "xxxxxxxxx"
as something like:

x-x-x-x-x   and   -x-x-x-x-
-x-x-x-x-         x-x-x-x-x

The top line representing the left hand and the bottom representing
the right hand. The Juggler Node would then move between these two
nodes.

Now, for synchronous patterns, we do care about distinguishing between
the two hands.  There is the added problem that for every other beat,
nothing is landing in either hand.  Displaying these perpetually empty
landing times would be a waste of pixels.  For example, the pattern
"(4,4)" is really

x-  but is represented as   x
x-                          x

The problem arises when switching from synchronous to asynchronous (or
vice versa).  The State Graph must switch from 1) distinguishing
between hands and ignoring every other beat and 2) treating the hands
as the same and showing every time.  So when switching, you'll get
such nice things as:

x
 xx
x

Sometimes two nodes will show up the same yet will clearly be distinct
nodes.  This would be caused by the following:

x--           x-                                x
  -xx   and     xx  will both be displayed as    xx
x--           x-                                x

This is not considered a bug.  It is possible that one day it will be
considered a bug.  By that time I will be helpless in the face of the
morass of code that pertains to this problem.  It will then be
rereclassified as not-a-bug.

2) If you switch back and forth between synch and asynch patterns too
quickly, the landing states might not be displayed properly on the
State Graph.  Slow down.  Take some time to pour your coffee on the
roses.  This will get fixed eventually.  (I understand that making
positive statements like that one will help.)  It's just annoying to
fix, so I don't feel like doing it.  Can you say "design stage", boys
and girls?

Questions or comments pertaining to the State Graph in particular
should be addressed to gwar@math.harvard.edu.  I would like to thank
Doris for her excellent job in typing up this manuscript.  I would
like to thank my friends and family for suffering my bouts of rage
during the completion of this project.  And finally, Mark Leyner for
inspiration. :).

Greg Warrington				Somerville, MA, January, 1997.






