Passing Records!

Search posts
Forum index

 

Orinoco -

Passing Records!

After an enormous amount of blood, sweat & tears (actually just the third one) the records section now supports a number of passing patterns. The filter page has a new control so you can filter by solo & passing patterns too.

So for the passers:

Please have a play, it is inevitable that I have broken something!

Woett, Esther, Rob van Heijst, Mees Jager, CamS, Sidney Kloek, Jan Poolen, Heydar, Brook - can I assume all your records with ridiculously high numbers of 'passingballs' were done on 1-count? I can quickly change those over to the new format.

Is there a way to validate Préchac notation beyond the very basic: /<[\d\s\.p\|\*]+>/ (which for the non geeks just checks for valid characters)?

Marvin, did you enjoy our passing session today?

#NewFeature

Marvin - - Parent

No.

The Void - - Parent

By the way, Marvin, I was pleased to rediscover these audio gems after not hearing them for so very long.
https://hhgproject.org/variations.html

Orinoco - - Parent

Fantastic! I'd only heard Metal man before.

Marvin - - Parent

Well of course you'd get enjoyment from those odes to my misery. Why wouldn't you?

Woett - - Parent

Awesome! All cascades or fountains are indeed 1count. The popcornstyle trick 7868686 is a 7count :)

Rob van Heijst - - Parent

Thanks to this guy I only pass balls in 1-count.

Brook Roberts - - Parent

Yay, thanks! Yes, done on one-count.

Will look at this properly/reply to prechac comment later but thanks a lot for implementing this :)

Brook Roberts - - Parent

Although, quick question, if I did 18 throws of 3-count to collect, as did my partner, the default is to count selves (I think), but should I put 18 because I personally did that, of 36 because the two of us did that? (and maybe put a little note somewhere to say that?).

Brook Roberts - - Parent

(I'm assuming the sum, due to the 20 ball passing record being 20 passes).

Orinoco - - Parent

Interesting. I'd put 18, because to take it to an extreme: saying you did 100 catches in a 100 person W feed is a bit misleading in terms of how much actual juggling was done!

However, according to the JISCON rules they count the sum of caught passes between both jugglers ignoring all self throws which I think makes a lot of sense.

I have changed all cascades & fountains to 1 count, the showers to 2 count, siteswaps have been left as is.

Brook Roberts - - Parent

So I totally agree about preferring only to count your own, but I think it's nice for records to be comparable - so I"m mostly asking about your site policy, so that people match :)

And since that was how you imported the existing records (i.e. I assure you 20 ball passing has yet to be qualified!) I've copied it for importing my own records. Personally I'd prefer it to be the way you described - but since one of the main points of the records is to allow comparisons I think it useful for there to be a 'standard' way of recording it on the edge from the start.

Brook Roberts - - Parent

...and think that the edge should make it clear to users the expected way for users to input records.
[also, I assume from your example that I can include patterns with more than two people in the records section ;)]

Orinoco - - Parent

Yep, right we are going with the sum of passes caught between all jugglers as per the JISCON rules. The passing format instructions have been updated accordingly!

I've also just added b2b & sbs modifiers for back to back & side by side patterns respectively.

You can indeed record 3+ person passing patterns by using Préchac notation with lots of | & listing everyone's name after 'with'.

Brook Roberts - - Parent

Great!

"Change the '#' to the number of catches you want to record" - which appears when you are viewing a passing record and considering updating could perhaps be updated similarly.



Orinoco - - Parent

Good idea, done.

Adrian G - - Parent

RE validating prechac through regex...

I don't think that will match sync patterns as you don't have parenthesis in there...

I'd go with something like the following to validate them (disclaimer, I don't completely understand prechac so may be missing something... e.g. I'm not sure how '*' fits into it...):

If we define prechac like the following, which I think is correct (in some horrible combination of ebnf and regex):
prechac ::= '<' ( throws_set ' '? '|' ' '? )* throws_set '>'
throw_set ::= ( throws ' ' )* throws
throws ::= ( '(' throw ',' throw ')' ) | throw
throw ::= digit+ ( '.' digit* )? 'p'?

Putting that back into a regex gives:
throw = \d+(\.\d*)?p?
throws = ((\(\d+(\.\d*)?p?, ?\d+(\.\d*)?p?\))|\d+(\.\d*)?p?)
throw_set = ((((\(\d+(\.\d*)?p?, ?\d+(\.\d*)?p?\))|\d+(\.\d*)?p?) )*((\(\d+(\.\d*)?p?, ?\d+(\.\d*)?p?\))|\d+(\.\d*)?p?))
prechac = <(((((\(\d+(\.\d*)?p?, ?\d+(\.\d*)?p?\))|\d+(\.\d*)?p?) )*((\(\d+(\.\d*)?p?, ?\d+(\.\d*)?p?\))|\d+(\.\d*)?p?)) ?\| ?)*((((\(\d+(\.\d*)?p?, ?\d+(\.\d*)?p?\))|\d+(\.\d*)?p?) )*((\(\d+(\.\d*)?p?, ?\d+(\.\d*)?p?\))|\d+(\.\d*)?p?))>

Well that got bigger quickly...

If you actually want to use that it's probably a good idea to generate it on the fly with something like so that it's easy to modify:
throw = '\d+(\.\d*)?p?'
throws = '((\(' + throw + ',' + throw + '\))|' + throw + ')'
throw_set = '((' + throws + ' )*' + throws + ')'
prechac = '<(' + throw_set + ' ?\| ?)*' + throw_set + '>'

Not sure if that's any help whatsoever based on how long it got, but hopefully it was!

Orinoco - - Parent

The * indicates a hurry eg: Jim's 3 count. & yes I've just noticed the missing 'x' for crossing passes!

I've not come across any Préchac that uses () in the wild, could you give me an example?

Yeah, that sort of unwieldy regex is what I was expecting, but when I meant validation I was thinking more mathematically. For example \w+ will match a vanilla siteswap but it won't validate it. For highlighting siteswaps on the Edge I first do basic pattern matching to find candidates then put them through mathematical validation. In the case of Préchac I'm wondering if mathematical validation might be cleaner than the pattern matching.

I'm not very familiar with Préchac notation either, I've read (well, dived in & out of) Sean Gandini's guide, a lot of stuff on PassingDb & the Passing Wiki, but I've not done much practical work & have yet to come across any articles about validating Préchac notation. Is there a combination of throws that produces an invalid passing pattern, or can I stick in any old number anywhere?

Adrian G - - Parent

OK, I'd never seen hurries put in prechacs, nice to know there's a proper way to do it though.
Wikipedia contains the pattern : <(4xp,2x)|(4xp,2x)> A more obvious example (to me at least) would be 8 club singles 2-count which would be <(4p,4x)|(4p,4x)>

Ah, ok, I completely misinterpreted the 'validation' then. For full validation you will have to do a similar thing to siteswap. In siteswap the most intuitive definition of valid is where each point has the same amount of objects coming into it as going out, this is still true with prechacs.

So what you would need to do is for each throw from each juggler work out which hand/which juggler/what time it lands and make sure that it's valid there. This gets slightly more interesting with over two people as a 3p from one juggler goes to a different person to a 3p from a different juggler, and you need to use 3p2 for changing who it goes to. Because subscripts are annoying, I've often seen things like 3a/3b instead of 3p1/3p2 (though Sean Gandini seems to use subscripts in his guide you linked, so I assume that was the original way)

The final conceptual problem for me is how to tell which hand juggler 2 should start in... I feel like by default both jugglers start right-handed, and this seems to hint that there's no nice way to indicate for one juggler to start left handed (see under 7 club 2-count). I suppose a '*' could be used to indicate a hurry at the start maybe? or is there a standard way of indicating it?

I'll have another look at it tomorrow and try to write a simple validation program in python.

Adrian G - - Parent

OK, so been having a few weird issues with no proper standard as far as I can tell with regards to a few aspects (i.e. JugglingLab, does one thing (note, JL notation link), Sean Gandini's article does another etc.)

I find myself tending to agree more with the interpretation that is not JugglingLab's, but if you're planning on doing the same thing as with standard siteswaps and want to use JL to simulate them then you may want to go with it's syntax...

So, the areas of weirdness:
- in Sean Gandini's writeup, passes are relative, i.e. a p to the next juggler, a p2 passes to two jugglers on, a p3 to three jugglers on etc. in JugglingLab these are absolute and a p1 means to pass to juggler 1, a p2 to juggler 2, etc (just a 'p' still means to pass to the next juggler)
- 'crossingness', in JugglingLab, a 3p goes from right-left, a 3px from right-right,a 4p goes from right-right and a 4px from right-left, so similar to normal siteswap, this leads to weird things like 7 club 2 count being written as < 4xp 3|L3 4xp > instead of < 4p 3|L3 4p > which is what I've normally seen. What https://youtu.be/MTqz58m2hGg?start=11 says is that the 'crossingness' of a pass is determined also by which hand the juggler it is going to started with, this makes 7 club 2-count nicer to write as well as making patterns like 7-club 1 count nicer (<3.5p|3.5p> instead of <3.5p|3.5px>), incidentally JugglingLab doesn't seem to work with decimal passes...
- I have little to go off in terms of offsets in patterns like 7c 1-count, I feel like it can be implicit but I know JoePass requires it to be explicit, so not sure about that... I think certain jugglers starting left handed has to be explicit however, JL does this well with just a L/R in front of any throw.
- Hurries get weird when you try to validate through standard siteswap methods because as far as I can tell hurries don't work if you don't have a dwell ratio of at least 0.5 and standard siteswap is generalised to work with any dwell, I believe JL is also doing something similar to me for validation and I can't manage to get a jims 3-count simulation working (if someone else can, please let me know)


I put what I quickly wrote up in Python up here: https://github.com/AdGold/prechac-validator it doesn't support decimals or hurries at the moment because I don't know how they should act, they would not be too hard to add in though and if someone can clear up for me what they should do then I can do that quickly.

Orinoco - - Parent

Thanks Adrian for all your work on this. I hadn't thought to check how the simulators handle it. Préchac has to date not gained the popularity that regular siteswap has so it looks as if the usage is inconsistent. I will have a better look at your code this evening.

Adrian G - - Parent

No problem, I've been meaning to learn passing siteswap properly for a while so it's good to have some motivation :)

I think Prechac also hasn't quite had the mathematical scrutiny that siteswap has so there are a few things like this which I assume whoever came up with the notation (Jack Boyce according to social siteswaps) would have considered and made logical decisions on it, but haven't mentioned those decisions anywhere so other people have misunderstood/changed it to work better for them.

I still need to check properly how JoePass handles it as I haven't been able to due to not understanding the format properly...

Also, I'll have a go searching for old r.j threads and hope something comes up there too

Adrian G - - Parent

Finally finished exams and had a chance to make it a bit nicer, it now supports the notation to my understanding, i.e.:
* It uses '*' to mean "throw this club a beat early, skipping the dwell time" for hurries, it is also by default a shorthand to throwing again with the same hand, so patterns like this work: <3x 3*> and <(3x*,3x*)! R3* (3x*,3x*)! L3*>.
* Juggler delay is implicit and put in automatically when there is a pattern with decimals such as: <3.5p|3.5p>
* It automatically works out which hand it would make sense for a club to land in so patterns like <4p 3|L3 4p> work (you don't need a 4xp). This gets a bit weird with patterns like Jim's 3-count and I haven't found a nice way to treat that other than ignoring 'x's altogether which I don't think is good (it's like writing R3R3xL3L3x as R3R3L3L3 IMO)
* It follows the standard that is used in JugglingLab, JoePass and in the Social Siteswap DVD and Christophe Prechac's note where a 4xp is a straight pass and a 4p is crossing. So 8o sync 1-count is written as <(4x,4xp)|(4x,4xp)>.

I've made a temporary live version at https://www.jugglesim.com/prechac.html too (a bit slow because there were a few problems with XSS permissions so I had to do it in a roundabout way)

Mike Moore - - Parent

Happy to see my (IMO, best) tutorial here this morning!

I don't know if determining crossingness by ordering of throws was an original idea or not (most of my tutorial was educated by the Gandini's Social Siteswaps DVD). I did want something that was juggler-agnostic, in that it didn't couple a juggler's hands together. I like that idea because it feels more general (I could very easily go to odd-number-handed siteswaps). This may not be as easy to go from siteswap to juggling as some other methods though.

Adrian G - - Parent

Thanks for that tutorial! I really liked the way you related crossingness to which hand was to pass next in the diagram, it helped clarify that concept nicely for me.

I assume you've looked into the implications of it more than me, does it mean that anything with an 'x' becomes a hurry? I'm fairly certain of this but not completely sure

I do like how it means that both jugglers have the same siteswap, I rewatched Social Siteswaps (thanks for reminding me, I'd forgotten about that one) and it seems they do the same thing there, in particular they mention <3 3 3 1p|L3 1p 3 3> (which JugglingLab won't accept unless the 'L' is removed, in which case it makes it a slightly different pattern) and do what JugglingLab calls <3 3 3 1xp|L3 1xp 3 3>.

One odd consequence of this technique that I noticed is when writing down jims 3-count, if you do it based on which hand should throw it next and add an 'x' if it's to the other hand then you end up with <3p 3* 3 3xp 3 3 | 3xp 3 3 3p 3* 3> (notice that both jugglers do an 'xp' for on pass and a standard 'p' for the other) this causes a couple of odd conceptual things because 'x' doesn't even consistently mean straight or crossing for each juggler in one pattern, however it also makes sense in some regard because it is those 'xp's which are what mess with the rhythm. This possibly may also render the '*' unnecessary for clear understanding of the pattern...

I also skimmed the passing section in Ben Beever's book (I haven't had a chance to read that part thoroughly yet) and he writes 7c one count as (where 'x' = crossing pass and 't' = tramline):
J1: {3.5tp, . }
J2: { . ,3.5xp}
Which other than the weird notation, seems to be the same as JugglingLab.

Also, can you elaborate on how to go to odd-handed siteswaps? I'm not entirely sure what you mean, I feel like the passing notation itself doesn't allow for odd numbers of hands as it's of the form < (two hands) | (two hands) ... | (two hands) >

Mike Moore - - Parent

"I assume you've looked into the implications of it more than me, does it mean that anything with an 'x' becomes a hurry? I'm fairly certain of this but not completely sure"

I have a confession to make: I barely ever pass only clubs. >90 % of my passing is with balls or mixed objects, so I'm not familiar with most club passing/traditional terminology beyond the very basics, like "early double". As such, I'm working off of a definition I found online, "A hurry comes about when a club (or ball) is thrown one count sooner than normal," to think about your question.

Reading that definition, I'm still having trouble. What's "normal"? You can pass something like (4x,4xp), and I don't see any hurries in there. Or something like (4,2xp)*, which is a super fun (hard!) pattern where two jugglers share a box.

I can't think of any examples that aren't in synchronous siteswap, though, so maybe asynch siteswaps with xs require hurries.

"Also, can you elaborate on how to go to odd-handed siteswaps?"
I think you caught me sleeping there. I think I was mixing up the old school passing siteswap form that's similar to the one I use in the tutorial, but all the numbers are doubled (which then makes fewer assumptions about the number of hands). It represents the number of beats later a juggler throws a certain prop (I think...this was a while ago) so you often get large numbers. For example, 7 object ultimates would be 7p. Do you know the notation I'm talking about? I think it was used in the passing section in the original Siteswaps DVD. I'm pretty sure it can be used to deal with odd-numbered hands (though I have little experience with that).

Orinoco - - Parent

I've never heard that definition of a hurry before.

I think the more common hurry is when a pass is thrown that upsets the normal throwing sequence. For example: two jugglers are passing 6 clubs 4-count with right handed tramline passes, each is throwing left right left right... If one juggler passes a crossing single the receiver is forced to make 2 right hand throws one after the other, first the pass then a self to empty the hand to receive the incoming crossing pass. That's a hurry.

Mike Moore - - Parent

The earlier definition came from: https://www.passingdb.com/download.php?section=articles#articles5

Now that you mention it, the definition you gave sounds familiar. Would you say a hurry is one that forces your partner to "throw" a 2?

In that case, it's definitely not true that xs always result in hurries. However, I think that taking an x out where it was before, or putting one in where it wasn't would result in a hurry.

Brook Roberts - - Parent

That sounds sort of right, and a way of thinking about it that I hadn't before. Certainly you can view all juggling as a slow cascade i.e. (4x, 2)* for just doing three clubs. That way on each beat either hand can throw, we normally alternate, but you don't when you hurry. This is one reason for this sort of pattern why people often juggle a bit slower!

However, interestingly, for a lot of standard patterns with hurries, rather than doing 4ps you can collapse the throws down to 3.5ps. So Jim's two count under the above interpretation is (4p, 2)(2, 4x)(4p, 2)(4x,2) for one of the passers, with the hurry on the last 'pair' of beats. But if you float your passes slightly, you can juggle at a normal speed and instead juggle the global siteswap 77466, (in local prechac 3.5p, 3, 3.5p, 2, 3). This has a very different feel (and you can of course add in flips on the 2s to prove you really now have a period 5 pattern). In this case you no longer 'forced to throw a 2', but on the other hand, they don't feel like hurries either!

Orinoco's definition of hurry sounds close to standard.

Brook

If anyone fancies trying something hard with hurries, firstly try 7 club 2 count Jim's (doubles better), which is easy. Then try Oddz Godz (see e.g. Aidan's book) for a pattern where every self is a hurry (but still 2-count)!

Brook Roberts - - Parent

P.S. I've never seen a notation that explicitly allows for hurries apart from either: having a hold in the other hand, or better, relabeling hands in a causal diagram. The idea of using a * is neat (although * is a bit overloaded, I think you could always tell them apart in practice). I might use it!

Adrian G - - Parent

As I mentioned in my reply to Mike's post, I feel like the 'throw a 2' method doesn't quite hold up when you get patterns like 4x* (which he describes in more detail here). I do however think if you really want to be specific, you are right about just writing it using sync notation as then the hold times are explicit and you don't need to worry about screwing with siteswap in order for it to make sense.

I haven't seen the 'unhurrying' of jims patterns before, I will have to try that out next time I'm doing some club passing, it's a neat idea.

I'm with you about the '*' notation too, I hadn't heard of it until Orinoco mentioned it. I'm fairly sure you're right about being able to tell them apart unambiguously in all cases too. As far as I know a '*' for repeat on the other side only can occur after the ')' of a sync pattern, whereas for a hurry it must be after a throw, so as weird as it looks, (3x*,3x*)(3*,-)* makes sense for a height 3 version of columns. Incidentally however, Christophe Prechac uses '%' to designate repeat on the other side in his notes in order to avoid confusion which I like (even though '*' is standard now and there's not way that's going to change)

Adrian G - - Parent

So I've done a lot of looking through old r.j posts over the last couple of days (I can link the relevant for anyone interested). However, I also found a link to Christophe Prechac's descriptions (part 1, part 2 of passing notation, which it turns out is also in the page you linked above...

After reading through that I have to agree with your earlier (and Christophe Prechac's) definition of a hurry, as an object that is thrown one beat earlier than usual, skipping the dwell time (the 'normal' you asked about means 'after a standard dwell time'). This definition makes more sense to me as from a siteswap perspective, hurries are actually invalid, consider the following:

Take the pattern 3x3* this is a standard hurry pattern, where you cause your own hurries by throwing a 3x instead of a 3, this is kind of like 423 but throwing the 4 at the same height as the 3. Writing it out in full (I'm omitting the standard '!' to designate no extra beat after sync for readability) you get (3x,-)(3,-)(-,3x)(-,3) which will fail if you try to validate it, you can see this in the quick ladder diagram I made badly here (the left one). The right hand diagram shows what happens if you have every throw landing one beat early (i.e. assuming a dwell ratio of 0.5) here by skipping this dwell ratio you can get a valid pattern, note that implicitly the other hand also has a '1x' added. This is the same kind of thing as your "forced to throw a 2".

Using this definition, you can more easily validate a pattern with a hurry, though I haven't worked out the full details, Christophe mentions added a '-1x' the beat after a hurry from the same hand which helps to an extent, but not completely, as there is also the implicit 1x to worry about.

There are also cases, however that an implicit 1x is not added, for example the pattern 4x* which is a fast 3 ball cascade, here with the pattern (4x,-)(-,4x) the other hand will always be empty so there is no need to add a 1x, simply adding the -1x to give (4x,-1x)(-1x,4x) allows the pattern to be validated (who said negative siteswaps weren't useful??)

I've been playing around with a couple of rules to work in the general case and if I get something nice that's consistent then I'll post it.

So after reading through all those posts/articles, yeah I completely agree with you that my earlier statement was completely wrong (even though in my head I was only talking about passes, it still doesn't work), I think I also agree with your "taking an x out where it was before, or putting one in where it wasn't would result in a hurry" but feel like it relies a bit too much on the properties of the original pattern and the transformation to be able to make sense to me...

Also, RE odd-handed siteswaps I think you're thinking of multi-handed notation (MHN) in which you would write 7c ultimates as simple 7 (the 'p' is unnecessary as you can work out which hand an object goes to purely based off the number). And I believe you're right in that it can be used for odd numbers of hands but I've never actually done that.

Adrian G - - Parent

err 'part 2' link should be: https://www.passingdb.com/articles.php?id=16

Mike Moore - - Parent

"This definition makes more sense to me as from a siteswap perspective, hurries are actually invalid"

Couldn't this be made valid by increasing the throw rate and inserting a bunch of twos? Similarly to how you can call a 3o cascade (4x,2)*?

"Also, RE odd-handed siteswaps I think you're thinking of multi-handed notation (MHN) in which you would write 7c ultimates as simple 7 (the 'p' is unnecessary as you can work out which hand an object goes to purely based off the number)."

Yes! That's the one. I didn't know that you could figure out which hand an object went to by the value: can MHN discern a 7 (thrown a pass to my partner, then returned) from a 7 thrown as a standard self* throw?

*self here meaning thrown to myself, but changing hands

Mike Moore - - Parent

""This definition makes more sense to me as from a siteswap perspective, hurries are actually invalid"

Couldn't this be made valid by increasing the throw rate and inserting a bunch of twos? Similarly to how you can call a 3o cascade (4x,2)*?"

Oops, you wrote about that in another post, please ignore this bit.

^Tom_ - - Parent

MHN (or as I will choose to call it now, 4-handed siteswap (4hss) [though obviously the concept can be extended to more or fewer hands]), is simply a siteswap where the hands are L l R r L l R r rather than L R L R (where L and R are the left and right hands of juggler A, and l and r are the left and right hands of juggler b).

beat hand
0 L
1 l
2 R
3 r
4 L
5 l
6 R
7 r

A few observations:
- If we take any even throw, we see that it returns to the same juggler (imagine looking from the side and thinking of the 2 jugglers as being 2 different hands (evens don't cross))
Furthermore, any number divisible by 4 returns to the same hand. (T%4=0 -- same hand, T%4=2 -- other hand same juggler)
so 2hss:2 = 4hss:4 (= nhss:n)
So for any even throw, if we take the number that is half of the number that we read, then that's the "regular" siteswap number for that throw.
(eg, a = crossing double or triple, same throw as a 5 club cascade)

- If we take juggler A, any throw T where T%4 = 1 (1,5,9,...) is L-l or R-r, which is to say that it crosses
for the same juggler, T%4 = 3 (3,7,11,...) is L-r or R-l, is a straight throw
If we take juggler b, we see that this relationship has switched.
In the application where we see this most commonly (club passing), one juggler has crossing 7s and straight 5s/9s, and the other has straight 7s and crossing 5s/9s.

- Furthermore, it may or may not be apparent that all of the vanilla siteswap rules that we know and love still apply (e.g. validation, states, replacements), because the mathematical rules of vanilla siteswap are agnostic to the number of hands, only to the order of the throws.

- So yes, the 4hss value tells you what you need to know about the hands, and I believe that everything different is discerned.
a standard 7 throw as you mean would be a siteswap e in 4hss.

- A common complaint about 4hss is that the numbers are in the wrong order. Let me point out the following observation. When juggling the regular 2hss patterns 423, ask each hand what they throw. Assuming you start with the right hand, the right hand will say 432, the left hand will say 243. So should we write the siteswap as 243? No, because for the purposes of the entire pattern, information about the hands independently is incomplete (if you want to validate the pattern, you need to know what both hands are doing [just because 42 and 33 and valid, doesn't mean that your left hand can do 42 while you right hand does 33]).
It should be fairly easy to see that the same thing is going on with a 4 handed siteswap. Remember the analogy of juggler A being one hand and juggler b being the other hand.
So a 4hss of 9667867
A: 96678679667867
b: 96678679667867
So the starting juggler will throw a so called "local" siteswap of 9 6 8 7 6 7 6
or doublep self heff singlep self singlep self
and the other starts half way through the pattern with
self singlep self doublep self heff singlep

It therefore follows that if the period of the pattern is even, then the 2 jugglers will not do the same thing*, a hybrid of the 6 club patterns 972 and 978 is 972978, where one throws their part of the pattern 972 and the other throws their part of the pattern 978.
(*just like the analogy of the 2 hands, even period = 2 hands doing different things)

- To convert from 4hss to the alternative "prechac" notation, first turn a "global" 4hss into a local siteswap by reading first all the odd throws and then all of the even throws (if period is odd). then divide all numbers by 2, adding "p" to any non-integer number.
e.g. from 9667867 to 9687676 to 4.5p 3 4 3.5p 3 3.5p 3

nvFAQ:
- Do you have a preference?
Yes, I prefer 4hss.

- Do both make sense in certain circumstances?
Yes. One of the elegant things about 4hss is that it deals with the whole pattern*, rather than worrying about how 2 jugglers fit together.
On the other hand, if you want to make some stealing patterns which relate closely to solo juggling, and/or have a variable number of jugglers involved in the pattern, then there is no continuous "whole" pattern, but what is continuous is what a single juggler is doing, so that should maybe be the base notation.
(* replacing 2 consecutive 4hss throws of 7 with an 86 (a heff for one juggler followed by a self for the other) is fairly obvious with 4hss, but less obvious in "prechac" notation)

- Why do you call the other notation "prechac" with quotation marks?
Because I don't think that's the right name for it, and in some old posts, people seemed to rightfully object to the name. I think the notation (with or without angle brackets and pipes) was created by Jack Boyce, but Prechac made the transformation which is named after him. This says that you can add or subtract half of the period from any throw and turn it into a pass. This seems to now be fairly deeply intertwined with the notation for some of those who use it, such that the notation appears to have gained his name too.
The transformation can of course be done in 4hss, particularly easy if the period is odd. First convert a solo pattern into 4hss (45141 to 88a22), then add or subtract the period from any throw (period is 5, so adding or subtracting 5 from any of the numbers creates an odd number (pass)).
*Apologies for the missing accent.


If you've made it this far, then apologies for this being a rather unorganized post, it's one of my goals to present this information in a clearer way, but I'm still thinking about that.

^Tom_ - - Parent

Of course convention would probably dictate that I started with Rr rather than Ll, but that looked like too much effort to go through the post and fix anything that needed fixing. It makes no difference, but it allows you to start the pattern with both throwing with their right hands. By choosing to start with both throwing from their right, we fix that the person who starts is the one with straight 7s and crossing 5s/9s.

Adrian G - - Parent

Thanks for the nice writeup on 4hss (also, I like that name better than MHN as MHN is very general and can refer to lots of things), I'm nowhere near as familiar with it as I am with standard siteswap and find it nice to keep reading explanations on it.

My main problem with 4hss is that (AFAIK) it can't represent any pattern, in fact it can only represent very specific patterns where no two jugglers throw at the same time, to 7c ultimate and 7c 3 count are heaps nicer than the alternative (7 vs <3.5p|3.5p> and 966 vs <4.5p 3 3|3 4.5p 3>) but it fails when it comes to notating something like 7c 2 count or 4 count (<4p 3|L3 4p> and <5p 3 3 3|3 3 5p 3>) or even more so patterns like 8c 2 count singles (sync) which is <(4px,4x)|(4px,4x)>. If there is a way to notate those patterns using 4hss then please let me know, it would be really useful!

My other problem is that I have more trouble working out what is happening from a pattern (I have to mentally halve all the numbers and double check if it was given to me in local or global form)

That said, its simplicity is amazing (I spent a tiny fraction of the time checking the 4hss patterns there vs the others), so I think it's useful for those patterns but (for me at least) not so much in general.

I completely agree about calling the it prechac notation, prechac does mean a bunch of different things, from the prechac transform to the patterns that you can get through the transform ('prechacs') and sometimes even just for patterns where you are standing side by side (though the last one is probably slightly incorrect). However calling it 'passing notation' is also confusing to some as that could also mean 4hss/MHN. Calling it 'prechac notation' is at least unambiguous from the 'prechac transform' etc. Maybe to reflect that it was Jack Boyce who created it (I'm fairly sure you're right there based on what I read in the old r.j posts) maybe we should call it 'Boyce notation' or 'Boyce passing notation' :P

I'm slightly confused about your conversion from ss -> 4hss, you seem to be taking every 2nd number going backwards and doubling in 45141 to get 88a22, however when I try 312 I get 624 instead of 642, what am I doing wrong here? I think I've misunderstood how to convert between ss and 4hss...

Also, do you mind explaining how the prechac transform works on even length siteswaps? I don't see how you end up with the information that a certain throw has to be a pass because subtracting the period (even) from a siteswap of purely even numbers (as they all have to be doubled to convert to 4hss) will never result in an odd number. Have I misunderstood something there?

^Tom_ - - Parent

Vanilla 4hss notation is exactly as limited to representing only patterns where no 2 hands throw at the same time as regular siteswap notation is.
However, now that we have 4 hands rather than 2, there are more than the previous 2 options (async/sync).
Now we have at least (async async/antisync async/async sync/sync async/sync sync), and maybe even more, but I'm going to leave it at those.
(As an aside, I'd like to mention that in my opinion, 2hss sync notation is probably wrong, either all of the numbers should be halved, or (0,0)s should be present (I can think of interpretations where it's right, but they're fairly illogical)

Let me start by dealing with the ones which are probably the most common problems, either sync- or antisync- async (even or odd numbers of clubs on 2 count respectively).
One solution is to adopt a sync2hss-style approach, which Aidan's book, "The Highgate Collection" makes use of, this makes 7club 2count something like (8x,6)*.
I don't know if everyone uses an x here or if some use a p.
This problem meets complications when combining it with sync sync patterns, although it should still work, conventions of notation are then going to be more important to distinguish between a self cross, a straight pass, and a crossing pass - I think the most logical is (x, p, & xp) or (x, xp, p) or (a context dependent combination of both).

An alternative, which was presented as an article on the ija ezine some time ago is to move the beats slightly until they deviate from the assumption of equispaced to approach the limit of being synched.
Then we see that for one juggler, a 7 pass takes the same time, and has the same crossingness as a 5 for the other juggler, and we can now write sync siteswaps in the vanilla async framework (* links and diagrams can be provided here if you're interested). Giving something like 7 club 2 count a notation of 9667.
The same method can be used to fix notation for sync patterns. If course trying to apply both of these at the same time to notate a sync sync pattern is going to get messy quickly, but it is at least possible.

^Tom_ - - Parent

For the alternative, take a look at the bottom sections of http://ezine.juggle.org/2012/05/09/period-5-patterns-four-handed-siteswaps/

^Tom_ - - Parent

Let me now address the conversion from ss to 4hss:
example ss: 12345
step 1, double every throw
2 4 6 8 a
step 2, reorder the throws.
As we know that each juggler throws every other throw, so if we want each juggler to throw 2 4 6 8 a in that order; then reading the first 3 odd numbers must give us 2.4.6 and with a period 5 pattern, the 4th odd number is the same as the first even number (4*2-1)%5=(1*2).
so we can now fill in the spaces with the 4th and 5th local throws, which take the 2nd and 4th global positions. 284a6.

^Tom_ - - Parent

Prechac transform on even length siteswaps:
Here we have the problem that the time offset between the 2 jugglers is always half of the period. So if we have an even length siteswap, then the offset is a full integer. If the offset is a full integer, then we are no longer "async async", so our 4hss is no longer vanilla.

So can we go from ss 33 to 7club 2-count (antisync async)?:
I suppose so, but I'm not quite sure how systematically this can be done. 3 3 to local 6 6 to local 6+P 6 = 8 6 to global (8x,6)(6,8x)

In practice, it probably makes most sense to use the notation which corresponds to the symmetry of the pattern, so for patterns with 2 or 4 hands throwing simultaneously, I often write it in Boyce notation unless it includes a transition to/from async async.

Adrian G - - Parent

Thanks I think I understand most of that...

I agree that sync is inconsistent, but it's also so much easier to teach I think, trying to explain why 4b fountain is 4 but sync 4b fountain is (2,2) would be hard... And always adding an extra beat would just get annoying... So even though I agree it doesn't make sense, I still kind of prefer it this way

Hmm, so I assume with (8x,6)* that's (R,l)(r,L)? (capitals = J1, lower = J2), I suppose that works, I haven't seen it written quite like that before. I think it may get weird once it gets to sync/sync though with something like (8x,8xp,8x,8xp) of similar because all throws are throwing at the same time, is there a neat way to do that that you've seen?

RE using x/p/xp etc. options, I feel like that's going straight into the whole crossing vs straight in Boyce notation that we've been discussing in other parts of this thread...

I can see the logic behind trying to write everything in vanilla ss however I personally don't like it as an alternative as now given a siteswap, not only do you need to know how many hands, but also the hand throwing order/rhythm. While it may be more 'pure' in some sense I feel it's a lot less practical. (also I really hate that different throws from each juggler are the same)

Conversion makes sense now, thanks for that!

Ahh, I didn't realise the doing the Prechac transform on an even length would cause it to be not vanilla.
"I'm not quite sure how systematically this can be done"
I think what you have works systematically as an algorithm for the transform:
- Take a ss, e.g. 3 3 (local)
- Double it, e.g. 6 6 (local)
- Add period and add an 'x' to an throws you add it to, e.g. 8x 6 (local)
- Reorder throws for global siteswap, notation assumes (R,l)(r,L) etc.
- so you get (8x,l)(r,6), to put the other jugglers throws in you need to put the last half at the front as prechacs are staggered symmetric patterns, so J2 has 6 8x (local)
- Final global siteswap is (8x,6)(6,8x)

I think those steps should work in general for even length patterns...

"so for patterns with 2 or 4 hands throwing simultaneously, I often write it in Boyce notation unless it includes a transition to/from async async."
I have to agree with you there, I still haven't made up my mind as to which notation I prefer for patterns that can be written in vanilla 4hss, because while it is a lot nicer to write them in 4hss, if it's only one case of patterns I feel like I might as well write them in Boyce notation too to be consistent.

Though honestly at least 80% of the time I learn passing patterns I learn them from a causal or from an english description (crossing pass, straight double pass, self)...

Adrian G - - Parent

On the topic of writing hurry patterns differently, the reason that it works in sync is to do with the explicit dwell time in (4x,2)* this is also beatmap's approach to this as with how it uses (1,2x)* to notate 3 ball cascade. The use of explicit dwell time (i.e. inserting a bunch of twos) in these notations, as you said, makes it valid, however the conversion there is somewhat weird in cases and (in terms of validating patterns which is where this whole convo started).

I think Tom explained how a 7 has to be a pass better than I could so I'll leave that part there...

Also, I have a couple of other questions about the crossingness of passes if you have a moment too, I went through a bunch of r.j posts on this part too (this one was quite interesting even if it got a bit off topic), and it seems that apart from the simulators, most people agree on determining whether it crosses in the same way as your tutorial, however they still write Jim's 3 count as <3p 3* 3 3p 3 3|3xp 3 3 3xp 3* 3> which confuses me somewhat.

The above writing of the pattern implies that the direction is based purely on the starting hands of the jugglers and not what they currently are throwing with, while this does make it at least consistent through the pattern, it (IMO) also becomes just as arbitrary as writing xp for all crossing and p for all straight and does't have the niceness of the original method... Using which hand each juggler is currently throwing with makes Jim's three count <3p 3* 3 3xp 3 3 | 3xp 3 3 3p 3* 3> (i.e. J1's first pass is straight and J2 is also passing with RH therefore no x, however for the second pass, they are passing with opposite hands so it needs a px to go straight...

So my question is, am I missing something in this method that makes Jim's 3 count work with one person only having xp and the other only having p? or is it only based off the start? or have most people just not looked into it like this and as such it's just an annoying inconsistency?

Also, it seems that when moving to sync patterns there is still the problem of which hand it goes to and that can only be determined by the use of a specific x to mean "go to other hand" for even and "go to same hand" for odd, such as with the pattern <(4x,4xp)|(4x,4xp)>

Incidentally, that same thread I linked also discusses the whole relative vs absolute passes I mentioned, and one notation suggested there is using 'r' instead of 'p' for a relative pass, but that of course suddenly adds another thing to the notation...

Adrian G - - Parent

Err, and apparently I'm really bad at copy-pasting links, that should be: https://groups.google.com/forum/#!searchin/rec.juggling/prechac/rec.juggling/6BH4fqbWV9c/zB4D425T85gJ

Mike Moore - - Parent

Sorry for the slow reply, this conversation escalated quickly and I had to be in a proper mindset to follow it! I'll start from the bottom, because that's the topic I'm most comfortable with.

Also, it seems that when moving to sync patterns there is still the problem of which hand it goes to and that can only be determined by the use of a specific x to mean "go to other hand" for even and "go to same hand" for odd, such as with the pattern

The inclusion of the x in 4xp may not be necessary in this pattern, but I think it makes sense because most people consider an 4p to cross. I felt that treating [even number]p s as crossing throws be default in synchronous passing sitewap made the most sense.

"most people agree on determining whether it crosses in the same way as your tutorial"

I am a little surprised, and happy to hear that! I don't think I'd come across that idea before, but it seemed like the only way to handle that complication, so I went with it.

"So my question is, am I missing something in this method that makes Jim's 3 count work with one person only having xp and the other only having p?"

Isn't that how Jim's 3 count works? One person always throwing crosses, the other always throwing straights? (I read about it from here: https://www.gnerds.com/juggle/view_pattern.php?patternid=3)

Brook Roberts - - Parent

That is how Jim's 3 count usually works.

Do most people consider a 4p to cross? Are you saying that you would notate 8 club 2 count on singles as ? Because that's definitely not how I would do it normally...

I see where you are coming from in 4p by default being straight, because in typical async patterns that is the case. But I don't think it is normal usage, and I think sticking with x for 'cross' makes sense from a reading point of view!

Mike Moore - - Parent

I see where you are coming from in 4p by default being straight, because in typical async patterns that is the case. But I don't think it is normal usage, and I think sticking with x for 'cross' makes sense from a reading point of view!

Do you mean a 4p by default being a cross? In typical async patterns, I think that's usually the case (e.g. 4p23 for early doubles).

I'm not using x to mean cross, I'm using it to mean "do the opposite of the usual in terms of crossing/non-crossing". This is the same usage it gets in lonely-juggling synchronous siteswap (though you only see [odd number]xs in transitions).

Brook Roberts - - Parent

Yes, I meannt 4p being by default a cross - was a typo.
Yes I know you're not using x to mean cross - I'm suggesting that common usage (at least around my parts) is to use it to mean cross, and I think it is more intuitive in general.
I realise it's not consistent with what is used in transitions (I use x to mean opposite of normal in transitions too) but I think case isn't a great precedent since the notation for transitions is a bit of a fudge anyway.

Adrian G - - Parent

So, the way I see it, the problem with using 'x' to mean cross is that siteswap should not (and does not) give you hand directions, imagine we're passing 6c 2 count, so 3p 3, now I turn and start doing dropbacks, if we keep the same 'p is straight' then suddenly the pattern that we're juggling changes (passes are going right-right and left-left instead of left-right and right-left.

So 3p 3 can now denote two different patterns. But OK, maybe 'x'=cross wasn't right, what about 'x'=right-right/left-left instead? This is essentially what JugglingLab does, except that a default even throw is right-right/left-left in the same way as solo juggling, so the x just swaps it, which makes more sense seeing as you still can have solo throws.

But then that gives other weird issues like 7c 2 count is 4px 3 etc. which the whole basing it off which hands a throwing makes nicer as simply 4p 3.

That was sort of a random mush of thoughts so hopefully makes sense...

Brook Roberts - - Parent

Yeah, x=right/right is what I would actually have it as.

Adrian G - - Parent

Yeah, ok, I still don't think I like the idea that the throw direction is defined based on how a small case of passing works (two jugglers passing face to face), IMO the rational behind a notation shouldn't rely on certain juggler positions.

I think my other reply to you a few posts down the other day explained stuff better than that one after rereading them, it was just before I left to go to my exam so I was a bit rushed ;)

But the gist of it is I feel like it removes any connection to normal siteswap for no good reason...

Brook Roberts - - Parent

It's certainly not a small case of how my passing works! Which probably explains some of the bias.

Passing tends to have a large number of notations in use, more than I ever use in solo (prechac, multihanded notation, causal diagrams, Aidan notation, brolly notation etc) so I think there is a bit of a break in my mind in really gearing it towards (my) passing use.

Adrian G - - Parent

Fair enough ;) It's definitely the majority of my passing as well, but a small case of overall passing (consider all the side by side patterns, over 2 person patterns where crossing isn't as clear normally, etc.) and IMO a notation should be catering for the general case in that regard rather than based on a certain use.

Even if it isn't as easy to see what's crossing and straight, it isn't too bad and I think the trade off with consistencies with solo siteswap and a notation that preserves the same nice things between async and sync vs. it being slightly easier to tell which passes are straight/crossing in certain patterns, for me the former definitely wins out.

^Tom_ - - Parent

So you're suggesting that in what I call "sync async" patterns (both jugglers throw their right hand throws at the same time), Op is straight, Ep is crossing (O=odd,E=even).
But in "antisync async" (one throws with their right at the same time as the other throws with their left), e.g. 7club 2count, Ep is straight, Op is crossing?

Logically that makes sense, because then the crossingness simply corresponds to the hand that the partner is throwing with at the arrival time. In other words, there is no choice.

On the other hand, in "sync sync" or "async sync" patterns, this obviousness no longer applies, as the partner has 2 hands which throw at the same time. In this case the choice is now somewhat more arbitrary.
If we take the example of 2 people juggling 4 clubs each in sync sync ((4,4),(4,4)) if you will. Obviously a 4 is straight, so there's an argument for a straight 4p (plus there are probably more patterns with straight 4p passes than crossing 4p passes). However, if you want to be able to interchange self throws and passes (8 club synchronous 3 count springs to mind), then the passes have to land in the hand from which the partner threw their pass, which makes them crossing.

In the category of antisync sync, we have patterns like techno, where I guess the passes are 4p, and yet one juggler passes crossing and the other straight.

Brook Roberts - - Parent

I think Tom's example of 7 club 2 count is a good one. Any notation ideally strikes a balance between intuitive and consistent, so that it has nice features and works well for those who understand it fully, but also where possible agrees with the naive understanding, so that people don't have to get bogged down in discussions like this just to use it (since funny, some of my friends aren't as keen on talking about numbers for hours as me and just want to juggle!).

I suspect any such user will describe 7 club 2-count as 4p 3, and I think any good notation would need to have a good reason to differ from the comparable precedent. (i.e. we need a good reason to tell people actually it makes more sense to describe this as 4px 3 locally). I think instead it seems more obvious to not use the x at all when 4p fully describes it's target (i.e. when the received of your pass is juggling async) and only use x's when they are required.

And if so, I would then say that if you are only applying x's to patterns where a 4p and a 4px could exist, it makes sense then to make the choice of x's meaning straight. Note straight 4ps are used far more often than 5xs in transitions.

P.S. Not sure what you mean by antisync sync (the same as async sync?) but in techno both jugglers use all 4 hands at the same time if you think of it as a sync pattern, so it is sync sync {(4x, 4p)(2,4x)*|(4x,2)(4x, 4px)*} If you just mean one does crossing one does straight I'm not sure that is a useful category since you can obviously have patterns where both people do straight and crossing e.g the symmetric pattern (4x, 4p)(4px,4).

Some people think of techno as 7 club 3-count on singles, in which case you can avoid all this anyway ;)

Obviously in the above I used 4p to mean straight!

^Tom_ - - Parent

I'm not sure as to whether the group antisync sync exists or not, at the most, it's a subset of sync sync, but I wanted to make a distinction as the juggler who's passing switches with each beat.
Obviously techno (even the sync version, which I've been told is the only true way) is siteswap 966 in the limit of synchronizing the beats (just as the box is 960).
My definition of antisync is most clear with the difference between sync async (6 club {1,1.5,1.67,2,3,4,6} count, 8 club 2 count (async), etc) and antisync sync (7club 2 count).

"I would then say that if you are only applying x's to patterns where a 4p and a 4px could exist, it makes sense then to make the choice of x's meaning straight."
Is that what you mean, that 4px should be straight? I presented an argument for both sides above, though I'm not certain which I think would be more obvious.

Brook Roberts - - Parent

I am doing a good job in this thread of stating the opposite of what I mean.

I am strongly in favour of 4p meaning straight!

Adrian G - - Parent

I'm not entirely sure what I think of not including 'x's at all when it doesn't need them, on the one hand, yes it's great (like in solo siteswap) where unnecessary information isn't included, on the other hand, when it's causing a hurry or being different from normal in some way, it still feels a bit weird to call it just a '3p' (but maybe that's just what I'm used to).

"I am strongly in favour of 4p meaning straight!"

So onto sync, it's really only a question of even passes, I think odd passes automatically go right-left (straight) by default. The problem as I mentioned above with something 'meaning straight' is that what happens if one juggler is turned around? So I'll assume you mean right-left instead of straight. To me this is like saying that a 4 should cross by default...
However, take this example, suppose you have two jugglers simply juggling four clubs: <(4,4)|(4,4)> now they start to pass:
If you have a solo juggler switching from (4,4) to (4x,4x) then it's obvious that the 'x's "cancel out" in a sense. Now take <(4p,4x)|(4p,4x)> (using 4p = R-L) vs <(4px,4x)|(4px,4x)> (using 4 = R-R), in the second you have the same fact in that the 'x's still cancel out and it is obvious what is happening in the throws. Additionally, in the same way that <3 3|3 3> can turn into <3p 3|3p 3> and <4 4|4 4> can become <4p 4|4p 4> when both jugglers pass with the same hand, <(4,4)|(4,4)> can become <(4p,4)|(4p,4)> when both jugglers pass with the same hand, rather than <(4px,4)|(4px,4)>

One final argument (if you're not sick of reading this post already :P ), is that jugglers facing each other is (IMO) kind of weird, one jugglers right hand is on the same side as the other jugglers left hand. Having a 4p, if you imagine the other passer standing in front of you, facing away, should go straight from your right hand to their right hand in the same way that a 4 goes from your right hand to your right hand, turn them around and you get a 4p, still going from right-right, is now crossing.

That was all written quite quickly, with all my other recent posts here as I haven't checked this thread properly in a couple of days and need to head out soon...

Mike Moore - - Parent

"I think instead it seems more obvious to not use the x at all when 4p fully describes it's target"

Being pedantic, couldn't you do a 7o 2count with all passes as crosses? (Actually, I'll have to try this out...I tend to juggle left handed, and my partner is strongly right handed).

I do now agree about typical passes being thrown as straights, regardless of whether they're even or odd. I think I was extrapolating from too small an example base.

Using xs to mark crosses instead of using it the way that's consistent with solo siteswap seems like an effective way of handling things. But it feels so wrong to me!

Adrian G - - Parent

Yes, you can do 7o 2 count all crosses, however both jugglers would start right handed so you would get the following pattern: <4p 3|3 4p> instead of <4p 3|L3 4p> (so in the seconds, 'L' means J2 starts left handed, which through your rule for what crosses, makes the passes straight instead of crossing). And yes, if both jugglers are only throwing one club at a time, it is very easy to see which hand the club has to be thrown to (because that hand will be throwing that club again on the beat after it lands) so yes, any pattern where only one hand per person throws at once can be unambiguosly written without any 'x's (so from the point of interpreting it, you can completely remove 'x's if you really want). Sync still needs them of course, however.

I still agree with your original reasoning to say evens are right-right by default (I think cross/straight are bad terms for this as I briefly mentioned in another post about where one person turns around), as was mentioned earlier if you want to do 8c 3 count <4p 4 4|4p 4 4> seems the most logical to me.

"Using xs to mark crosses instead of using it the way that's consistent with solo siteswap seems like an effective way of handling things. But it feels so wrong to me!"

I agree that it feels wrong, which is why I think it shouldn't mean that ;)

Mike Moore - - Parent

"Yes, you can do 7o 2 count all crosses, however both jugglers would start right handed so you would get the following pattern[...]"

Ah, good point. I suppose the crunched down 4p3 siteswap leaves ambiguity in that form.

"I agree that it feels wrong, which is why I think it shouldn't mean that ;)"

I was using "crossing" to mean a right/left or left/pass for brevity (laziness?), so I think we were on the same page. Using an x to mean right/right or left/left still feels wrong! My juggling focus is synchronous (solo) patterns, and while I rarely actually work out sync/async transitions in siteswap, I do have [odd number]xs pretty internalized. I'll have to compartmentalize those parts of my soul.

^Tom_ - - Parent

If you were using the term "crossing" to mean right to left, then I suspect there's been a lot of talking at cross purposes (or should that be straight purposes).

In this thread I've always used the term crossing to mean right to right, and I'm 99.99% sure that Brook has been too.

Mike Moore - - Parent

Oops, the whole "saying opposite of what you mean" must be contagious. I meant crossing as right/right or left/left, and straights as right/left and left/right.

Adrian G - - Parent

Ah, I must have misinterpreted your post, specifically "I do now agree about typical passes being thrown as straights, regardless of whether they're even or odd. I think I was extrapolating from too small an example base." as I think a 4p should cross by default...

I've done some more reading through passingdb/the passingdb articles you linked/old r.j posts and can't find anyone writing sync patterns like that (though admittedly sync passing patterns with even passes aren't that common and I only found around 10 references total). However all the articles I've read through (incl Christophe Prechac's ones and the Social Siteswaps DVD) as well as both JugglingLab and JoePass seem to use <(4xp,4x)|(4xp,4x)> instead of <(4p,4x)|(4p,4x)>

I also think this makes far more sense as it's how solo siteswap works, IMO a 4xp should be considered a 4x that is passed instead of a 4 that is passed (in some direction), the first has a logical sense to it the second is completely arbitrary. Yes, defining it as 'crossing' (R-R) for when jugglers are facing each other may not seem arbitrary, but juggler direction still is and suddenly when they turn around then 'x' means straight. To me it makes more sense to have the rational for the definition of it independent of juggler positions.

Adrian G - - Parent

I don't think I explained what I meant with jim's 3 count very well...

In Jim's 3 count, the first pass, both jugglers are passing with their right hands:
J1: right->left (straight), as it's "sync async", it's a 3p
J2: right->right (crossing), as it's "sync async", it's a 3px
Cool, now pass number 2, remembering that J1 has had a hurry so now J1 is passing from their right hand and J2 from their left.
J1: right->left (straight), as it's "antisync async", it's a 3px?
J2: left->left (crossing), as it's "antisync async", it's a 3p?
So, using the method of which hand is throwing at that time causes J1 to throw a 3p then a 3px (which are both straight) and J2 to throw a 3px then a 3p (which are both crossing), this seems a bit weird and not what others that use that same notation method write it as so I think I'm missing something...

david - - Parent

I have been working on what I thought was 423 with singles for the 4. It sounds like that is what you are describing here and it does feel like I'm hurrying. We had a discussion about it in our group and decided it was a 423, not knowing anything about hurry notation. We thought siteswap notation doesn't specify the height or flight time, so calling this a 423 is good siteswap. Asking naively, why call it something else? Or, more generally, is the whole hurry notation not necessary? Can it all be done with siteswap and a note that says singles etc. similar to the notes that say under-the-leg etc?

Adrian G - - Parent

honestly, in terms of describing it to another juggler, the easiest way is to simply say 423 with the 4 as a single because it's concise and doesn't rely on them knowing anything extra about siteswap (and even a lot of people who don't know siteswap know what 423 is).

However, what you said about siteswap is not 100% correct, while siteswap doesn't care about the height, it does care about the relative heights of throws, so a 4 must be higher than a 3[1], so technically if you throw them at the same height it is not 423 (though arguably it's still better to call it that)

However, you don't have to go to hurries to be able to describe it correctly, simply by using sync notation, you can get (4,2)(4x,2)* which is a completely reasonable (and I think completely isomorphic) notation for it.

Of course, hurry notation can be a lot simpler to use in many cases than writing out the sync siteswap in its entirety (even 3x3* is much more concise than (4,2)(4x,2)*), which is why you will occasionally see it around (though again, it's mainly in passing patterns such as Jim's 3 count where it makes stuff a lot simpler).

The reason I used the above example was simply as a simple hurry pattern which people would recognise so I could use it for examples.

[1] The amount higher will be (4-1)2/(3-1)2 is 2.25 times higher - yes, technically your 4 should be 2.25 times higher than your 3 (assuming a dwell ratio of 1/2), you can see this if you put it into JugglingLab with a 'dwell beat' of 1 (dwell beats = 2*dwell ratio). If you're interested in why this difference is so large, Boppo (Bruce Tiemann) has a great video about it https://youtu.be/s09mV9TXEis

fat_hampster - - Parent

"""However, what you said about siteswap is not 100% correct, while siteswap doesn't care about the height, it does care about the relative heights of throws, so a 4 must be higher than a 3[1], so technically if you throw them at the same height it is not 423 (though arguably it's still better to call it that)"""

Actually, siteswap cares not for your relative heights, it is a notation for describing orderings. You can change your throw heights and dwell ratio dynamically in a pattern, e.g. gradually raising then lowering the height you juggle 5 balls. Assuming the twos are inactive, 423 and (4,2)(4x,2)* are both accurate, but 423 might be preferred for being more concise (in the same way that we prefer 3 to 522 or (4x,2)*). If you have active twos, then one of these becomes inaccurate depending on whether they are activated synchronously or asynchronously*.


* It can be argued that nothing is truly synchronous, but there is a point where you can't tell the order, and even slightly before that point it can be useful to pretend. (e.g. some people do 8 club 2 count singles slightly async)

Adrian G - - Parent

Very good point, thanks for mentioning that, I forgot that you could have differing dwell times for each ball, having a dwell ratio of (for example) .8 for the 4 and .3 for the 3 would make them both go to the same height from the formula I mentioned so that would work.

So, yes, my earlier post was assuming a consistent dwell ratio (and all the other siteswap assumptions, such as a regular beat, etc.) and in that case will hold.

"gradually raising then lowering the height you juggle 5 balls"
Depending on the amount you raise or lower it I believe you may have to change your beats per second (which breaks the 'regular beat' assumption of siteswap). From a 5b pattern with dwell ratio 0.5 you can get it ~1.6 times higher (dwell ratio 0) and ~1.8 times lower (dwell ratio 1) before having to change throwing speed. So all this adjusting of heights through dwell time (IMO) is not a good way to describe it (at least for the 5b example) as dwell ratios beyond [0.2,0.8] become extremely difficult and really aren't what you are actually doing when adjusting the heights the majority of the time as no one juggles with extreme dwell times like that

I do realise that you could have a changing beats per second and siteswap can still work due to it only caring *how many* beats have passed and not how long they were, but I feel like while you *could* say that, siteswap does expressively forbid it...

I'm happy to be corrected on ^ if you disagree but that's my understanding

fat_hampster - - Parent

So I don't remember the exact formulation people generally use for siteswap, but an assumption of regular beats seems pointless because the abstraction works just as well/better when you only consider ordering, and also because in practice people don't juggle with regular beats. It can be a nice property to assume for the translation, and it generally works out as the easiest way of juggling them, but I view siteswap purely as an abstraction for orderings, and the physical aspect of the beats interferes with that abstraction. Further you then need to consider other physical properties, such as, how does your example work with relativity? If a juggler is moving away from you at a high speed does the siteswap he's juggling change? Madness I say.

Adrian G - - Parent

I could also be misremembering here, but I've always thought that a regular rhythm was by definition, it may also be that that's what all the tutorials say simply to make it easier to understand...

After thinking over it a bit more, I feel like I kind of agree with you on some of that however, siteswap can definitely still describe it but I'm still not completely convinced that it's worth removing that restriction...

Either way it feels like a kind of moot point, so it might be better to just agree to disagree.

Cedric Lackpot - - Parent

> I could also be misremembering here, but I've always thought that a regular rhythm was by definition ...

It depends who you ask. Purists/pedants (like me) assert it's fundamentally about the order in which events occur, and the timing is at best of secondary importance; practical people (probably you, and most other siteswappers too) insist it tells you about timing too, because of the presumption of a regular or semi-regular rhythm.

Both arguments have merit; only one is wrong ;-)

Adrian G - - Parent

"practical people (probably you, and most other siteswappers too) insist it tells you about timing too"

I think I was a bit unclear what I meant there, I completely agree that the notation doesn't tell you anything about timing, as you said all it really cares about is order. However, siteswap is normally coupled (for better or for worse) with the assumption of regular rhythm. IMO, seeing as you can describe any pattern simply using a different siteswap, a dwell time and consistent throwing speed, then that to me is a good way to do it (I realise this is nowhere near as useful in practise for writing things down a lot of the time (though this is the assumption that most simulators work under) as there are weird resulting siteswaps, but to me simply changing the siteswap and keeping the rest regular can allow for any pattern, unambiguously, which I personally prefer.

However, from a theoretical point of view, I completely agree with you about the information that a siteswap actually tells you.

Brook Roberts - - Parent

I definitely wouldn't assume a regular rhythm. Doing so makes tricks like 4 club doubles-singles (53) no longer representable by siteswap in any sensible format, as almost everyone would juggle it at a galloped rhythm.

A lot of the tutorials also talk about siteswap being related to height, but I would claim they are wrong on that too :)

I think it would not be a moot point if you *actually* insisted on regular rhythm, because examples as above would have to become something weird like 7522 to represent the actual timing. You could do this, and do it consistently, but I think it's very unhelpful - like treating juggling 5 balls as different heights as different tricks.

Of course, I use e.g.(4x,2)* and 3 to mean different things even if the 2s aren't active. But I never claimed to be totally consistent!

^Tom_ - - Parent

I guess I'm the only person who writes the box as either 630 or 603, and (6x,4)* as 690, 960, or 672. People tend to think it's silly, but this way calculating transition throws I'd much easier.
When I say that the different notations are equivalent, people like to correct me by saying things like that it may be convenient to pretend they're the same, but that they're different really.

Adrian G - - Parent

I'm curious, any reason why you don't represent box as 612 instead? it seems like a more natural way than 630 or 603 to me...

^Tom_ - - Parent

I think I disagree with you. Obviously, the box is the pattern at which 612 423 630 and 603 all intersect, but in terms of maintaining appropriate throw values (which is the only reason why I would switch a number divisible by 3 and a 0 to a 3n+1 and a 2), the typical box has 4s and 2s, so if we're going to make the 4 larger, it seems wrong to also make the 2 smaller.

On the other hand, the jugglinglab simulation for 612 looks pretty good, but then again that's not the point.

I guess the main reason is that we know that there are 3 orbits, 1 odd number, period 3, and 1 unthrown throw, to me the simplest representation is 630 or 603, and I don't see any reason to tweak it.

Adrian G - - Parent

"so if we're going to make the 4 larger, it seems wrong to also make the 2 smaller."
Fair point, I suppose I was more thinking in terms of what feels like the box instead...

"3 orbits, 1 odd number, period 3, and 1 unthrown throw"
Yep, we're definitely thinking about it differently, I tend not to think about patterns in terms of orbits and crossing throws, I quite like that method of catagorisation though, I may start thinking about some patterns that way.

^Tom_ - - Parent

It's not necessarily how I think about patterns, but when writing an alternative notation for a pattern, these just tend to be some of the properties which you need to check that you preserve.

Topper - - Parent

WHOOSH

Orinoco - - Parent

Managing to keep up then Kev?!

 

Subscribe to this forum via RSS
1 article per branch
1 article per post

Forum stats