Siteswap notation is by far the most popular notation today for describing juggling patterns. It is used by jugglers worldwide to communicate juggling patterns to one another, and also to learn and invent new ones.

This page describes the pattern notation used by the siteswap notation component of Juggling Lab. There are two main sections:

The notation described here is complicated in its full description, but don't let that put you off. Understanding just vanilla siteswap will let you have a lot of fun experimenting with Juggling Lab, and you can pick up more over time.

Siteswap notation is a very *simple* notation. When an object is thrown within a
juggling pattern, siteswap only concerns itself with
two facts about that object:

- Which hand it's being thrown to, and
- How many beats of time will elapse before that object is thrown again.

That's it. So there are a lot of things siteswap ignores. What kind of object was it? Did it go through the air, or bounce off the floor, or go under the juggler's leg? How did the arms move? And so on. Because these styles and embellishments are ignored by the notation, we often find that two patterns that seem quite different to us as jugglers, for example the three ball cascade and Mills Mess, are considered identical by siteswap notation!

Rather than think of this as some kind of tragic deficiency, better to think of it the other way around: Siteswap notation describes for us what is most important about a pattern, namely which objects are thrown by which hands, and when. Every real-life juggling pattern has a siteswap description, and every siteswap can be creatively embellished in an infinite number of ways.

The simplest case is that of a single juggler throwing alternately with
both hands in a R-L-R-L kind of way (called asynchronous juggling), with
one throw per beat.
This is what you do in the standard cascade pattern. Each throw in our
notation can then be described by a single number, namely *the number of
beats in the future when the object is thrown again.* In a 3 ball
cascade each throw is a `'3'`

, for example.

In this case it turns out the notation doesn't
need to specify the destination hand, since odd numbers always go to the
opposite hand, and even numbers to the same hand (a result of constraining
ourselves to a R-L-R-L throwing rhythm). Another way of thinking about
it is this: When you do a throw `'n'`

(`n`

is the throw number), you throw just
as you would if you were doing a cascade or fountain with `n`

objects, at
the same handspeed. A `3`

is a short toss across, a `4`

is higher and into the same hand, and so on.

An asynchronous siteswap is just a sequence of these numbers: The first number describes the first throw made, the second number the second throw (opposite hand as the first), and so on. At the end of the pattern you loop back to the beginning and continue.

Sample three ball tricks include (click on the patterns to see animations):

`3`

- Standard cascade

`51`

- Shower (that's
`5`

and`1`

, not fifty-one!)

`42`

- Two in one hand, hold with the other (see the explanation of holds below)

`441`

- An interesting box-like pattern

`55500`

- A 3-high flash

The `'0'`

, `'1'`

, and `'2'`

throws need some
explanation. A `'2'`

throw is
thrown again two throws in the future, in other words the next throw out of
the same hand. Since the hand does nothing before throwing the
object again, we are free to interpret a `'2'`

as just a hold in that hand for one count.
A `'1'`

is a fast zip across from hand to hand, as in the shower. Finally,
a `'0'`

is no throw at all; the hand is empty (the pattern
`60`

is three in one hand, the other hand empty).

Throws with values greater than `'9'`

are
by convention assigned the letters
`'a'`

(10),
`'b'`

(11),
`'c'`

(12), and so on. In Juggling Lab these
must be supplied
in lower case to avoid conflicting with throw modifiers.

Are all strings of numbers jugglable patterns? No. Notice that if you average the throws in each of the above patterns you
always get 3, the number of objects being juggled. This is one of the
ways you can tell whether or not a string of throw numbers forms a
valid pattern. `'76'`

doesn't work, but `'75'`

is a
valid six ball pattern
(commonly known as the six ball half-shower). It turns out that even this averaging criterion is not enough
to determine which strings of numbers are valid juggling patterns; for a better description see the JIS siteswap
help pages.

So far in our discussion of siteswap, we have placed some serious restrictions on the pattern: There is only one juggler (solo juggling), the hands are throwing in a right-left alternating rhythm (asynchronous juggling), and only one throw is made at a time out of each hand. This simplest form of siteswap notation, sometimes called vanilla siteswap, was the first kind discovered, independently by three people in 1985: Bruce Tiemann (Caltech), Paul Klimek (Santa Cruz), and Mike Day (Cambridge, England).

What we'd like to do is expand the set of patterns we can describe, by relaxing these restrictions one by one. We start by allowing the juggler to make multiple throws out of the same hand at the same time; this is a popular juggling technique known as multiplexing.

The simplest way to notate multiplexing is to group together with brackets the throw
numbers of the multiplexed throws. An example five ball
multiplexed pattern is `24[54]`

. From the middle of a cascade, we first do a hold
with our right hand, throw a shorter toss from the left hand to itself, and
then simultaneously throw a `5`

and `4`

with the right (the
hand had two balls in
it, since it did the hold first). Then we can either switch back into the
cascade, or repeat the trick starting with a left-handed hold -- recall that we switch
hands each repetition since the
pattern is of odd length. [This, by the
way, is a trick that Anthony Gatto did in his act, except that he did it
all while juggling over his head. He also did `26[76]`

with seven balls.]

Now we relax the restriction that the juggler throws in a right-left alternating rhythm. The simplest case is where both hands are throwing at the same time, called synchronous juggling.

Synchronous siteswap notation is very much like vanilla
siteswap notation above, but with two differences: (1) we group together throws
made simultaneously with parenthesis, and (2) we now need to specify a
destination hand for each throw, so put an `'x'`

after any throw that crosses
over into the other hand (a throw without the `'x'`

is assumed to be directed
to the same hand that threw it). A `'2'`

is still a hold, but a `'2x'`

is similar to the `'1'`

in the siteswap notation above: a short pass from hand
to hand. A `'0'`

is still no throw, and a `'0x'`

is not allowed.
*All* throw numbers must now be even.

Examples of synchronous patterns:

`(4,4)`

- 4 ball synchronous fountain

`(4x,4x)`

- A common crossing version of the 4 ball fountain

`(4x,2x)`

- 3 ball shower with simultaneous throws

`(4,2x)(2x,4)`

- The 3 ball "box" or "see-saw" pattern

`(6,6)(6x,2x)`

- A 5 ball trick

`(6x,6x)(2x,2x)`

- A 4 ball trick

`(4,4)(4,0)`

- 3 balls in 4 ball synchronous fountain (1 missing)

By convention the left slot in the parenthesis is taken to correspond to
the left hand. Multiplexing can also be notated, exactly as above; for example
the 4 ball pattern `(4,2)(2x,[44x])`

has a multiplexed `'4'`

and `'4x'`

thrown with the right hand.

Imagine several people juggling, each person asynchronously, but synchronized
with respect to each other (i.e., all jugglers throw with their right hands at the
same time). This is the situation in 2-count 6 club passing, for
example. Now our notation has to tell *all* people what to do, which might
sound complicated but actually isn't too bad if we add a few things to what we
defined above.

Divide a "throw" into several
parts, the throwing instructions for each juggler. Continue to write a self-throw
as a single number, exactly as we did for siteswap notation
(a `2`

is a hold,
a `3`

is a low toss to the other hand, etc.).
So for example, `<3|3|3|3>`

is a
pattern that describes 4 jugglers each doing a 3-ball cascade.

What about passes? Append a `'p'`

to a number to
represent a passed throw. To figure out which of your partner's hands to
pass to, use this rule: If without the `'p'`

the throw would go to your left
hand, throw at your partner's left, and so on. If there are more than two jugglers, put a
number after the `'p'`

to indicate which
juggler you're passing to, with the convention that the leftmost juggler in the
`<|>`

is juggler #1, the next is juggler #2,
and so on. So for example, `<3p|3p>`

and
`<3p2|3p1>`

each describes the same passing
pattern, namely 6-object ultimate passing.

Some example passing patterns (note the average rule still applies):

`<3p|3p><3|3>`

- Ordinary 2-count 6 object passing. Notice how the instructions for each person are sectioned off. Each person starts throwing with his right.

`<3p|3p>`

- Ultimate passing, where all throws are passes.

`<3|3>`

- Two people doing 3 ball cascades.

`<4p|3><2|3p>`

- A left-handed double, if done once from the middle of a "cascade" (in this case
`<3p|3p><3|3>`

qualifies).

`<2|3p><2p|3><[3p/2]|3p><3|3>`

- A multiplexed pattern, the left-handed single. Do the first hold with your right hand, since that is when your partner is doing a
`'3p'`

. The`'2p'`

is from your left to his left, and then you resume. Note the use of`'/'`

in the multiplexed throw, to separate the two throws`'3p'`

and`'2'`

(otherwise the animator would think the`2`

was the target juggler for the`3p`

pass). This could also have been notated`[3p22]`

.

`<(4x,4xp)|(4x,4xp)>`

- A synchronous pattern with 2 jugglers and 8 objects. Note that the
`'p'`

comes after the`'x'`

. The`4xp`

is thrown to the other juggler's left hand, since a hypothetical`4x`

thrown as a self-throw from the right hand would go to the throwing juggler's left hand. Multiplexing can also be included in a synchronous pattern with multiple jugglers.

`<(2p3,4x)|(2xp3,4p1)|(2xp2,4xp2)>`

- A synchronous pattern with 3 jugglers and 9 objects.

The previous section described basic siteswap notation, which is also what is produced by the Juggling Lab siteswap generator. The animator portion of Juggling Lab also recognizes several extensions to this notation, to provide convenience and greater flexibility.

When a pattern contains a subpattern that you'd like to repeat multiple times, Juggling Lab provides
a simple way to indicate this without manually repeating the subpattern. For example, let's say you want
to do 10 throws of the 3-ball cascade, followed by two iterations of
`531`

. One way to achieve this would be to use the
pattern
`3333333333531531`

.

Using the subpattern repeat notation, you can also write this as
`(3^10)(531^2)`

. In all cases the result is as though
the subpattern had been written out manually the specified number of times.

Another convenience is simplified passing notation, which allows you to combine together multiple beats within a single `<|>`

. For example, 2-count passing with 6 can be shortened to
`<3p 3|3p 3>`

from the version `<3p|3p><3|3>`

discussed above. The only restriction is that the total
number of beats within a `<|>`

must be the same for all jugglers.

A final notational convenience was introduced by Ben Beever, who noted that many popular sync patterns are
symmetrical in the sense that the pattern consists of a throwing sequence which is then repeated with the
roles of the hands exchanged. One example is the see-saw or box
pattern `(4,2x)(2x,4)`

. The convention is to write only the
first half of the pattern, and attach a `"*"`

to indicate
the hands-exchanged repeat. In this way the box pattern can be written
`(4,2x)*`

.

Juggling Lab allows you to add instructions to each siteswap throw in order to change the way the juggling looks. Each modifier is a string of upper-case letters that comes after the throw it modifies, and the main action is determined by the first letter in the string:

– Bounce the throw off the floor. The format is to put as many**B**`B`

's as you want bounces, followed by the style of the bounce:`L`

for lift bouncing`F`

for force bouncing`HL`

for hyperlift bouncing (for a description of hyperforce/hyperlift bouncing, see this discussion on rec.juggling)`HF`

for hyperforce bouncing

`BL`

indicates regular lift bouncing with single bounces`BBF`

indicates force bouncing with double bounces`BBHL`

indicates hyperlift bouncing with double bounces

– Hold an object that would ordinarily be thrown (e.g., a**H**`'4'`

).

– Throw an object that would ordinarily be held (e.g., a**T**`'2'`

).

For example, `42T3`

is the siteswap
`423`

where the
`'2'`

is thrown, rather than held.
`<(2p3,4xBL)|(2xp3,4p1BL)|(2xp2,4xp2BL)>`

is
the three-juggler passing pattern mentioned above, only now all throws from the right hands are bounced off
the floor.

Juggling Lab also understands patterns in a combination of async and sync notations. A few examples:

`41x(4x,3)`

- A 3-ball pattern that is pretty close to
`(2,4)(4x,2x)`

in appearance.

`55556x56x1x(6x,4)(4,6x)(6x,4)(5x,7)(6x,4)`

- A pattern that switches between the 5-ball cascade and the sync pattern
`(6x,4)*`

. (This pattern could have been written`(5^4)6x56x1x((6x,4)*^1)(6x,4)(5x,7)(6x,4)`

to better indicate the subpatterns involved.)

Several new things are going on here, for example odd throw values
(`7`

and
`5`

) in a sync pair, and throws like
`"1x"`

and
`"5x"`

. These departures
are required to generate the change in rhythm as we switch between async and sync throwing.

Some words of explanation:

- The
`"x"`

suffix is generalized here to mean "throw to the opposite hand that you would in an async pattern". So a`"4x"`

is a crossing`4`

, and a`"1x"`

is a non-crossing`1`

(i.e., a short hold). - When there is a switch from a sync to an async section, how does Juggling Lab decide which
hand should start throwing? The rule is simple: If we label the beats 1, 2, 3, ... from
the start of the pattern, Juggling Lab by default makes all async throws on
*odd*beats out of the right hand, and throws on*even*beats out of the left. If you keep track of which beat you're on, you can tell what this default behavior will be. The hand choice can be overridden using`R/L`

specifiers; see below. - Juggling Lab always assumes a single beat of no throws after each
`(,)`

sync pair. So an async throw after a sync throw happens two beats after the sync throw is made. (The exception is for short-beat sync throws, described below: An async throw happens one beat after a short-beat sync throw.) - The siteswap average rule still holds for patterns in mixed notation.

The appropriate transitions between async and sync patterns can be tricky to figure out. One approach is to sketch a ladder diagram on paper. Juggling Lab's "Transitions" feature can also help, accessible as a tab on the main window.

As noted above, usual sync throws `(t1,t2)`

assume the beat immediately
following the sync throw is empty (no throws occurring). So for a sync pattern, each
hand throws every two beats, the same as async juggling. This preserves our
intuitions for how high a throw `X`

should be when we switch between sync and async
patterns.

In some cases it may be desirable to break this assumption and allow a throw on the beat
immediately following the sync throw. For this purpose you can use a "short-beat" sync throw,
which adds a `'!'`

to the throw pair signifying no empty beat immediately following.

One use for short-beat sync throws is to write an async pattern using sync notation. For example
the async pattern `5551`

can be written as `(0,5)!(5,0)!(0,5)!(1,0)!`

. Why would we do this?
Sometimes writing async patterns in this way can help to think about patterns that switch between
sync and async sections. For example: `(4,5x)(4,1x)!(0,5x)!(4,0)!(0,1x)!`

. The short-beat throw `(4,1x)!`

has a short
hold `1x`

that changes the timing from sync to async. (This latter pattern could also be written `(4,5x)(4,1x)!R5x41x`

using mixed async/sync
notation. See below for an explanation of the `'R'`

.)

By default, Juggling Lab assigns async throws on *odd* beats to the right land,
and throws on *even* beats to the left hand. Thus all async patterns start with the right hand (beat 1) and alternate.

In some cases we might want to override this default. For example in two-count 7 club passing,
the right hand of juggler #1 throws at the same time as the *left* hand of juggler #2. We would like to write two-count 7 club passing as something like
`<4xp|3><3|4xp>`

, where we
identify the first juggler as starting with her *right* (a pass), and the
second as starting with her *left* (a self).

Juggling Lab allows you to do this by using a hands specifier: Put a

or
**L**

before any asynchronous throw to cause that throw to be made by the left or right hand, respectively. Any subsequent async throws are made in an alternating manner from that point onward, until another
hands specifier is given. For example:**R**

`<R|L><4xp|3><3|4xp>`

- The solution to the 2-count 7 club passing problem. Juggler #1 starts with the right hand, juggler #2 starts with the left.

`L75`

- A 6-ball half shower, with the left throwing high.

A hands specifier may come at any point in the pattern; in particular there may be multiple hands specifiers, for example `R3R3xL3L3x`

which is a pattern with an unusual RRLL throwing rhythm.