v2.0 Notes

Reached a good stopping point for v2.0 faster than I expected. I added the following:

• User inputs for beat duration, dwell duration, prop radius and prop coefficient of restitution (ie. bounciness)
• Support for bounce juggling
• Add any number of "B" characters to a single toss to make it a bounce (the number of bounces is the number of B's). Must follow each B with an L (lift), F (force), HL (hyperlift) or HF (hyperforce). So 5 ball lift bounce pattern would be "5BL"
• http://jugglinglab.sourceforge.net/html/ssnotation.html explains the bounce notation I used
• Animated jugglers
• First person camera option
• User input for animation speed

Priorities for the next version:

• Synchronous siteswap "halving" issue
• Alternative dwell paths like reverse cascade, windmill and mills mess
• Alternative props like clubs and rings

Soon I'd like to write a post about my dwell path and flight path interpolation algorithms. Definitely needs explaining because the code is starting to look a little messy.

gunswap v1.0 released!

I am happy to announce that after way too much tinkering and half-complete little scripts, gunswap v1.0 is complete!

All you can do right now is enter a standard siteswap pattern and see it animated in the browser (I've done all my development in Chrome). There is support for vanilla, multiplex, synchronous and passing siteswaps. That lays the groundwork for a lot of cool improvements - what's next?

Version 2 will probably focus mostly on more inputs for configurable parameters. The trick is going to be determining which are the most important. Here are some general categories of input parameters and/or new features:

• Synchronous siteswap "halving" issue. Consider adding (0,0) in between each beat to make throws match up with async siteswap better.
• Environment
• Gravity
• Beat duration
• Dwell ratio
• Props
• Cosmetic properties like size, shape and color
• Consider options for different types of props like clubs and rings
• Coefficient of restitution (if we implement bounce juggling)
• Toss modifiers
• Force/lift bounce
• Rotation of prop (more useful for things like clubs and rings - not really noticeable with balls)
• Dwell path
• Current dwell path is just a circle which has options for center, radius and points of catch/release
• Totally custom dwell paths could be made using some kind of bezier curve algorithm. http://bseth99.github.io/projects/animate/2-bezier-curves.html looks like it has some potential and I think this is how Juggling Lab does it
• Passing
• Define juggler positions
• Allow jugglers to move
• Animation
• 2D option
• Lighting and shading
• Animation speed
• Database backend
• Not sure how interested in this I am, it would be nice to be able to save patterns, but this seems like it would shift the focus of the project

Siteswap validation

In the previous post we discussed validating the format of a siteswap string using regular expressions. However, this is not sufficient for completely validating a siteswap pattern. We need to ensure that all the throws defined by the pattern can be repeated indefinitely without props ever colliding. This can be achieved using state arrays that are frequently associated with siteswaps.

A state diagram will reflect the position of all props at each beat in the pattern. Consider the following state array:

01x23

The state array indicates the time at which each prop is going to land. Prop 0 is landing now. Prop 1 is landing in 1 beat. Prop 2 is landing in 3 beats. Prop 3 is landing in 4 beats. A state diagram should always be the length according to its maximum toss. So if a siteswap has a maximum toss of 7, the state diagrams for that pattern should all be length 7.

Now consider the very basic siteswap 3. We will construct a state array for each beat in the pattern, starting of course when there are no props

3

BEAT 0 NO PROPS xxx
BEAT 1 TOSS 3   xx0
BEAT 2 TOSS 3   x01
BEAT 3 TOSS 3   012
BEAT 4 TOSS 3   120
BEAT 5 TOSS 3   201
BEAT 6 TOSS 3   012
BEAT 7 TOSS 3   120
BEAT 8 TOSS 3   201
...

Notice how beats 3 through 5 could essentially go on forever. This indicates that our siteswap is valid. 

Now let's consider siteswap 531 and try to figure out how we can programmatically identify when we've reached a repeatable set of state arrays.

531

BEAT 0 TOSS 5 xxxx0
BEAT 1 TOSS 3 xx10x
BEAT 2 TOSS 1 210xx

Let's say that a pattern is initialized once all props have been introduced to the pattern and we've completed all of the toss instructions in the siteswap.

BEAT 3 TOSS 5 10xx2
BEAT 4 TOSS 3 0x12x
BEAT 5 TOSS 1 012xx
BEAT 6 TOSS 5 12xx0
BEAT 7 TOSS 3 2x10x
BEAT 8 TOSS 1 210xx
BEAT 9 TOSS 5 10xx2

Let's say that the pattern is complete when we've reached the first throw and we're back at the first state. Thus, our repeatable pattern is the state array represented by beats 3 through 8.

Take note that when a pattern ends in a state where all props are landing sequentially, we'll call this a "ground state" siteswap. This basically just means that you can enter and exit the pattern from the cascade or fountain pattern.

Now consider an excited vanilla siteswap like 51. This siteswap cannot be entered from the ground state and that affects its initialization process.

51

BEAT 0 TOSS 5 xxxx0
BEAT 1 TOSS 1 1xx0x

At this point we would generally toss prop 2 into the mix, but we can't because prop 1 is landing now and needs to be tossed. Thus, we toss prop 1 and save prop 2 for the next beat.

BEAT 3 TOSS 5 xx0x1
BEAT 4 TOSS 1 20x1x - INIT
BEAT 5 TOSS 5 0x1x2
BEAT 6 TOSS 1 01x2x
BEAT 7 TOSS 5 1x2x0
BEAT 8 TOSS 1 12x0x
BEAT 9 TOSS 5 2x0x1
BEAT 10 TOSS 1 20x1x 
BEAT 11 TOSS 5 0x1x2 - COMPLETE

As you can see above, our repeating pattern is beats 5 through 10.

For synchronous siteswaps we need to extend this state model to include left/right hands. Consider (4,4):

(4,4)
LEFT RIGHT
x0   x1
02   13 - INIT
20   31 
02   13
20   31 - COMPLETE

For multiple jugglers we need to extend this state model to include each juggler. Consider <3p|3p>:

<3p|3p>

JUGGLER 1  JUGGLER 2
LEFT RIGHT LEFT RIGHT
xxx  xxx   xxx  xxx
xx1  xxx   xx0  xxx
x1x  xx3   x0x  xx2
1x5  x3x   0x4  x2x - INIT
x5x  3x0   x4x  2x1
5x2  x0x   4x3  x1x
x2x  0x4   x3x  1x5
2x1  x4x   3x0  x5x
x1x  4x3   x0x  5x2
1x5  x3x   0x4  x2x
x5x  3x0   x4x  2x1 - COMPLETE

Finally, consider the multiplex pattern 33[33]. For multiplex patterns we will delimit the landing beats using brackets.

33[33]

JUGGLER 1
LEFT        RIGHT
[x][x][x]   [x][x][x] 
[x][x][0]   [x][x][x] 3
[x][0][x]   [x][x][1] 3
[0][x][2,3] [x][1][x] [33] - init
[x][2,3][x] [1][x][0] 3
[2,3][x][1] [x][0][x] 3
[x][1][x]   [0][x][2,3] [33]
[1][x][0]   [x][2,3][x] 3
[x][0][x]   [2,3][x][1] 3
[0][x][2,3] [x][1][x] [33]
[x][2,3][x] [1][x][x] 3 - complete

So how do you tell when a siteswap is invalid? This occurs when there is a conflict between the number of props landing in a hand and the number of props expected to be tossed by that hand. Consider an invalid siteswap 513.

513

BEAT 0 TOSS 5 [x][x][x][x][0]
BEAT 1 TOSS 1 [1][x][x][0][x]
BEAT 2 TOSS 3 [x][x][0,1][x][x]
BEAT 3 TOSS 5 [x][0,1][x][x][2]
BEAT 4 TOSS 1 ERROR: EXPECTING 1 PROP, 0 LANDING