Vanilla siteswap sequences are used to represent vanilla juggling patterns[1] which involve at most one object being thrown at a time. This notation wasn’t meant to comprehend “body moves”, multiplex and synchronous throws, etc. and so it is not surprising that the notation had to be extended[2] to take care of these scenarios. However, one finds that even for vanilla patterns, many extensions of the vanilla notation exist. In this blog, I will explore what scenarios prompted the creation of such extensions, why they get messy and how an alternative methodology can eliminate much of the clutter and confusion they cause.
The Assumptions of Convenience
When speaking of vanilla siteswap sequences, most authors, implicitly or explicitly, make two assumptions which are convenient for visualization purposes, but otherwise unnecessary:
- The sequence describes juggling patterns involving two hands (right and left) which throw alternately.
- The throws are uniformly spaced in time.
Assumption 1 immediately leads to a corollary: Throws with even siteswap numbers come back to the throwing hand, while throws with odd siteswap numbers go to the other hand.
Juggling patterns often violate one or the other of these assumptions, if not both. The juggling world seems to be particularly uncomfortable with the idea of Assumption 1 being violated[3], while being more accepting of Assumption 2 being violated. This has led to terminology like “hurries”, “galloped” patterns, “polyrhythms”, etc., to describe patterns violating either/both of these assumptions. Some of these concepts (e.g., hurries) have in turn spawned corresponding extensions to the vanilla siteswap notation. Unfortunately, different juggling simulators have adopted different extension schemes, adding to the confusion.
In this blog, we compare this traditional approach against a contrary approach, i.e., we allow Assumption 1 to be violated but insist on enforcing Assumption 2. To allow for Assumption 1 to be violated, we describe a vanilla juggling pattern as a combination of a vanilla Object Siteswap Sequence (OSS) and a vanilla Hand Siteswap Sequence[4] (HSS). The vanilla HSS for the “two hands throwing alternately” case would be “2” as has been discussed in Siteswap Notation II. In general, the HSS allows for any number of hands to be involved and they can be throwing in any sequence. In particular, in the case of two hands, they need not throw alternately. Note that this also invalidates the corollary of Assumption 1. Whether the object siteswap number for a given throw is even or odd, the throw could either go back to the throwing hand or go to the other hand, depending on the HSS.
Non-alternating hands
Let us now see how the traditional approach handles the case of Assumption 1 being violated and how it compares with the proposed method of using an OSS+HSS combination. As an example, we use the pattern shown in the below video which corresponds to OSS “3” juggled with HSS “1 3” as has been worked out in the video.
Hurries
If in the two handed case, the hands are not throwing alternately, then one or the other hand must be making two (or more) throws in succession. A concept called “hurry” has been introduced to describe this situation and is implemented in the JoePass! simulator. To represent a hurry, JoePass! uses an asterisk (*) after the siteswap number to denote a throw being made by the same hand as the previous throw. Further, to represent an even throw going to the other hand or an odd throw coming back to the throwing hand, an “x” is used after the siteswap number. For example, JoePass! produces a similar pattern to the video above when asked to simulate the sequence “4x 4*”.
Specifying Hands
The Juggling Lab simulator has a different way of allowing one to specify the hand making each throw. The Juggling Lab sequence which reproduces our pattern from the video is “R3 R3x L3 L3x”. R indicates a right hand throw and L, a left hand throw. The meaning of the “x” is the same as explained above for JoePass!.
Though the symbols used are different, the philosophy is similar.
Consider the following:
- Additional symbols create clutter. Further, symbols like “*” and “x” are used differently in synchronous notation, causing confusion.
- More importantly, the permutation and average tests[5] now need to be modified to comprehend the new symbols.
In contrast, in the proposed representation both OSS “3” and HSS “1 3” can be evaluated independently with unchanged permutation and average tests. Any combination of a valid OSS and a valid HSS will give a valid juggling pattern. The only exception is if the hand siteswap number is “0” when the object siteswap number is non-zero, for that would mean the need to throw an object without a hand being available to do so.
Non-uniform throws
We now move to the study of cases where Assumption 2 is violated. Further terminology has been introduced to describe such patterns.
Galloped Patterns
A popular term used to refer to juggling patterns with non-uniform throwing rhythms is “galloped patterns”. There is no specific notation to indicate that a pattern is galloped – it is a qualitative description of the pattern. Interestingly, galloped patterns have also been used to represent patterns which have uniformly spaced throws made by non-alternating hands as patterns which have alternating hand throws which are non-uniformly spaced. The argument is outlined below.
If we find two successive throws being made by the same hand, we say that between these throws, there is an off-beat, “invisible” throw being made by the other hand. An invisible throw could either be an empty hand, or a “hold”. The empty hand is a “0” throw and the held object is a “2” throw in the alternating hands scenario. The pattern described as the object siteswap sequence “3” juggled with hand siteswap sequence “1 3” can therefore, be viewed as a “galloped 5 0 4”, where the “0” is the invisible, off-beat, other hand throw occurring “somewhere” between two successive throws from the same hand.
The galloped throw does not have any associated notation but still creates confusion. It does not specify which throws are off-beat and by how much. Further, once one goes down this path, where does one stop? For example, the uniformly spaced patterns “7 5 1 2 0”, “9 0 0 5 1” and “9 5 0 0 1” could all be called the galloped “5 3 1”. The nuances of the relative difficulty of juggling these patterns are completely lost.
Polyrhythms
What if the two (or more) hands involved in a juggling pattern are following independent throwing rhythms? For example, let’s consider the two-handed case where the right hand is throwing every 0.5s while the left hand is throwing every 0.75s. Since we’re restricting ourselves to vanilla patterns (one throw at a time involving at most one hand/object), let us further say that the right hand starts throwing at time = 0s and the left hand starts at time = 0.6s, so that synchronous throws are avoided. The timeline of the first few throws is shown in Table 1.
| Throw # | Time (s) | Throwing Hand | Time since previous throw |
|---|---|---|---|
| 0 | 0 | Right | – |
| 1 | 0.5 | Right | 0.5-0 = 0.5 |
| 2 | 0.6 | Left | 0.6-0.5 = 0.1 |
| 3 | 1.0 | Right | 1.0-0.6 = 0.4 |
| 4 | 1.35 | Left | 1.35-1.0 = 0.35 |
| 5 | 1.5 | Right | 1.5-1.35 = 0.15 |
| 6 | 2.0 | Right | 2.0-1.5 = 0.5 |
| 7 | 2.1 | Left | 2.1-2.0 = 0.1 |
| 8 | 2.5 | Right | 2.5-2.1 = 0.4 |
| 9 | 2.85 | Left | 2.85-2.5 = 0.35 |
| 10 | 3.0 | Right | 3.0-2.85 = 0.15 |
| 11 | 3.5 | Right | 3.5-3.0 = 0.5 |
Notice that the hands don’t throw alternately. Therefore, this pattern is in violation of Assumption 1. Further, the “time since previous throw” is not constant, so it is also in violation of Assumption 2 (uniform spacing). To complete the picture, let us further say that the object siteswap sequence being juggled in this fashion is “3”. By definition, this means that for each beat, the object thrown at that beat is to be thrown again 3 beats later. Table 2 represents the updated table with the objects being thrown at each beat also indicated.
| Throw # | Time (s) | Throwing Hand | Time since previous throw | Object thrown |
|---|---|---|---|---|
| 0 | 0 | Right | – | A |
| 1 | 0.5 | Right | 0.5-0 = 0.5 | B |
| 2 | 0.6 | Left | 0.6-0.5 = 0.1 | C |
| 3 | 1.0 | Right | 1.0-0.6 = 0.4 | A |
| 4 | 1.35 | Left | 1.35-1.0 = 0.35 | B |
| 5 | 1.5 | Right | 1.5-1.35 = 0.15 | C |
| 6 | 2.0 | Right | 2.0-1.5 = 0.5 | A |
| 7 | 2.1 | Left | 2.1-2.0 = 0.1 | B |
| 8 | 2.5 | Right | 2.5-2.1 = 0.4 | C |
| 9 | 2.85 | Left | 2.85-2.5 = 0.35 | A |
| 10 | 3.0 | Right | 3.0-2.85 = 0.15 | B |
| 11 | 3.5 | Right | 3.5-3.0 = 0.5 | C |
How can a vanilla siteswap sequence differentiate between this way of juggling “3” vs. the regular 3-object cascade?
Galloped approach
As before, one can resort to “invisible” throws to fix the “problem” of non-alternating hands. This means we have to insert a left hand throw between throw #0 & #1, throw #5 and #6 and so on. This would lead to the event sequence as shown in Table 3 which corresponds to the siteswap sequence “4 0 3 3 4 4”.
| Throw # | Time (s) | Throwing Hand | Time since previous throw | Object thrown |
|---|---|---|---|---|
| 0 | 0 | Right | – | A |
| 1 | ? | Left | ?-0 = ? | – |
| 2 | 0.5 | Right | 0.5-0?= ? | B |
| 3 | 0.6 | Left | 0.6-0.5 = 0.1 | C |
| 4 | 1.0 | Right | 1.0-0.6 = 0.4 | A |
| 5 | 1.35 | Left | 1.35-1.0 = 0.35 | B |
| 6 | 1.5 | Right | 1.5-1.35 = 0.15 | C |
| 7 | 2.0 | Left | ?-1.5 = ? | – |
| 8 | 2.0 | Right | 2.0-? = ? | A |
| 9 | 2.1 | Left | 2.1-2.0 = 0.1 | B |
| 10 | 2.5 | Right | 2.5-2.1 = 0.4 | C |
| 11 | 2.85 | Left | 2.85-2.5 = 0.35 | A |
| 12 | 3.0 | Right | 3.0-2.85 = 0.15 | B |
| 13 | 3.5 | Left | ?-3.0 = ? | – |
| 14 | 3.5 | Right | 3.5-? = ? | C |
A simulated version of “4 0 3 3 4 4” will, however, show uniformly spaced throws.
Though the “0” throws do lend a “galloped” feel to the pattern, the timing is very different from what was intended in Table 2.
Juggling Lab Extension
Instead of forcibly writing the pattern as one using alternating hand throws, we can use the hand-specifying extended notation of Juggling Lab to capture the hand sequence of this pattern and write it as “R3x R3 L3 R3x L3x”.
This still does not solve the problem of mimicking the irregular throw timings accurately. If anything, the throws are even more regular than we got through the galloped approach.
JoePass! extension
JoePass! allows one to provide fractional siteswap numbers and delays between throws that can create non-uniformly spaced throws. After breaking my head over it for a long time, I thought the following instruction set for JoePass! should have led to an accurate simulation of the pattern of Table 2. The numbers represent number of beats assuming each beat is of 0.25s duration.
#sx
#D -
#jugglerDelay 1 l 0
4 0 3.4
#jugglerDelay 1 l -.6
3.6 4
#jugglerDelay 1 l .4
3x
I got the following simulation result, but the timing doesn’t appear correct.
The two crossing throws should be closest to each other with just 0.1s gap, but that isn’t the case – I’m guessing the negative jugglerDelay value didn’t work. Even if there is a way to replicate the exact timing of Table 2, JoePass! documentation itself states that by adopting this notation, “we messed up everything that was a clear and logical theory…”.
The documentation further says, “… this [notation messing up the theory] is necessary if we want to make it possible to write down some of the really interesting patterns.” Let us see if this is indeed the case.
Proposed approach
We now use the juggling pattern corresponding to Table 2 to present an approach that can take care of all the ‘special” cases discussed above without “messing up the theory” or needing any tweaking of algorithms that hold for vanilla siteswaps. Contrary to the traditional approach, we will insist on Assumption 2 but give up on Assumption 1.
First, we consider the smallest number appearing in the “time since previous throw” column of Table 2. This is 0.1 and we set Beat duration T = 0.1s. The first instance of two throws being separated by 0.1s is the throw #2 occurring at T2 = 0.6s. We say that throw #2 occurred during the beat lasting from T2-T/2 to T2+T/2, i.e., from 0.55s to 0.65s. We now mark out the rest of the beats as shown in Table 4. To avoid ambiguity at the borders of the beat intervals, we include the starting time in the beat interval and exclude the ending time – that will be included as the starting time of the next beat interval.
| Beat Interval | Throw # | Beat # | Throw time (s) | Throwing Hand | Object Thrown |
|---|---|---|---|---|---|
| [-0.05, 0.05) | 0 | 0 | 0 | Right | A |
| [0.05, 0.15) | – | 1 | – | – | – |
| [0.15, 0.25) | – | 2 | – | – | – |
| [0.25, 0.35) | – | 3 | – | – | – |
| [0.35, 0.45) | – | 4 | – | – | – |
| [0.45, 0.55) | 1 | 5 | 0.5 | Right | B |
| [0.55, 0.65) | 2 | 6 | 0.6 | Left | C |
| [0.65, 0.75) | – | 7 | – | – | – |
| [0.75, 0.85) | – | 8 | – | – | – |
| [0.85, 0.95) | – | 9 | – | – | – |
| [0.95, 1.05) | 3 | 10 | 1.0 | Right | A |
| [1.05, 1.15) | – | 11 | – | – | – |
| [1.15, 1.25) | – | 12 | – | – | – |
| [1.25, 1.35) | – | 13 | – | – | – |
| [1.35, 1.45) | 4 | 14 | 1.35 | Left | B |
| [1.45, 1.55) | 5 | 15 | 1.5 | Right | C |
| [1.55, 1.65) | – | 16 | – | – | – |
| [1.65, 1.75) | – | 17 | – | – | – |
| [1.75, 1.85) | – | 18 | – | – | – |
| [1.85, 1.95) | – | 19 | – | – | – |
| [1.95, 2.05) | 6 | 20 | 2.0 | Right | A |
| [2.05, 2.15) | 7 | 21 | 2.1 | Left | B |
| [2.15, 2.25) | – | 22 | – | – | – |
| [2.25, 2.35) | – | 23 | – | – | – |
| [2.35, 2.45) | – | 24 | – | – | – |
| [2.45, 2.55) | 8 | 25 | 2.5 | Right | C |
Counting the beats between successive throws of the same objects and also between successive throws by the same hand, we see that Table 4 corresponds to the OSS “10 0 0 0 0 9 9 0 0 0 10 0 0 0 7” with the HSS “5 0 0 0 0 5 8 0 0 0 5 0 0 0 7”. The HSS can be incorporated into the hand specification extension of Juggling Lab to write the sequence as “a 0 0 0 0 R9 9 0 0 0 Ra 0 0 0 L7x” where a = 10. Finally, note that the beat duration should be set to 0.1s, i.e., 10 beats per second, in the simulator.
Thus, we can almost exactly[6] replicate this so-called polyrhythmic, galloped juggling pattern as a combination of vanilla object and hand siteswap sequences which assume uniformly spaced throws, without “messing up” the “clear and logical theory”.
PR Vaidyanathan, pursuing his M.Tech. in Computer Science at the Indian Institute of Technology, Gandhinagar (IITGN) is working with me to write a juggling simulator[7] based on the OSS+HSS concept. Taking Eric Gunther’s Gunswap simulator as a starting point, we have developed a preliminary version which accepts inputs in OSS+HSS format. Using this modified Gunswap simulator, OSS “a 0 0 0 0 9 9 0 0 0 a 0 0 0 7” with HSS “5 0 0 0 0 5 8 0 0 0 5 0 0 0 7” produces the animation shown below.
It can be shown that if the throw rates of various hands involved in a polyrhythmic patterns are rational numbers, then we will always find a sequence of throw time differences that repeats, therefore, enabling the algorithm described above to determine an equivalent siteswap sequence involving uniformly spaced throws. If the numbers are irrational however, the throw time differences may not form a repeating sequence. However, in that case, by definition, the pattern is also not a repeating one and therefore, outside the purview of siteswap notation.
The individual hand rhythms, apart from being different, could themselves be galloped. As long as the pattern repeats after a certain period (failing which, we wouldn’t call it a pattern in the first place), the above approach will work and we can continue to have a world which follows a “clear and logical theory”. In part II, we’ll apply the methods developed in this blog to some real life examples.
Footnotes
- By “pattern” we mean a repeating sequence.
- Mike Day’s Mills Mess State Transition Diagram, Denis Paumier’s Topological Notation, and Jack Boyce’s multiplex and synchronous notations are example extensions.
- Perhaps with good reason. See “Musings” section at the end of Siteswap Notation II.
- This idea is not new. For example, it has been mentioned in Burkard Polster’s “Mathematics of Juggling”.
- See Siteswap Notation I.
- In Table 4, all the throw times lie in the centre of the beat duration, except the throw at 1.35s, which is at the edge of the beat duration. This will cause a 0.05s error in the simulated timing. This error can be minimized by choosing ever smaller beat durations at the cost of larger siteswap numbers and longer sequences.
- Apart from software development, Vaidyanathan is also interested in collecting and designing twisty puzzles like the Rubik’s cube.