Siteswap Notation VII: Sync-Async Transitions

The representation of transitions between asynchronous and synchronous juggling patterns using siteswap notation often leads to some confusion. The confusion is primarily caused by trying to describe these transitions within the limitations of simulator compatible siteswap sequences. As we saw in Siteswap Notation VI, in some situations, the simulator does not allow us to accurately represent a given juggling pattern. These simulator limitations get further exposed when dealing with transitions between asynchronous and synchronous patterns.

In the video below, I have demonstrated various versions of the asynchronous 3-ball cascade and the synchronous 3-ball shower patterns. The background metronome is set to 180bpm. In each case, I have indicated the simulator compatibility of the notation. We’ll analyze the transitions between asynchronous and synchronous patterns using these patterns.

As demonstrated in the video, the asynchronous 3-ball cascade at 180 throws a minute may be represented by the vanilla siteswap sequence S₁ = “3” with the default hand siteswap sequence H₁ = “2”. The synchronous 3-ball shower at 180 throws a minute may be represented by the synchronous siteswap sequence S₂ = “(2x 1x)” with the hand siteswap sequence H₂ = “(1 1)” implicitly assumed^[1]. Clearly, a transition between these two sequences is a case of both the object as well as the hand siteswap sequences transitioning.

Object Siteswap	S1	T12	S2	T21
	3	?	(2x 1x)	?
Hand Siteswap	H1	TH12	H2	TH21
	2	?	(1 1)	?

The complete sequence involving the transition between “3” and “(2x 1x)” has a mixture of asynchronous and synchronous throws. As we discussed in Siteswap Notation V, we can treat ALL the throws of such “mixed” sequences as synchronous throws. As shown in the video, the asynchronous siteswap sequence “3” juggled at 180 throws a minute, when represented as a synchronous sequence using hand siteswap “(1 1)”, can be written as “(3x 0) (0 3x)”.

Object Siteswap	S1		T12	S2	T21
	(3x 0)	(0 3x)	?	(2x 1x)	?
Hand Siteswap	H1	H1	H1	H1	H1
	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)

We have thus made the hand siteswap sequence “(1 1)” uniform across the two object siteswap sequences and reduced our problem to the transition between two object siteswap sequences alone.

A Solution

The below video demonstrates one way of making the transitions between the sequences S₁ = “(3x 0)*” and S₂ = “(2x 1x)” at 180 throws a minute.

Thus, we have got the transition sequence T₁₂ = “(3x 0) (0 2x) (2x 0)” to go from S₁ to S₂ and the transition sequence T₂₁ = “(1 3x) (3x 1) (0 3x)” to go from S₂ to S₁. One can verify with the permutation test that the sequence S₁T₁₂S₂T₂₁ = “(3x 0) (0 3x) (3x 0) (0 2x) (2x 0) (2x 1x) (1 3x) (3x 1) (0 3x)” is indeed a valid sequence^[2] and that either/both of the sequences S₁ and S₂ can be repeated multiple times, as long as the transition sequences between them, i.e., T₁₂ and T₂₁, are retained, to get a valid siteswap sequence.

Table 1: Cascade-Shower Transition

Beat	0	1	2	3	4	5	6	7	8
Object Siteswap	S1		T12			S2	T21
	(3x 0)	(0 3x)	(3x 0)	(0 2x)	(2x 0)	(2x 1x)	(1 3x)	(3x 1)	(0 3x)
Hand Siteswap	H1	H1	H1	H1	H1	H1	H1	H1	H1
	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)

Note that since the hand siteswap number is always “1”, any time the object siteswap number is also 1 (but not 1x!), we can “hold” the object. Though a perfectly valid solution, this is not simulator compatible.

Simulator Compatible Solution

The solution can be easily made simulator compatible by resorting to the collapsed beat equivalent sequence for Table 1, i.e., “(6x 0) (0 6x) (6x 0) (0 4x) (4x 0) (4x 2x) (2 6x) (6x 2) (0 6x)”. Effectively, this is the transition between the two simulator compatible collapsed beat sequences, S₁ = “(6x 0) (0 6x)” and S₂ = “(4x 2x)”.

Table 2: Simulator compatible Cascade-Shower Transition

Beat	0	2	4	6	8	10	12	14	16
Object Siteswap	S1		T12			S2	T21
	(6x 0)	(0 6x)	(6x 0)	(0 4x)	(4x 0)	(4x 2x)	(2 6x)	(6x 2)	(0 6x)
Hand Siteswap	H1	H1	H1	H1	H1	H1	H1	H1	H1
	(2 2)	(2 2)	(2 2)	(2 2)	(2 2)	(2 2)	(2 2)	(2 2)	(2 2)

If the first solution was not simulator compatible either in letter or in spirit, this collapsed beat version can be said to be simulator compatible only in letter, not in spirit. Remember that the philosophy of the collapsed beat representation was rooted in the conviction that a synchronous pattern can at best be thrown at half the throw rate of an asynchronous pattern. In that context, the solution of Table 2 comes up short.

Optimal Solution

The solution we’d like would involve juggling both the asynchronous and synchronous parts of the sequence at the fastest throw rate that the juggler can manage for each. In our case, this means that we’ll have to imagine that 180 throws a minute is the fastest asynchronous throw rate I can manage and the synchronous throw rate must therefore, be slower than that^[3] as the same hand cannot throw twice in succession as fast as two different hands can. In a simplistic model, this means that the throw rate for synchronous throws would be half the throw rate for asynchronous throws^[4]. In other words, the asynchronous sequence can continue to be S₁ = “(3x 0) (0 3x)”, at 180 asynchronous throws a minute. The synchronous sequence, on the other hand, should be S₂ = “(4x 2x) (0 0)”, so that no hand throws at successive beats, giving us 180/2 = 90 synchronous throws a minute. Below video shows a possible way to make the transition between these two sequences.

The shortest sequence S₁T₁₂S₂T₂₁ is now: “(3x 0) (0 3x) (4x 0) (0 1) (4x 2x) (0 0) (1 3x)”.

Table 3: The “Optimal Solution”

Beat	0	1	2	3	4	5	6
Object Siteswap	S1		T12		S2		T21
	(3x 0)	(0 3x)	(4x 0)	(0 1)	(4x 2x)	(0 0)	(1 3x)
Hand Siteswap	H1	H1	H1	H1	H1	H1	H1
	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)	(1 1)

Again, S₁ and S₂ could be repeated multiple times while retaining the transition sequences between them to generate a valid sequence. In Table 3, it appears that at beats #3 and #4, the left hand is throwing on successive beats and again when the sequence wraps back from beat #6 to beat #0, the right hand is throwing on successive beats. This seems to defeat our intention of creating a sequence where the same hand never throws on successive beats. However, notice that in each of these apparent problem cases, at least one of the throws corresponds to siteswap number 1. With the hand siteswap sequence being “(1 1)”, this throw can be simplified to a “hold”, so we’re never really required to throw with the same hand on two successive beats.

Simulator compatibility

The simulator though, can’t be made to comprehend such subtleties. The optimal solution meets the simulator requirements in spirit, but unfortunately, not in letter. Not only will the simulator think that there are throws from the same hand on successive beats, it will also not like the presence of odd siteswap numbers like 3x and 1 in a synchronous sequence. Therefore, we need the collapsed beat version of the optimal solution: “(6x 0) (0 6x) (8x 0) (0 2) (8x 4x) (0 0) (2 6x)”. This finally meets the simulator requirements in both spirit and letter. 

Table 4: Simulator compatible version of Optimal Solution

Beat	0	2	4	6	8	10	12
Object Siteswap	S1		T12		S2		T21
	(6x 0)	(0 6x)	(8x 0)	(0 2)	(8x 4x)	(0 0)	(2 6x)
Hand Siteswap	H1	H1	H1	H1	H1	H1	H1
	(2 2)	(2 2)	(2 2)	(2 2)	(2 2)	(2 2)	(2 2)

The insistence of the simulator on using the collapsed beat notation when representing synchronous sequences has led to siteswap numbers as high as 8 for a simple transition from a 3-ball cascade to a 3-ball shower. It creates the intimidating impression that one needs to be able to throw an 8 with reasonable control to be confident about juggling this 3-ball pattern! However, as explained and demonstrated in the “optimal solution”, this transition can be juggled with a maximum siteswap number of 4, without needing the same hand to throw on two successive beats and with the synchronous throw rate at half the asynchronous throw rate.

To get the true feel for what the pattern of Table 4 would look like as compared to say the completely asynchronous sequence “3” juggled by the same simulator, one should reduce the “beat duration” (or equivalent) control of the simulator to half the value that is set for the asynchronous sequence. However, this should not be done blindly for all synchronous patterns. For example, if simulating the sequence with collapsed beat notation “(4x 2x)” where all the throws are “genuinely synchronous”, one should retain the same beat duration setting as for the asynchronous sequences to get a true feel for the relative throw rate and throw heights for the two patterns.

Hopefully, it is now clear that simulator incompatible sequences are not necessarily “incorrect”. Conversely, simulator results need to be carefully interpreted, especially for asynchronous sequences not juggled with hand siteswap sequence “2” or for sequences which mix asynchronous and synchronous throws.

Musings

I’ll now try to anticipate and answer some questions that the readers of my blogs on siteswap notation may have so far.

More (Simulator) complexities

We said that the simulator compatible synchronous representation of the asynchronous 3-ball cascade sequence “3” would be “(6x 0) (0 6x)”. But the simulation of the synchronous version looks slower and has higher throws than the simulation of the asynchronous version. Can we get the asynchronous and synchronous versions to match without changing any other settings in the simulator? Let’s see. If we were to un-collapse the collapsed beats, the synchronous version would expand to “(6x 0) (0 0) (0 6x) (0 0)”. Now this is essentially an asynchronous sequence – at most only one hand actually throws an object at any given beat. The object siteswap numbers for this asynchronous sequence are obviously, “6 0 6 0” which can be reduced in terms of the minimal period to “6 0”. However, if you try simulating “6 0” in a simulator, it will show you a pattern with three objects juggled in one hand while the other hand does nothing – it’s nothing like the “(6x 0) (0 6x)”! This is because the moment the simulator sees an asynchronous siteswap, it will assume the hand siteswap sequence “2”. In this case, we wanted the hand siteswap sequence “4 0” but we can’t tell that to the simulator.

Interestingly, for the asynchronous sequence “6 0” and for the synchronous collapsed beat sequence “(6 0)”, the simulator will do exactly the same thing. Well, almost; it’ll probably change the hand which is doing the 3-in-1-hand pattern. Note, however, that technically, converting the asynchronous “6 0” to its collapsed beat version would have led to “(12 0) (0 0)”, again a slower and higher version of what we wanted!

The 4 2 3 demystified

My blog, The 4 2 3 demystified, was a case study of the asynchronous sequence “4 2” juggled with the hand siteswap sequence “1 3”. I also gave an alternate interpretation of this sequence as the “synchronous” sequence “(2 1) (2x 1) (1 2) (1 2x)” with all the 1’s juggled as holds. As should be understandable now, both alternatives cannot be simulated. One must understand that this is a limitation of the simulator and not a problem with either of the solutions. What can be simulated is the collapsed beat version “(4 2) (4x 2) (2 4) (2 4x)”. However, that blog was discussing the transition between the 3-ball cascade and the “4 2” juggled with hand siteswap sequence “1 3”, without any change in the throw rate between the two sequences. Then, if the asynchronous sequence is “3”, the “synchronous” sequence must be “(2 1) (2x 1) (1 2) (1 2x)” to retain the same throw rate. Alternatively, if the collapsed beat version is used for simulator compatibility, then the 3-ball cascade must also be written as “(6x 0) (0 6x)” and not as “3” to achieve the transition without changing the throw rate.

Siteswap Numbers vs Throw Heights

Notice that in the video demonstrating the Table 1 solution in this blog, “(3x 0) (0 3x) (3x 0) (0 2x) (2x 0) (2x 1x) (1 3x) (3x 1) (0 3x)”, the throw heights of the 3x and 2x are pretty much equal. This can happen if the flight time is the same in both cases due to a difference in how the siteswap number is split between the flight time and the hold time in each case. Here, the asynchronous 3x can be viewed as the combination of a 2x from one hand and then a hold (1) in the other hand. Remember that in Siteswap Notation V, we remarked that the sequence “(2x 1) (1 2x)” was in fact, the 3-ball cascade. Thus,  it is understandable that the 3x and the 2x are being thrown to the same height here.

Similarly, in the collapsed beat version of this solution, the asynchronous 6x would be thrown approximately as high as the synchronous 4x: the asynchronous 6x is effectively 4x from one hand and then a hold (2) in the other hand. The hand siteswap sequence “(2 2)” means that an object siteswap number of 2 can now be interpreted as a hold.

Collapsed Beats vs. Slow Motion

In the “collapsed beat version” of a sequence, every beat gets stretched to two beats. It might therefore be tempting to think of it as a slow-motion version of the original, running at half the speed. However, that’s not all there is to it. In the video below, I have slowed down the 180 throws a minute transition from “(3x 0)*” to “(2x 1x)” to half the speed to get an effective throw rate of 90 throws a minute. Next to it, I have also shown the collapsed beat equivalent transition “(6x 0)*” to “(4x 2x)” which is again an effective throw rate of 90 synchronous throws a minute.

Though the throws are indeed being made at the same time in both the cases, notice that the throws are much higher in the collapsed beat sequence. This is because to slow down the throw rate in real life, we also have to throw the object higher. The slow motion version is how the same timing could be achieved at a place where the acceleration due to gravity was 1/4 that on earth! This is because in the slow motion version, the object is now taking twice as long to cover the same vertical distance, as it would at normal speed. Apart from lower gravity, the horizontal component of the speed of the throw should also be halved.

Let’s say the acceleration due to gravity in the normal speed world is g_n and in the slow motion world is g_s. Further, the time taken for the object to fall from the highest point to the hand, i.e., fall the distance h, in the normal world is t_n and in the slow motion world is t_s.

Then, t_s = 2t_n. Also, h = (1/2)g_nt_n² = (1/2)g_st_s². Substituting t_s =2t_n, we get g_n = 4g_s. Or g_s/g_n = 1/4.

Footnotes

1. “(2x 1x)” is not a simulator compatible sequence. Yet, it is a correct representation of the pattern juggled in the video with the given beat (throw) rate.
2. This is an example where neither T₁₂ nor T₂₁ are valid sequences when considered in isolation.
3. It is because I’m capable of a faster asynchronous throw rate than 180 throws a minute that I was able to demonstrate even a synchronous sequence at that rate in the solution of Table 1.
4. In reality, the synchronous throw rate, though slower than the asynchronous throw rate, may not be exactly half of it. It could even be faster than half. But for now, we’ll use this simplistic model.