Siteswap Explorer web app preview
About a year ago I released my iOS App 'Siteswap explorer'. My Apple Developer account has just expired and Apple have removed the app from the store. Being a fool, I had some stupid idea that it was going to stay there. Ho hum. I'll probably renew the account but maybe only when I have something new to release.
Meanwhile, I've been working on a cross-platform rewrite. The intention there was to release new iOS and Android versions using the same code base, but then I experimented with reusing the logic in a web app and this happened. I've used a siteswap animator which should be familiar to Edgizens!
Here it is: https://siteswapexplorer.azurewebsites.net/
The design is very rough and ready at the moment. Fixing that's the next phase. What you see here is the 'make anything work' version.
Oh yeah, if you have an iOS device and you add the page to your home screen, the navigation buttons will be hidden, making it look more like an app.
I've added 'excavate ancient devices' to my to do list, but I don't think success is guaranteed there! Success with the code, that is. There are ancient devices to be found! Some may even work.
After making 51 one handed (to a020), there is then an option to Make One Handed. Which seems... interesting.
Hah! There are lots of algorithm tests but that one's a little too concrete for the headspace I must have been in at the time so I didn't think of it!
It still lets you do 'showerify' multiple times which does strike me as strange, but it's a touch more valid than the issue you mentioned.
I've also made slight changes to the animator (draw a few fewer things, change some colours, probably not going to make it burst into life on devices which didn't work before that change).
Thank you for making this available to non-smartphone owners!
This is great work, there are a number of functions in there that I didn't know about (extend up/down, dual) & I can't immediately work out how to calculate them myself. I have less inclination these days to think about these sort of things so it's nice to have some software to do it for me!
I was pretty savage with my optimisation of the animator. From memory I cut out all the considerable amount of different prop related code. Then I found there was a lot of work being needlessly repeated every frame in both the hand & prop update functions that I moved back into the constructor functions eg. the body was being recalculated each frame, I calculated the path once in the constructor & saved it as a variable (I don't think the nodding head is necessary!)
I don't think your siteswap explorer app needs anything that is not in my stripped down version (Tom's site needs a lot more features) so I would've thought the Edge version might have been an easier starting point for you? There's a little bit of code for synch hand movements I think that you could strip out if you want to optimise further!
Thanks, glad you like it!
The other changes I mentioned relate to 'colour by orbit' which is my favourite feature form the mobile app but is still missing on the web version. The problem there is that the current version creates a new ball for each throw. Quite some sleight of hand for a hand which is the end of a line! I did some ugly stuff to make ball IDs work for balls which have been thrown, but I really want to be able to colour each hand's next 'not yet thrown' ball too, which would get even uglier. And of course I've certainly broken non-vanilla siteswaps (which I suspect will never be handled by Siteswap Explorer, but whatever). I asked Tom who I've not met but is clearly awesome about that and he's offered to have a look at restructuring the code so the balls can persist.
I'm irritated that Apple want 100 hard-earneds a year for me to keep a free hobby app in the store. The cross-platform rewrite is working on iOS, Android and Windows. MacOS and Linux are probably also possible if I wanted to maintain even more binary releases. But now that the web app is looking viable I'm experiencing a bit of 'but I'm a mobile developer' existential angst!
I was quite surprised when I learnt that the props were created anew each throw. I thought that was a very clever solution I would not have come up with myself.
Instead of rewriting everything to track props I think it would be easier to precalculate the sequence of colours to be thrown from each hand & just look up the colour & assign it to the prop when it is created & pass the colour to the hand when the prop is destroyed.
In the ValidateSiteswap function it populates the this.left & this.right arrays with the throw each hand makes on each beat.
eg. for 534 it calculates:
this.left = [5,0,4,0,3,0];
this.right = [0,3,0,5,0,4];
At this point in the code you should have all the info required to calculate the full colour sequences:
this.leftcolour = [red,0,blue,0,green,0,blue,0,octarine,0,green,0,octarine,0,red,0,green,0,red,0,blue,0];
this.rightcolour = [0,green,0,octarine,0,red,0,green,0,red,0,blue,0,green,0,blue,0,octarine,0,green,0,octarine];
Or at least that seemed easier when I thought of it but now that I've written it down & read it back I'm not so sure!
If you go this route then you may be better off sticking with the original code because one of the other optimisations I think I did was to draw all the props as one path whereas I believe the original code drew each prop as it's own path. One of the best ways to speed up canvas animation is to reduce the number of changes to the context state, I think of it as pick up pen draw circle, put down pen, pick up pen draw circle, put down pen... vs pick up pen, draw circle, draw circle... put down pen). However if you need to pick up different colour pens anyway this doesn't matter.
I’ve been meaning to reply but I’m still thinking!
Tom has come through with changes to support a list of ball colours.
I think I will still come back and see how much of your optimisation principes can still be applied later but yeah, I’ll be starting with the original code.
The site has gone live with its new URL and a few new features: https://siteswapexplorer.com
Nice, although not sure colours are working consistently for base patterns, eg 3, 33, 3333, 33333 shows the balls all in red, but 333, 333333 has 3 different colours
Hah, I’ve had to get creative with my answer: my phone is determined to give me a transparent nothingness where I would hope for the Edge to normally show a keyboard!
The reason for that colouring isn’t immediately clear but I think it’s correct. For the first 3 of 333, the next ‘let’s call it a throw’ is 3 beats later. So it’s always that first 3. If you view 300 and 330 that may become clearer.
In 33, the first 3 is thrown, then the number three beats later is the second three. Three beats after that is the first 3 again. So both are in the same orbit.
I’ve been enjoying others examples of how changing the number of cycles also changes the orbits. A favourite is:
Of course, I've only just realised that I could also have said "Yes, it defaults to 'colour by orbit' mode". I need to think about how to communicate stuff like that better on the site!
Hah, perhaps I should better have anticipated the need for a good robots.txt in my 'generate all the links you can think of' site!
Subscribe to this forum via RSS
1 article per branch
1 article per post