synch siteswap causal diagram

[nopoetsplease]

fair play, i'm double posting this: r.j and on jugglingedge.

i can't quite get my head around how to draw causal diagrams for synch
siteswaps.

in vanilla siteswaps, the dots representing the "hands" are
isometric/staggered to show the alternating throws. in synch, are the dots
lined up?

also, if i'm drawing the path of the 6x in a (6x 4)*, obviously projecting
the path six places will land it on the same hand. do you draw the path to
the seventh place or the 5th? or am i missing the point entirely?

thanks,
-alex

--
----== posted via www.jugglingdb.com ==----

[Vertigo]

Yep, the dots are lined up in synch.

A 6x should go 3 spaces forwards, and to the opposite hand. (And, in
general, an n-ball-height throw should go (n/2) spaces forwards, and to
the opposite hand if it's a crossing throw)

You'll notice when juggling 6x,4 that the 6x is thrown again 3 "beats"
later. So yes, in synch it is no longer true that a throw's siteswap
number represents how many beats later it's thrown again. This is the
tradeoff we make in exchange for maintaining the fact that a 6 in synch is
the same height of throw as a 6 in asynch.

[Miika]

nopoetsplease wrote:
> fair play, i'm double posting this: r.j and on jugglingedge.
>
> i can't quite get my head around how to draw causal diagrams for synch
> siteswaps.
>
> in vanilla siteswaps, the dots representing the "hands" are
> isometric/staggered to show the alternating throws. in synch, are the dots
> lined up?
>
> also, if i'm drawing the path of the 6x in a (6x 4)*, obviously projecting
> the path six places will land it on the same hand. do you draw the path to
> the seventh place or the 5th? or am i missing the point entirely?
>

The dots line up in synch.

In a ladder diagram, you draw paths for all the objects and a 6x will
land three pairs of dots forward on the other side. (Dwell times are
ignored so it leaves the hand immediately.)

In a causal diagram the paths don't indicate objects, but the reason or
cause those hands need to be emptied. This is basically a ladder diagram
with all the arrows arriving as many beats earlier, as there are hands
used in the pattern. Causal diagrams are most often used with passing
patterns.

A quick comparison of these two different diagrams for (6x,4)*:
http://www.mediafire.com/imageview.php?quickkey=tz4hnxv37nvh69a


-Miika

--

Siteswaps of the day: 6 , (6,6) , (6x,6x)

[^Tom_]

Vertigo wrote:
> You'll notice when juggling 6x,4 that the 6x is thrown again 3 "beats"
> later. So yes, in synch it is no longer true that a throw's siteswap
> number represents how many beats later it's thrown again. This is the
> tradeoff we make in exchange for maintaining the fact that a 6 in synch is
> the same height of throw as a 6 in asynch.

Or, by treating the 2 simultaneous throws as 2 events rather than 1 event
of 2, it sort of still makes sense - as the 6x will be thrown again at the
time of the 6th (and seventh).

0 -- 2 -- 4 -- 6
1 -- 3 -- 5 -- 7
or
0 -- 2 -- 4 -- 6
0a--2a--4a--6a

is essentially what you're doing, but you're now using only the top line
of numbers when dealing with timing.


0 -- 2 -- 4 -- 6
- 1 -- 3 -- 5 -

Would also work, as siteswap doesn't say that the beats have to be in
order, you can imagine stretching an asynch siteswap's beats towards a
synchronous one

such as: changing
0 -------- 2 -------- 4 -------- 6
---- 1 -------- 3 -------- 5 ----
to
0 -------- 2 -------- 4 --------6
-1 -------- 3 -------- 5 -------- 7

Using this method of writing the pattern, something like (4,4) would
become 4. but if you wanted to throw a (4x,4x), it would now be a (5,3),
but due to the distortion of the beats, a "(5" is the same height as a 4
and a "3)" is the same height as a 4 from the other hand.

Using a slightly different method, you could probably write (6x,4)* as 726
if you wanted to write it as an asynch siteswap.

I have a few issues with synchronous siteswaps, in that they degeneralize
siteswap from being a hand-agnostic order of throws to being 2 handed in
nature... but otherwise, they're just as simple as siteswap, but the "odd"
hand is now even too, so you end up with 2 beats called 0, 2, 4 etc.

hope this helps
(NB - i'd advise using a fixed width font to read this ;) - or copy/paste
to something like notepad)

^_

[^Tom_]

The 4th paragraph in part 8 of Allen Knutson's Siteswap FAQ v2 explains my
problem with synchronous siteswap. It's not a big problem, and I fully
understand the reason for it, it's just not very elegant.
http://www.juggling.org/help/siteswap/faq.html#gen

[Miika]

I'm trying to understand why synch siteswaps might feel like a bad
system. To
me, something like naming a vanilla siteswap and then separately telling
the
correct timing is far inferior. (Different ways of doing this have been
suggested, and I guess it can have it's uses in patterns with more complex
rhythms.) Your example of calling (4x,4x) as 53 with altered rhythm (one
hand
throws everything a beat too early) works but it doesn't illustrate the
pattern
nearly as well. Using (4x,4x) clearly shows it to be a symmetric pattern
at
first glance, it indicates the pattern being synchronous, and the relative
heights of the throws are similar to that of someone juggling an asynch
fountain with four. With the other way, there is room for confusion on
which
hand is throwing too early, which results in more than one way to notate
the
same pattern, like (6x,4)(6,4x) derived from both 7463 and 6455 , and 53
could
also mean (6x,2x) . Of course this can be worked around, but if for
instance
you are making a list of all the patterns, this is a large issue.

I can't help but feel the statement you reference as being very
old-fashioned,
or even close-minded in a way:

This [synchronous notation] 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.

Having extra beats in between the synch throws relates nicely to asynch
patterns. If you want to show what happens on those beats, you can use
something like (4x,4x)!(0,0)! or even <2p|2p> and explain that your hands
are
the passing partners. For me synchronous siteswaps are a very natural way
to
extend the siteswap idea into something a little different.

As for the averaging theorem, it would still hold, even if we didn't
double
the numbers. Of course it needs to be explained how to use it in such a
pattern
(or multiplex, or passing etc.) but this applies to any formula in any
system
that you want to expand to include some other system as well! In any case
the
argument for doubled numbers comes down to it being practical, not just
theoretically sound.

Of course this thread started about causal diagrams, easily confused with
ladder diagrams. Not much to say about those right now, but they look good
on
the Juggling Edge!

Just thinking,

-Miika

--

btw, tämä on toinen viestini tältä sivustolta

--
----== posted via www.JuggleJunction.org ==----

[^Tom_]

Just to make this unambiguously clear, I accept and use (,) synch siteswaps.
I just have some issues with them.

As I explained, Allen Knutson explained on my other post which contextualized
my post, and even your post pointed out - they have their oddities.

Mainly, they diverge from the original point of siteswap - not a lot, but they
do. Normal siteswap arithmetic (states, swapping sites) do not work.
They add implied non-existent beats just so that people like you - most people
- think they're more normal.

I would prefer that 2 in one hand were called 2, or (2,0), but I know that
convention is too well established now - so I'm only preaching to those with
interest in siteswap theory.
I like the fact that siteswap (or at least the numbers in it) doesn't know or
care how many hands are at work. It's simply an ordering system.

You talk about heights, but it's nothing to do with heights [siteswap has
nothing to do with heights]. It's the same argument as 4 handed siteswaps for
passing patterns.
A) apply the vanilla principles about number of hands that throw until object
is thrown again
vs
B) treat everything in a directly analogous way to solo asynch juggling,
because jugglers know what height a 4 is.

Both have merits, but I know which one I prefer. I don't accept that the
argument about height is correct - but I get the idea makes some sense.
I favour the more mathematically correct one, not the one that most jugglers
would just "get"[1].

And, yes, as you say, the original discussion was about causal diagrams,
easily confusable with ladder diagrams. Or, as I suspect, it was a question
about ladder diagrams, easily confused with causal diagrams. (And I think the
original question has been answered - here by you and on the edge by me.)


^_
--
1 - I've heard lectures, read papers, heard people explaining, giving
workshops etc about siteswap where they describe a 4 as "the same sort of
throw as when doing 4 balls". This isn't the same as, and is what I'm sure is
a much better definition, "a throw which is thrown again 4 beats later".
But then again, when teaching the basics, the difference is subtle, and the
former explanation is clearer

--
----== posted via www.jugglehub.com ==----

[Aidan]

I have a slightly different take on synch siteswaps. If you think of a
beat as a moment when you
can throw or catch a ball, then the 6 is thrown 6 beats later.
Aidan.