## More general notations

So far we've been doing things with the vanilla restriction that only one hand is throwing at a time - and in fact that the hands are alternating, saying the other hand is "throwing" a 0 or 2 if it seems to be doing nothing. How does the notation complicate if we remove this?

In two ways: before, we indicated the one throw that was going on at any time. Now, we have to indicate the throws that each hand is doing. (What if some hands aren't doing any throws? We've already figured out the kludge for that; declare that they're doing the "hold throw" or the "empty hand throw", which in vanilla siteswap was 2 or 0, respectively.)

 Take the example of the shower-box. The notation for this pattern is ``` (2x,4) (4,2x) ``` which means first that the right hand does a 4, while the left hand does a 2 that crosses. Then the left hand does a 4, while the right hand does a 2 that crosses. (2x,4)(4,2x)
 4 This no longer really quite fits in with "The Siteswap Idea" that a throw be labeled by one plus the number of throws while it's in the air - shouldn't we just be calling those things 1's and 2's instead of 2's and 4's? Basically, mathematically, the answer is yes. But this doubling of all the numbers in "synchronous siteswap" is by now pretty standard, because it gives the proper indication of the relative heights of the throws. For example, most people asynchronously fountain 2N balls at the same height as they synchronously fountain 2N, so it would be a little weird calling the throws 2N's in vanilla siteswap and N's in synchronous siteswap. Also, the averaging theorem is still true only if you double the numbers. (4,4)

Here are some more examples of synchronous patterns to think about:
synchronous showers
 (4x,2x) (6x,2x)
3-in-one-hand, 2-in-the-other
 (6,6)(6,2) (6,4)
4-ball shower-boxes
 (8,2x)(4,2x)(2x,8)(2x,4) (6x,2x)(2x,6x)

 (6x,2)(6,2x)(2,6x)(2x,6) (6,2x)(6,2x)(2x,6)(2x,6) Compare and contrast these two on the left with some asynchronous analogues, 534 and 61616. (61616 is not really all that analogous to (6,2x)(6,2x)(2x,6)(2x,6) since it has three 6s on each side rather than two.) 534 61616

This notation extends in an evident way to more hands - put in more commas, and say which other hand you might be throwing to, instead of just "x". This sometimes gets called "Multi Hand Notation" - but there's nothing frightening in it beyond the step from 1 to 2 hands.

Basically all of the theory of vanilla siteswaps applies to these too, mutatis mutandis - you can follow a single ball to see what it does, divide the sum in that orbit by the total number of numbers to see how many balls are in the orbit, and so on.

Thus is defeated the first vanilla restriction. (Which of course doesn't mean that vanilla siteswap is now defunct - it is more convenient for describing those patterns that it can describe.)

The other restriction, No Multiplexing, is simpler to get around. Instead of saying what throw a hand is doing, we write down all of the throws it's doing, and put them in []'s to indicate that they happen at the same time. (Notice that this modification is completely independent of the ones we needed to institute for synchronous siteswap, and the examples below will be both synchronous and asynchronous multiplex patterns.)
 For example, how do you juggle the asynchronous multiplex pattern ...444423[34]4444... in the middle of fountaining four? At some point hold with (say) the right hand, which is the 2, and so catch a second ball in the right hand. Then do a 3 from the left. Then do a multiplex from the right, throwing one across as a 3, the other up as a 4. Go back into 4. 44423[34]

 [23] N.B. The fact that siteswap doesn't tell you whether a 2 is a hold or a really dinky throw comes home to roost with these patterns. For example, the pattern [23] can either be interpreted as "juggle 3 while holding an extra one in each hand" or "do the easiest multiplex with 5", respectively. (You can tell the juggler applet to throw a 2 with the t throw modifier.) [2t3]

Here are some asynchronous multiplex patterns, and one synchronous:
 24[54]
 25[56]2
 25[75]51
 ...21[75]1...
 ([62],2) (6x,[22]) (2,[62]) ([22],6x)

Again, all the theory from the vanilla case extends to multiplex patterns too. The "averaging" theorem is a little different: you add up all the numbers, and divide by the number of throw times, not the number of balls thrown. For instance, in the 5-ball multiplex [23], we divide 2+3 by 1, not by 2. A pattern is valid if the number of balls landing at a given time is the same as the number of balls being thrown. And so on.

The substantial difference is that it becomes impossible to track a single ball - when you multiplex, it's up to you which ball does which throw. No doubt this freedom could be removed by adopting some convention regarding the order that the multiplex throws are listed - [23] being a slightly different pattern than [32] - but nobody has bothered to make the arbitrary choices to set up this system. (Not that you were worried about it anyway!)