Animating with JugglingLab

From JuggleWiki

Note: all images do show a hover-hand, but none are links, just images.

The program for JugglingLab Animator is free: DOWNLOAD

---

This is what the Juggling Lab Animator Input Window looks like for our example:

"File" will only give you options to "Open JML" or "Quit", so it can be ignored.
"Notation" is set to Siteswap, so it can be ignored.
"Help" will not help, so it can be ignored.
"Pattern entry" will be set to show this input format, so it can be ignored too.
(see Searching for Siteswaps for what "Generator" does)

This is what the JugglingLab Animation Window looks like:

Let's look at the bigger Input window.
The input slot for "Pattern" takes only a valid site-swap code.
Program entry for JuggleWiki will be "pattern=".

If you try something that is not going to work in the animator, you will see:

or maybe

You must click "OK" (or hit "Enter") to proceed with anything.

The "Dwell" default is "0.65" which will prolong hand follow motions, so "0.5" is recommended.
Program entry will be "dratio=" as less than 1.0 (using "dwell=" causes peculiar hand motions).

"Throws per second" can be left empty, default will be calculated by the number of balls generated and their heights.
For instance, default for '3' is about 2.95, while '531' is about 3.48 with the higher toss, so it is intuitive to use.
Program entry will be "tps=" ("bps" is ignored in JuggleWiki).

"Hand movement" is changed to "custom" to make toss-catch changes, as is commonly necessary.
Program entry will be as "hands=" in format shown below.
Length of input slot may be less than length of code you will want; using a text editor may help.

"Body movement" can be (and generally should be) ignored, default is '0' as directly facing a person.
Program entry would be as degrees in parentheses like "body=(80)." with closing or separator periods which follow site-swap beats.
Program code provides rotation only around the vertical axis
...you can, however, drag the figure in three dimensions (above horizontal).
Rotation will be to absolute degrees, not incremental, counterclock to figure's left but minus from '0' is supported.
Pattern will track with rotation (but balls may be shown as passing through the figure to catch up).
Repeating: "can be (and generally should be) ignored".

"Prop type" can be changed to "rings" but will be disappointing:

unless you drag the figure into perspective

...and that format will commonly cut off the rings, as well as make confusing double traces.
You will not be able to see it this way by program code in JuggleWiki, even with a false passing format:
...the rings will still be shown shifted to display as lines.
Using "ring" format is for your private use.

"Manual settings" will take:

"mat_style=" a relic of Ken Matsuoka's JuggleMaster animator; readily changed to "hands=" as explained below by making animation and then deleting this code.

"colors=" each inside curly braces { }, either black, blue, cyan, gray, green, magenta, orange, pink, red, yellow; or in RedGreenBlue format {0,0,0} through {255,255,255}, assigned (supposedly) in order of the site-swap; no separators or closing period; if used, all three RGB values must be shown; default is red, choosing "mixed" will be a poor choice.

"gravity=" default is "980" with lower numbers making lower tosses, higher numbers making higher tosses (at "2000" a '5' as the pattern's highest toss will be at '7' height).

"propdiam=" is set for ball diameter of 10 cm relative to the figure (like 4" stage balls), allowing good visibility and checking for collisions; rarely a reason to ever change it.

"bouncefrac=" default is "0.9" for 90% rebound, changes only hand height for release, with "0.5" looped higher than for level "0.95"; rarely a reason to ever change it (bounce is poorly represented by JugglingLab anyway).

These settings can be in any order, they must be separated with a semicolon.

Let's use the 4-ball pattern '53' to see how the variables affect an animation.

Using "Dwell" values of "0.3", "0.5", and then "0.8" will show various differences,
because different portions of the beats are flight.
Looking at each at the moment of Left-hand toss:

...you can see different stages of the other balls in the pattern.
Notice the right arm for the third figure, extending too far down, typical for higher Dwell value.
Notice also the oddly too high right-hand position for Dwell at "0.3" on the left.
That is from the program's hand-momentum function for a smooth arc from event to event,
a wonderful innovation, but it does also make some odd motions that are hard to reduce.

Looking next at the moment of highest point of ball path, there is quite a range:

The less time in hand, the more time in flight, so Dwell at "0.3" makes for higher tosses
. with Dwell at "0.8" being even less realistic for the site-swap toss values.

Now, let's look at "Throws per second" which will program as "tps=".
Compare a "Tps" value of "3" with using a value of "6":

There are major differences in heights, as well as run speed.
The animations are at different scales, to always fit toss height into the standard box.
(note: toss width may not be included; how much is shown below waist line is also variable;
the relative window can be specified in JuggleWiki, but the Animation Window does not include more for dragging a border.)
There are again oddities of hand motions for "Tps" at "3", rising way up and stretching way down:

    

You can counteract those results for "Tps" at "3" by putting "gravity=600" in the "Manual settings" slot:

         

The maximum height is brought down into normal range, the right hand still reaches up but not as high, and not down as far.

You can do the same thing for a "Tps" value of "6" by making "gravity=1800" in "Manual settings":

If you want your animation to show details for learning the pattern, "Tps" needs to be set near the ball number,
modified by lowest and highest toss value to adjust height and scale.
The program's internal "slowdown" default is "2" meaning half-reality speed, and is much harder to use sensibly, so is discouraged.
Many animations at JuggleWiki with five balls or more are using a standard of tps=4.5
with window height increasing with toss values from 350 for a '7', such as:

<juggle height=400>

pattern=97531

tps=4.5

dratio=0.5

If you run just "Defaults" for '53', you will get a collision:

This is very common with default operation, more with more balls.
To get an instructive animation, and to work out what you would have to do to do the pattern,
you would want to alter hand positions.
That is where JugglingLab exceeds all other programs, but is sadly neglected.

First step is to drop down "View" and choose "Visual editor"

...to make this window:

...and stop the action by clicking on the face (or whatever will stop it).
What is now on the right is the old site-swap Ladder Diagram (or "space/time" etc.).
The two black heavy vertical lines are the time-line for each hand as you see them --
left is the left hand, right is the right hand, with the top earlier and bottom later
...but the figure is facing the other way around (and that may be a persistent problem).

The black dots are "nodes" or "events" meaning hand positions at toss or catch (or others as defined).
The colored dots are the balls at a node from the site-swap; colors are shown as defined, per moment;
for multiplex, there will be that many ball dots at a node, traced separately, see below.
You can drag a black node dot with its ball dot, but do not do that for now --
those are the time "beats" of site-swap, and are where they need to be.

The thin black lines are ball paths, vertical while a ball is held,
crossing if an odd-value toss (or x), looped if even-value.
Where a thin black line goes down away from a colored dot, that was a toss.
Where a thin black line goes down to a colored dot, that is a catch.
With Dwell at "0.5" a left catch will align with a right toss, as above;
with higher or lower Dwell value, the alignments will be shifted down or up, and farther apart or closer per hand;
for synchronous patterns both tosses will be aligned.

The red horizontal line is the present moment in the animation.
When the animation is running, that line is sweeping down the diagram.
When the animation is stopped, that line can be dragged, with top and bottom continuous, and the animation will follow it.
It will also snap to wherever you click on the diagram.

Put the red moment line at the top.
Clicking on a ball dot will make a green square on the dot and in the animation (running or stopped):

That shows the default position for the first toss, where it causes a collision by being too close to the catch position.

Drag the green square on the figure to the position shown below to shift right-hand toss location:

Notice that the ball (with hand/arm in this case) will follow the results of that shift.
Set the red line to show the collision, and see that it has improved:

Leave the red line at the collision point.
Click on the second right-hand ball dot to show catch position, and drag its green square on the figure to about here:

As you drag the square and pause, the animation shows results, with the collision widened more safely.
Animations are diagrams for study, and making at least an entire ball-width separation is a good guideline.

If you thought the default left catch was too far out, move it too, watching the top for conflict:

If you now click on the figure to make it run, you can check for other improvements you might like.

To put an adjusted animation at JuggleWiki, you need to specify hand positions in its code format.
That is not an exact science, but usually does not have to be better than "close enough".
Learning where common numbers are, will be how you guess well for the "Hand" code:

This shows at (0); at (10); at (20); at (30); at (40); at (50).

The code has a necessary order: right, left, right, left for async patterns,
...but for sync patterns it is: left, right, left, right (may be a persistent problem).
It also is always stated as toss first (required) followed by catch (with other hand nodes definable).
What you do is put each event location in parentheses, normally pairing toss then catch,
followed by a hand separator period; then, the next hand in order -- even if '0' toss value.
If you miss a period or parenthesis, it will give that error message as an overlay.
If it finds a pair of parentheses without an appropriate number, it will do something scary:
it will show an "internal error" window with confusing code, and ask to "Quit" or "Continue" -- always "Continue".

For async, as '53' is, start with the top right toss ball dot, the first site-swap digit, and guess its number.
If both tosses were moved to about "5", and both catches were out at about "40", that would be:

...which will make both hands toss and catch that way, since code strings repeat.
Note that hand values are positive for each hand from the same '0' centerline.
Hit the "Juggle" button (or "Enter" if Input window is active) and see how it looks.

To show either hand across the midline, the first parameter is made minus, as a right hand at "(-10)":

There are two other hand parameters, separated by a comma: the second is up/down,
and this shows "(25,-10)" for a left hand:

The third hand parameter will let you move front to back (as 'x,y,z' in geometry, ignore icon labels).
Normal toss plane is at "0", so back to body plane is at "-25", a back-toss can be at "-45".
This shows a right-hand back-toss about to be made at "(-15,0,-45)":

(note: elbows cannot be controlled directly, and may do odd, snapping contortions, even passing through the figure)

You can put the green square back there graphically by rotating the figure to drag the green square on that axis:

You can choose more defaults with "Hand movements", but trying "outside throws" will again collide:

The input slot will show "(32.5)(10)." which is a hold-over from "mat_style"
which incremented by 2.5 cm (that's why it is so hard to understand).

If you wanted to work on the version of '53' as nested arcs, you might try the default "half shower" setting.
It will make "Hand" as "(32.5)(10).(10)(32.5)." and you may think the '3's are too close.
As shown above, just move the toss and catch positions farther apart, say to "(40)(25).(25)(40).":

You could continue to tweak the animation in the same manner as above,
and also for trying to solve common problems like snapping elbows and rubber arms:

This is showing a cross-side toss with the program having put the "scoop" swing way down there.
That condition is usually solved by changing one hand position, or maybe also with dwell or tps as above.

Another problem is arms shown passing through each other, as in this sequence:

For anything behind the figure, the arm will be shown as passing through the body.

To solve those problems, you would need to make other nodes by "right-clicking" near a time-line on the Ladder Diagram:

...and clicking for "Add event to" the side you want.

Here is our example '53' returning from a Back-toss, with another other node below for getting around the hips to next toss:

To test that with another animation display, you must also add those as parentheses in "Hand" input,
marking the catch with a 'c' as in "(35,5)c(-15,10)(-5).(-15,-10)(0,-5)c(40)." shown below.

You can add a node to control hand position anywhere on the time-line,
but can add it in the code only after the toss, in time order, to occur only as a regular fraction of the beat.
Additional nodes may make the animation jerky or robot-like, from additional calculations required.
The nodes, with ball "events", will drag up or down, too, making variable dwells.
But there is no Input window or Jugglewiki code for variable dwells.

Note that only the site-swap code you entered will make a toss with a catch.
You would show more to adjust on the diagram by duplicating the site-swap in "Pattern" like "535353"
or by adding parentheses pairs to "Hand" input, and making another animation display.
(if the additional Hand parentheses do not match the site-swap, the tosses will progressively go wrong)

A common way to put something "new" at JuggleWiki, is to make an under-arm toss somewhere:

After adjusting the animation, we can produce a Windmill-like variation, but then what.
Remember, it is gone with that animation window or any further changes to it.
For JuggleWiki, you need to figure out Hand code values, using the guide key above,
and input those in parentheses in "Hand movement" to see how you are progressing.
The later one using the coded input is placed to the left of our manually adjusted one to compare nodes:

Oops -- two errors: missed a minus for right-hand catch, and too far out for left-hand catch.
Input those changes as the new code and hit "Juggle" (or "Enter")
and drag the red moment line to check all positions:

Not satisfied with the arms still crossing through, we insert a node for both hands, as mentioned above:

Next step is to make a simple program with all the variables used:

<juggle>

pattern=53

dratio=0.5

tps=3.75

hands=(35,5)c(-15,10)(-5).(-15,-10)(0,-5)c(40).

</juggle>

For you, the name can be anything that will remind you what that was.
For JuggleWiki, however, some accord with previous usage is preferred.
This pattern is done in the manner of 3-ball Windmill, and so it becomes so posted at 53.

The basic variables and methods do not change for synchronous or multiplex patterns, or for more balls.

Here, for example, is a Synchronous Crossing or Wimpy version using (4x,4x):

...and Hands as "(10,-10)(35,20).(5,20)(35,-10)." (notice both tosses aligned together).

And here is a multiplex version of our '53' pattern, '[53]31'
with the brackets changed to curly braces as required for JugglingLab input:

The Ladder Diagram is doubled below the gray line to show odd-period continuation from the other side.
There are two additional tosses, a second '3' and the '1', which you can see by the slopes of the lines.
The '1' is only one beat, so those nodes are close together, adding to the jammed effect.
Being multiplex, there are two nodes for the duplex catches, with two tracks for being a '3' and a '1', then two balls at those nodes.

Each ball in the duplex is tied to its shared node and is tracked separately by the animation,
including by order of catch and then toss, which you can see better by pulling the lower window border down:

(note that the animation still fills its window, with no more area for what may be cut off).
It now shows better the first-in, last-out tracking for catch, then catch the '1', then toss for the blue ball
...which may not be the way you would want to toss the '5'.
You can change the site-swap toss order to "{35}31" to show a change also in catch order,
and you can shift the green squares on the animation per node as above,
but you cannot make separate locations for the duplex catch events by code:

The animation will show paths for 'splits' or 'stacks', but there is no hand to show how that would happen:
you will make it happen in your hands, however you need to and can do.

Here is '534' showing the other sort of path line in the Ladder Diagram:

The toss for the first async site-swap digit is always at top right (well, maybe not quite always).
Thin vertical lines along the wider black time-line show Dwell or when the ball is held.
The shorter crossing lines are the '3', the loop is the '4', the longer steeper lines are the '5'.
The gray horizontal line shows where the pattern repeats from the other hand.
Default values for Hand will again make a collision, and that does not show on the Ladder Diagram.

If you wanted to make changes for '534', you would show and drag green squares until it worked as you wanted.
To collect the Hand codes, you would start by making parentheses pairs for each site-swap digit:

Starting with the first toss at top right and the first catch below it, then the first left toss and catch,
fill them in as above, and run "Juggle" to compare as above.
Make the program as above, test it at JuggleWiki in Sandbox, find a page already there to add it,
or go to NewPage to make a new one.
To save a file on your computer or to email to someone or to embed in an HTML file,
you would choose "Animated GIF" from the Animation window "File" drop-down
available only for an original window, not after you have opened Visual Editor.
So still, you make the parentheses pairs for Hands etc. to make a new Animation display to Save.

With longer site-swaps and longer Hand descriptions, animating with JugglingLab can get complicated.
The main problem will always be to find a site-swap that will allow you to make the pattern you had in mind.
For Hand descriptions much longer than the input slot, using a simple text editor will help.

---