Siteswap transition generator!
I mentioned a while ago I had a quick & dirty transition generator. I've been tinkering with it for a few weeks & would now like to present my slightly cleaner version.
It handles transitions from/to asynch, synch, & multiplex siteswap in all permutations.
The asynch to synch / synch to asynch transitions have lead me to add another couple of characters to the siteswap syntax. I've created a help page: What do the / and + characters mean? Feedback on the clarity of my explanations would be much appreciated. I feel adding these characters is clearer & less likely to tie the user up in boolean logic than the method used in Pedro's transition generator.
Other features:
It comes up with a lot of multiplex transitions skipped over by other generators.
You can click on a transition to view a pretty(?) diagram showing the transition.
You can cycle through entered siteswaps to experiment with different entry/exit points.
Please note when working with higher numbers/longer siteswaps it can get pretty resource intensive so you may have to be patient!
#NewFeature
Wow, that’s great! Thanks for making and sharing this. Ran a few examples and to me it seems to work well, great visualization with the ladders too. Those multiplex transitions I had never considered before - super interesting! Will check out some sync to async and vice versa later.
This is really cool, thanks for making it! I really like that it shows the diagrams :)
Your notation is interesting but I personally find standard siteswap much clearer for these types of transitions and also more general, but maybe I'm just too set in my ways. All the implicit things happening in the background here confuse me, I think a + is +1 and add an x and the / is adding a 1x to the hand that's not throwing first (at the same time as the first throw) if going sync-to-async and simply adding a 1x if going the other way? I.e. (4,4+)/4 => (4,5x)(4,1x)! and 4+4/(4,4) => 5x41x(4,4). At the very least it feels worth including the siteswap in a JugglingLab link to a simulation of the transition. That said, it is kind of nice that it forces transitions with a 1x and doesn't view the 1x as part of a separate transition throw instead of part of the second siteswap, so maybe it is a better notation for most cases.
As to the actual explanation, all your beat numbers in are half what standard siteswap says (a 4 is now thrown again 2 beats later), not sure if this was intentional or not.
The diagrams show simultaneous throws at different points on the horizontal axis which I normally view as time. Also for (4,4+)/ for the default ones, it looks like it's actually showing (4,4+)(4,4+)/ the way I'd read it as it doesn't show the simultaneous catch followed by the 1x. I assume this was all to keep the diagrams simple like the notation, but I find that a bit odd.
Also really like the multiplex transitions, makes a lot of sense that they're possible but I also don't think I've seen transition generators give them either.
Thank you BasB & Adrian for the encouragement & feedback.
Both the JugglingLab help page & JuggleWiki acknowledge 'odd' & 'unusual' things about the notation. I feel that the notation used by JugglingLab breaks too many established rules (x means a crossing throw, even throws only in synch, x only used in synch etc.) to be easy to follow. I also don't like the mixing of synch & vanilla notation, it forces you to look that little bit closer to determine which is which.
If I ever get my head around the use of the ! symbol I'll have a look at toggling between both notations.
I've not seen diagrams drawn any other way for synch siteswaps (& is how I came up with converting synch to asynch before validating that I use everywhere). I kept the (,) notation in the captions to help highlight which throws are paired together which I thought was clearer than grouping the dots closer together (& the code for drawing the curves was easier!) Do you have an example of how you would draw it?
I've now rewritten the help page so that examples consistently start from asynchronous patterns which helps keep straight what a beat is.
New help page looks good!
I guess I don't care about those rules (tbh I never thought of them as rules before you said that). You only have even throws in normal sync because you're only throwing every 2 beats, you normally can't use x in async because it would mess up the alternating hands at an even rhythm and to me 'x' has always meant 'does the opposite of normal.' This is probably because I learnt sync and mixed sync/async at around the same time though...
You've probably heard this explanation of '!' a million times, but in case not, it means to leave out the implicit empty beat after a sync pair - e.g. in your tables in the help page, the sync throws are only every 2 beats on even beat numbers, using ! after a (4,4) lets you notate what happens on the next beat rather than two beats later.
I would either do something like one of these (top is closer to what you have, bottom is just a standard ladder diagram). Both unfortunately are still much more complex than what you have, however they keep straight that 4s are thrown again 4 beats later and 5s are thrown 5 beats later which to me isn't obvious otherwise, e.g. leaving out the 1x makes it look like the 4 is thrown again 5 beats later. But yeah they definitely end up more complex so may not be worth switching.
Yeah, I've read several variations of that explanation. I think my problem is I don't 'see' the implied empty beat after each pair. I was never taught synch siteswap, I just worked out a way to make sense of it that I think is different to most other people's understanding.
I think Jack Boyce's vision of synchronous siteswap is two separate timelines, one for each hand that interact with each other through crossing throws. Whereas I consider a synchronous pattern to be one timeline where both hands still throw alternately, but the left hand throws 1 beat after the right and the right hand throws 0 beats 'after' the left.
Thanks for the example diagrams, although I agree both are much more complex.
Subscribe to this forum via RSS
1 article per branch
1 article per post