Setting Dwell Time to 1.0 gives an empty animation sometimes
Closed this issue · 10 comments
This is the case for 51x* for example
Thanks for the bug report, I've never seen this! I verified that pattern=51x*;dwell=1 gives an empty animation in version 1.5.2. If you encounter any other examples, please let me know.
In this case the cause can be seen in the output JML:
<?xml version="1.0"?>
<!DOCTYPE jml SYSTEM "file://jml.dtd">
<jml version="2">
<pattern>
<title>51x*</title>
<basepattern notation="Siteswap">
pattern=51x*;dwell=1
</basepattern>
<prop type="ball"/>
<setup jugglers="1" paths="3" props="1,1,1"/>
<symmetry type="delay" pperm="(1,3,2)" delay="0.9756"/>
<symmetry type="switchdelay" jperm="(1,1*)" pperm="(1,2,3)"/>
<event x="18" y="0" z="0" t="0" hand="1:right">
<throw path="1" type="toss"/>
</event>
<event x="-45" y="0" z="0" t="0" hand="1:left">
<catch path="2"/>
</event>
<event x="-31.5" y="0" z="0" t="0.2439" hand="1:left">
<holding path="2"/>
</event>
<event x="-31.5" y="0" z="0" t="0.2439" hand="1:left">
<holding path="2"/>
</event>
</pattern>
</jml>
The two holding events at the end are apparently causing the layout engine to have problems, because they are at identical times and for the same hand. If we manually remove one of them we get the pattern we expect. dwell values like 0.99 and 1.01 also work fine.
A separate bug is that range checking on the dwell parameter isn't working. We should be checking that 0<dwell<2.
Issue fixed and committed to the master branch. I decided the cleanest way to address it was in JMLPattern.addEvent(): It now detects when there are two events for the same hand at exactly the same time, and merges those events.
Will leave the bug open for a while in case we see other related issues. Thanks again @froudaut for reporting it!
Hi @froudaut , I confirmed that my fix also works for pattern=6x0*;dwell=1. Thanks for reporting!
i have seen that recently hands ss has been implemented on jugglinglab as it is described in the book of Polster.The proof basically relies on Shannon theorem and as a consequence on uniform juggling. It seems to work well on non uniform juggling but do you know if proof has been done for that ?
The hand siteswap concept isn't constrained to uniform juggling. If you have Polster's book, the best illustration of hand siteswap is his figure 4.7 on page 110: This diagram shows nonuniform juggling because the balls have varied flight times. (Polster does confine his discussion to uniform juggling for his initial proof of Shannon's Theorem earlier in that chapter, although on page 103 he relaxes this restriction and proves Shannon's first theorem in the context of general juggling sequences. This discussion may have brought uniform juggling to mind.)
The biggest limitation to Juggling Lab's implementation of hand siteswap is that it's limited to a single hand throwing on a given beat. (Polster's figure 4.7 also illustrates this situation.) The way it works is that the hss determines which hand is throwing on a given beat, and that hand assignment is then applied to the pattern (or "object siteswap" = oss; what Polster is showing across the top in figure 4.7). Behind the scenes this is all converted into Juggling Lab's extended siteswap notation, then animated. Within this model the only real constraint is that if there is a nonzero throw in the pattern on some particular beat, there can't be a corresponding 0 throw in the hand siteswap. So pattern=3;hss=20 doesn't work because there's no hand to throw on beat 2, but pattern=40;hss=20 does work, because the pattern doesn't need a hand on beat 2. Note this constraint isn't symmetric: We can have a 0 in the pattern where there isn't a 0 in hss, because while it's ok for a hand to be without a ball, it isn't ok for a ball to be without a hand!
Now one can imagine a generalization here where we allow more than one hand to throw at the same time. Of course this is very common in juggling, solo and passing. This would correspond to a multiplexed hss. So in principle something like pattern=[64]0;hss=[22]0 could work, because you have two balls being thrown on each odd beat, and two hands available with which to throw them. But you get an ambiguity in terms of which hand to assign to which throw: This pattern could correspond to either (6,4) or (4,6) in conventional notation, depending on how you make that assignment of hands to throws. So you'd have to disambiguate things somehow, and the notation would get messier.
There is a related ambiguity regarding ball assignments in regular multiplexing: When you throw a multiplexed throw, which ball gets which throw? The way Juggling Lab does it is that the outgoing throw slots "fill up" as the balls land, and when the multiplexed throw comes, the throws are assigned in the order listed inside the []. If you look carefully at pattern=24[54];colors=mixed and pattern=24[45];colors=mixed you'll see the patterns are actually different when the balls are labeled. There would need to be some similar sort of identification to make multiplexed hand siteswap work.
@JigyasuJuggler and @aditya95sriram as the architects of Juggling Lab's hand siteswap feature do you have anything to add or disagree with? :)
@jkboyce: I think your explanation is quite comprehensive.
@froudaut: The hss notation will work for any asynchronous pattern (only one hand throws at a time), whether uniform or not. See https://jigyasujuggler.com/2019/03/25/vanilla-siteswap-extensions-an-alternative-approach-i/ for a detailed explanation for this.
As soon as two (or more) hands throw at the same time, we'll need something like multi hand notation. @jkboyce has explained the reason for this also. To word it differently, we treat the objects as indistinguishable but the hands as distinguishable so the same notation that we use for objects doesn't work quite as well for hands.
Hope this helps!
@froudaut : You are right, I should probably say galloped polyrhythms. The problem with such terminology though is that there is no end to it - for example, what do we call a pattern where the right hand follows a rhythm of 2 throws per second, then 3 throws per second and repeat and left hand follows a rhythm of 3 throws per second then 1 throw per second and repeat?
However, accurately representing (the timing involved in) these patterns through siteswap notation need not be so complicated. Here is how I look at it:
- Any juggling pattern (by definition, a pattern is something that is repetitive) can be represented using Multi Hand Notation (MHN) as presented in Polster's book chapter 4 (pages 85 - 90). Something equivalent like Luke Barrage's beatmap notation could also be used. Though Polster does not explicitly mention/demonstrate this, but MHN can represent galloped patterns, hurries, polyrhythms and so on (see point 6 below). When I say 'any' juggling pattern, I mean in terms of throw timings, not body throws and other such embellishments.
- For patterns that do not involve any synchronous throw, one may feel that MHN is an overkill. This is where the oss/hss notation comes in. It retains the simplicity of vanilla siteswap without needing extra symbols like *, !, x, p, etc. even for passing patterns involving any number of jugglers. As demonstrated in the article I sent earlier, using vanilla oss/hss enables us to represent any asynchronous pattern to an arbitrary degree of accuracy by creating beats which last for smaller and smaller time intervals (usually, things will be much easier than that). However, if there is even a single synchronous throw in the pattern, the oss/hss scheme will not work and we'll have to go to the MHN scheme (see point 7 below).
- If MHN and oss/hss is available, we do not need any additional notations like *, !, x (as commonly used or as used in Toukola's article - thanks for sharing!) to simulate any pattern. We also don't need the R, L hand modifiers of Juggling Lab or the 'p' for passing patterns. However, these additional notations are still very useful to visualize the pattern by just looking at the sequence. But checking whether a given sequence is valid or not, or inventing new valid sequences becomes difficult.
- Also, as demonstrated in the link I sent earlier, the implementation of hurries in JoePass is such that 4x 4* is a 3-ball pattern so even the average theorem doesn't work any more. This however, may be because of the way JoePass implements hurries rather than an inherent problem in the notation itself, I am not sure. But it illustrates the previous point I made about the difficulty in validating sequences which use such notations.
- The terminology like hurries, gallops, polyrhythms is also still very useful in giving a qualitative feel and a visualization of the pattern, but for simulation purposes, no new notation apart from MHN and oss/hss should be needed.
- In the second part of the article I sent earlier, most of the patterns (except squeezes) presented in Hans Nickman's article that you shared have been analyzed. It has been shown how these patterns can be accurately simulated using either oss/hss (for asynchronous patterns) or MHN (if the pattern has any synchronous throws). Squeezes will need us to change the way landing events are allowed in the simulator. Juggling Lab used a 'splitcatchfactor' to create different catch times so that squeezes were prevented. I'm not sure if the bug fix that this conversation started with will also now allow squeeze catches?!
- The appendix of the second part linked above also includes an example of how we can in theory, 'almost' simulate patterns with synchronous throws using the oss/hss notation if we really want to avoid MHN for some reason. I would not recommend this though (too much work)!
- In your polyrhythms diagrams you have pointed out the possibility of adding extra hold times to reduce throw heights - I believe this is exactly what is accomplished by default by the 'dwellmax' key in the new hss feature of Juggling Lab, but for asynchronous patterns. In theory, I believe it should be possible to enable this dwell maximization for MHN notation too if a simulator were to implement this notation.
Closing since original issue resolved