Causal diagrams and rhythm - Invitation to edit

[JaCo Stuifbergen (via Google Docs)]

j.c.stu...@gmail.com has invited you to edit the following document:

Causal diagrams and rhythm

Many animators allow to change parameters like juggling speed and height.
So we want to have a notation that describes the pattern, without fixing things like speed or height etc.

But if an animator always applies throw-on-the-beat, we would need 2 notations for the same pattern, depending on the physical parameters.

Open in Docs

Google Docs: Create and edit documents online. Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA You have received this email because j.c.stu...@gmail.com shared a document with you from Google Docs.

[Florian Pesth]

I have added a diagram and some text for an example of a polyrythmic
feed pattern based on 531 (not sure if anyone can juggle this - I
doubt it because it contains some 1 beat passes and is ridiculously
hard probably but it is more an example - I'm sure one can come up
with more juggleable patterns). As I noticed while drawing it does not
repeat after 36 beats of juggler A but it should repeat proably after
108 beats or something.

Also - I might have unintentionally spammed the comment section while
typing - sorry about that!

Am Sun, 25 Oct 2020 15:40:48 +0000
schrieb "JaCo Stuifbergen (via Google Docs)"
<j.c.stu...@gmail.com>:

> I've shared an item with you:
>
> Causal diagrams and rhythm
> https://docs.google.com/document/d/1d5zAFCprqpY0aZbUZenFsaYyZVzUF08uWbam9GQ_B5c/edit?usp=sharing&ts=5f959c80
>
> It's not an attachment – it's stored online. To open this item, just
> click the link above.

[JaCo Stuifbergen]

Florian,

I think that the pattern can be noted like:

throws = [

{beat:1, duration:3, from:"A_left_hand”, to:"B_right_hand”},
{beat:2, duration:1, from:"A_right_hand”, to:"A_left_hand”},
{beat:3, duration:5, from:"A_left_hand”, to:"A_right_hand”},
.....
{beat:1, duration:4.5, from:"B_left_hand”, to:"C_right_hand”},
{beat:2.5, duration:1.5, from:"B_right_hand”, to:"A_left_hand”},
{beat:4, duration:7.5, from:"B_left_hand”, to:"B_right_hand”},
{beat:5.5, duration:4.5, from:"B_right_hand”, to:"C_left_hand”},
{beat:7, duration:1.5, from:"B_left_hand”, to:"B_right_hand”},
......
{beat:1, duration:0, from:"C_left_hand”, to:"C_right_hand”},
{beat:2.125, duration:3.375, from:"C_right_hand”, to:"B_left_hand”},
{beat:3.25, duration:1.125, from:"C_left_hand”, to:"B_right_hand”},
{beat:4.375, duration:5.625, from:"C_right_hand”, to:"C_left_hand”},
{beat:5.5, duration:3.375, from:"C_left_hand”, to:"C_right_hand”},
{beat:6.625, duration:1.125, from:"C_right_hand”, to:"C_left_hand”}

..... ]

or like

[
{start:1, end:4, from:"A_left_hand”, to:"B_right_hand”},
{start:2, end:3, from:"A_right_hand”, to:"A_left_hand”},
{start:3, end:8, from:"A_left_hand”, to:"A_right_hand”},
...
{start:1, end:5.5, from:"B_left_hand”, to:"C_right_hand”},
{start:2.5, end:4, from:"B_right_hand”, to:"A_left_hand”},
{start:4, end:11.5, from:"B_left_hand”, to:"B_right_hand”},
{start:5.5, end:10, from:"B_right_hand”, to:"C_left_hand”},
{start:7, end:8.5, from:"B_left_hand”, to:"B_right_hand”},
{start:8.5, end:16, from:"B_right_hand”, to:"A_left_hand”},
...
{start:1, end:1, from:"C_left_hand”, to:"C_right_hand”},
{start:2.125, end:5.5, from:"C_right_hand”, to:"B_left_hand”},
{start:3.25, end:4.375, from:"C_left_hand”, to:"B_right_hand”},
{start:4.375, end:10, from:"C_right_hand”, to:"C_left_hand”},
{start:5.5, end:8.875, from:"C_left_hand”, to:"C_right_hand”},
....... ]

(by the way, the hands may be indicated by integers)

Is this notation suitable for you?

Co Stuifbergen
=========================
in...@jacos.nl
www.jacos.nl
+31 6 13 02 44 69 (mobile)

Kloosterwei 102
2361 XN  Warmond
the Netherlands
=========================

[Florian Pesth]

Jaco,

thanks, this would work and looks less ugly then I imagined.

If one uses the timebase of juggler B as 1 (which should be
valid) however there would be another requirement:

throws = [
{beat:1, duration:2, from:"A_left_hand”, to:"B_right_hand”},
{beat:1.67, duration:0.67, from:"A_right_hand”, to:"A_left_hand”},
{beat:2.33, duration:3.33, from:"A_left_hand”, to:"A_right_hand”},
.....
{beat:1, duration:3, from:"B_left_hand”, to:"C_right_hand”},
{beat:2, duration:1, from:"B_right_hand”, to:"A_left_hand”},
{beat:3, duration:5, from:"B_left_hand”, to:"B_right_hand”},
{beat:4, duration:3, from:"B_right_hand”, to:"C_left_hand”},
{beat:5, duration:1, from:"B_left_hand”, to:"B_right_hand”},
......
{beat:1, duration:3.75, from:"C_left_hand”, to:"C_right_hand”},
{beat:1.75, duration:2.25, from:"C_right_hand”, to:"B_left_hand”},
{beat:2.5, duration:0.75, from:"C_left_hand”, to:"B_right_hand”},
{beat:3.25, duration:3.75, from:"C_right_hand”, to:"C_left_hand”},
{beat:4.0, duration:2.25, from:"C_left_hand”, to:"C_right_hand”},
{beat:4.75, duration:0.75, from:"C_right_hand”, to:"C_left_hand”}
..... ]

In order to convert the throws of juggler A now correctly to the
fractions one would need to be able to specify the precision somewhere
(to distinguish exact fractions from a floating point value close to a
fraction. This would allow programs wanting to work with exact
fractions to do the conversion without hassle for the programs not
wanting to deal with it). This would be an optional parameter as there
could be programs not wanting to deal with it.

I think if we decide to go to indices instead of strings which was
suggested at some other place we could store it there:

limbs = [{name: "A_left_hand", precision: 0.01},
{name: "A_right_hand", precision: 0.01},
{name: "B_left_hand", precision: 1},
{name: "B_right_hand", precision: 1},
{name: "C_left_hand", precision: 0.01},
{name: "C_right_hand", precision: 0.01}]

I would however suggest to also allow to store an optional scaling
factor there (here called "multiply") and start with 0 indices. Apart
from elegance reasons I would also claim technical reasons for this as
it would make the files smaller:

limbs = [{name: "A_left_hand", precision: 0.01, multiply: 0.67},
{name: "A_right_hand", precision: 0.01, multiply: 0.67},
{name: "B_left_hand", precision: 1},
{name: "B_right_hand", precision: 1},
{name: "C_left_hand", precision: 0.01, multiply: 0.75},
{name: "C_right_hand", precision: 0.01, multiply: 0.75}]

throws = [
{beat:0, duration:3, from:0, to:3},
{beat:1, duration:1, from:1, to:0},
{beat:2, duration:5, from:0, to:1},
.....
{beat:0, duration:3, from:2, to:5},
{beat:1, duration:1, from:3, to:0},
{beat:2, duration:5, from:2, to:3},
{beat:3, duration:3, from:3, to:4},
{beat:4, duration:1, from:2, to:3},
......
{beat:0, duration:5, from:4, to:5},
{beat:1, duration:3, from:5, to:2},
{beat:2, duration:1, from:4, to:3},
{beat:3, duration:5, from:5, to:4},
{beat:4, duration:3, from:4, to:5},
{beat:5, duration:1, from:5, to:4}
..... ]

So I would suggest to introduce two optional (to write) parameters
"precision" and "multiply" in the limb definition. Programs are free to
use or ignore the "precision" parameter as they see fit. If programs
see a "multiply" parameter they should apply it to the values of the
hand it applies to (i.e. "from").

What do you think?

Cheers,
Florian


Am Mon, 26 Oct 2020 13:59:28 +0100
schrieb JaCo Stuifbergen <j.c.stu...@gmail.com>:

[Christian Helbling]

Hi Florian

Having different time scaling factors per limb seems much too complicated for me.

For a throw from hand A to a different hand B time would jump from one time system to another.
Even worse: if we choose to use throw time and catch time instead of throw time and duration
it would not even be obvious which in time scale the catch time is.
All software with jif would need to be able to correctly convert these different time scales and
always know which time scales applies for which value.

Having one timeline is much simpler.
It's still possible to do integer times in polyrhythmic patterns with a global time scaling factor
that is the least common multiple of the different rhythms.
Any pattern using arbitrary fractions can be turned into using only integer times this way.
Thus, the precision parameter is definitely not needed.
Even without any time scaling factor I don't really see the need of specifying precision.


With a global time scale factor, your example with
A) multiply:0.67 (exact: 2/3 = 8/12)
B) multiply:0.75 ( 3/4 = 9/12)
C) multiply:1 (implicit 1 = 12/12)

can be turned into a pattern with global time scale factor 12,
when all times using system A) are multiplied by 8, all B) times multiplied by 9
and all C) times multiplied by 12.

Is that clear enough, or do I need to convert your example to one with a global time scale factor?

Cheers
Christian

[JaCo Stuifbergen]

I agree with Christian that it will be better to use 1 global timescale instead of a different timescale for every juggler.

In the thread "how to write real fractions" Christian proposed to set a parameter "beats per minute".

I think that this can serve as a global time scale.

So if you make the time scale 1800 beats per minute, and juggler C does 2.5 throws per second (150 per minute), C throws every 12 beats.

C's 531 would be noted like

throws = [

{ time:0, duration: 60, to: .... },

{ time:12, duration: 36, to: .... },

{ time:24, duration: 12, to: .... },

...]

And B's 531 would be noted like

throws = [

{ time:0, duration: 45, to: .... },

{ time:9, duration: 27, to: .... },

{ time:18, duration: 9, to: .... },

...]

And A's 531 would be noted like

throws = [

{ time:0, duration: 40, to: .... },

{ time:8, duration: 24, to: .... },

{ time:16, duration: 8, to: .... },

...]

Perhaps, in some situations, you may wish to convert A's 40,24,8 back to 531, so I think that an optional parameter ("personal speed factor" or something like that?) can be useful in some situations. But we should not need that parameter for animations etc.

Co Stuifbergen
=========================
in...@jacos.nl
www.jacos.nl
+31 6 13 02 44 69 (mobile)

Kloosterwei 102
2361 XN  Warmond
the Netherlands
=========================

--
You received this message because you are subscribed to the Google Groups "juggling-interchange-format" group.
To unsubscribe from this group and stop receiving emails from it, send an email to juggling-interchang...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/juggling-interchange-format/d98997fe-9442-425f-5889-f0a32b2e8bb8%40helch.ch.

[Florian Pesth]

Hi Christian,


Am Sun, 1 Nov 2020 10:31:50 +0100
schrieb Christian Helbling <he...@helch.ch>:

> Hi Florian
>
> Having different time scaling factors per limb seems much too
> complicated for me.
>
> For a throw from hand A to a different hand B time would jump from
> one time system to another.

Indeed, I assumed the times would always be notated in the time system
of the throwing hand. An argument could be made, that if we notate the
catch time it should be notated in the targeting time system (Leading
to integer numbers always).

> Even worse: if we choose to use throw
> time and catch time instead of throw time and duration it would not
> even be obvious which in time scale the catch time is. All software
> with jif would need to be able to correctly convert these different
> time scales and always know which time scales applies for which value.
>
> Having one timeline is much simpler.

I agree with your arguments.

> It's still possible to do integer times in polyrhythmic patterns with
> a global time scaling factor that is the least common multiple of the
> different rhythms. Any pattern using arbitrary fractions can be
> turned into using only integer times this way. Thus, the precision
> parameter is definitely not needed. Even without any time scaling
> factor I don't really see the need of specifying precision.
>
>
> With a global time scale factor, your example with
> A) multiply:0.67 (exact: 2/3 = 8/12)
> B) multiply:0.75 ( 3/4 = 9/12)
> C) multiply:1 (implicit 1 = 12/12)
>
> can be turned into a pattern with global time scale factor 12,
> when all times using system A) are multiplied by 8, all B) times
> multiplied by 9 and all C) times multiplied by 12.
>
> Is that clear enough, or do I need to convert your example to one
> with a global time scale factor?

That is clear and reasonable (In fact I used a grid and 8,9,12 steps on
this grid to draw my ladder diagram).

One global time scale seems reasonable for me (to define a "standard
beat time" basically). One should however require than, that all beats
are notated, as is done with the 0 in vanilla siteswap.

I would recommend not mixing this scale factor with an absolute time
scale like BPM. I think this should be a different parameter to allow
being more or less specific about it.

Cheers,
Florian

[Florian Pesth]

Hi Co,

as I wrote on Christians Email I like this suggestion. I would however
keep the factor for converting to absolute timescales (like
BPM) seperate. This way we can still have the 531 notation for every
juggler without having to specify an absolute speed - as far as I
understood you this would be covered by your "speed factors"?

Cheers,
Florian

Am Sun, 1 Nov 2020 12:50:29 +0100
schrieb JaCo Stuifbergen <j.c.stu...@gmail.com>:

[Christian Helbling]

On 02.11.20 20:22, Florian Pesth wrote:
> [..]

>> Having one timeline is much simpler.
> I agree with your arguments.

Good, one thing settled.

> One global time scale seems reasonable for me (to define a "standard
> beat time" basically). One should however require than, that all beats
> are notated, as is done with the 0 in vanilla siteswap.

Why exactly? What would be the use-case that requires that?

Lots of patterns would then be mostly filled with zero throws, I suppose.

Also, I would still not enforce integer times.
It should be possible to drag some throw or catch (or physical throw/catch)
to any point in time in a causal diagram editor (or jif editor in general).
Furthermore, some irrational people might invent patterns with irrational numbers,
where we can at least have an approximate value.
And floating point time was the number one requirement of Wolfgang, creator of Joe Pass :)


That being said, the zero throw is a bit tricky. It is generally to be ignored
by animation software (except if there are some instructions other than that for the
prop throw itself in it). However causal diagrams of siteswaps would draw zero
throws as an arrow back to the last dot of the same hand. This way the diagram keeps
the nice property of having only closed loops.
So there is some kind of need for them.
I ran into this with passist.

I think it should be possible to include zero throws, but they won't have any prop
reference and no physical parameters.
In passist I handled them as a separate pause event, but I think it should be possible
to specify them the same way as other throws but with duration:0 to distinguish them from
actual throws.

> I would recommend not mixing this scale factor with an absolute time
> scale like BPM. I think this should be a different parameter to allow
> being more or less specific about it.

I'd vote for that as well. This way we can have an implicit default for jugglingSpeed
which would define some base juggling time (for example, two handed async juggling).

real time <==jugglingSpeed==> base time <==timeStretchFactor==> jif time

jugglingSpeed would be the physical parameter, timeStretchFactor the logical one

Cheers
Christian

[JaCo Stuifbergen]

 Florian wrote:

One global time scale seems reasonable for me (to define a "standard
beat time" basically). One should however require than, that all beats
are notated, as is done with the 0 in vanilla siteswap.

I would recommend not mixing this scale factor with an absolute time
scale like BPM. I think this should be a different parameter to allow
being more or less specific about it.

Christian wrote:

real time <==jugglingSpeed==> base time <==timeStretchFactor==> jif time

jugglingSpeed would be the physical parameter, timeStretchFactor the logical one

 

Are you agreeing on the same things?

Is jif time the global time, or is base time the global time?

Which of the two is Florian's "standard beat time" ?

And which conversion factor (jugglingSpeed or timeStretchFactor) is Florian's scaling factor?

And I think that Florian has different conversion factors in mind for jugglers at different speeds.

By the way,

I think that we need:

physical time <== BeatsPerMinute ==> logical time

• "logical time" (base time? jif time):
  the times at which a throw starts or ends refers to logical time
• <== BeatsPerMinute ==> (or <==timeStretchFactor==> ?):
  indicates how the logical time is related to the real time, so animators can choose a reasonable speed.
  Normally, a juggler will do between 2 and 3 throws per second
• physical time: the times at which a throw starts or ends, in seconds
  Of course, animating software can show a pattern slower or faster

And I think that in some situations, it is nice to have a conversion to a juggler's individual beats, especially when several jugglers juggle at different speeds.

For exampel, if you have

throws = [

{ time:0, duration: 60, to: .... },

{ time:12, duration: 36, to: .... },

{ time:24, duration: 12, to: .... },

...]

And set individualBeatLength = 12

the pattern can be converted to 531

For a juggler that has

throws = [

{ time:0, duration: 45, to: .... },

{ time:9, duration: 27, to: .... },

{ time:18, duration: 9, to: .... },

...]

individualBeatLength would be 9

Of course, this is an optional parameter !

[JaCo Stuifbergen]

Christian wrote:

Also, I would still not enforce integer times.

I agree!

Florian wrote:

>> Having one timeline is much simpler.

I agree!

>> One global time scale seems reasonable for me (to define a "standard
beat time" basically). One should however require than, that all beats
are notated, as is done with the 0 in vanilla siteswap.

I don't agree here.

In a vanilla siteswap like 3355500333 , we need the zeros to indicate that after 555, the next "3" will be on count 7.

But the zeros would not be required in a notation like:

throws = [

{ time:0, duration: 3, to: .... },

{ time:1, duration: 3, to: .... },

{ time:2, duration: 5, to: .... },

{ time:3, duration: 5, to: .... },

{ time:4, duration: 5, to: .... },

{ time:7, duration: 3, to: .... }, // note that there is no throw at time=5 or time=6

{ time:8, duration: 3, to: .... },

{ time:9, duration: 3, to: .... },

...]

Like Christian remarked, a lot of padding could be required, especially when jugglers have different speeds.

throws = [

{ time:0, duration: 40, to: .... },

       { time:1, duration: 0, to: .... },

       { time:2, duration: 0, to: .... },

       { time:3, duration: 0, to: .... },

       { time:4, duration: 0, to: .... },

       { time:5, duration: 0, to: .... },

       { time:6, duration: 0, to: .... },

       { time:7, duration: 0, to: .... },

{ time:8, duration: 24, to: .... },

       { time:9, duration: 0, to: .... },

      { time:10, duration: 0, to: .... },

       { time:11, duration: 0, to: .... },

       { time:12, duration: 0, to: .... },

      { time:13, duration: 0, to: .... },

       { time:14, duration: 0, to: .... },

       { time:15, duration: 0, to: .... },

{ time:16, duration: 8, to: .... },

...]

I agree that a zero throw cannot have a prop reference.

It might be useful to describe movements of a limb.

[Florian Pesth]

Hi Co, hi Christian,

Am Tue, 3 Nov 2020 12:34:25 +0100
schrieb JaCo Stuifbergen <j.c.stu...@gmail.com>:
>

> > >> One global time scale seems reasonable for me (to define a
> > >> "standard
> > beat time" basically). One should however require than, that all
> > beats are notated, as is done with the 0 in vanilla siteswap.
> >
> I don't agree here.
> In a vanilla siteswap like 3355500333 , we need the zeros to indicate
> that after 555, the next "3" will be on count 7.

Consider the following one hand, two ball pattern:

1)

throws = [
{ time:0, duration: 4, to: 0},
{ time:2, duration: 4, to: 0},
{ time:4, duration: 4, to: 0},
{ time:6, duration: 4, to: 0}
...
]

vs

2)

throws = [
{ time:0, duration: 4, to: 0},
{ time:1, duration: 0, to: 0},
{ time:2, duration: 4, to: 0},
{ time:3, duration: 0, to: 0},
{ time:4, duration: 4, to: 0},
{ time:5, duration: 0, to: 0},
{ time:6, duration: 4, to: 0}
...
]

vs

3)

throws = [
{ time:0, duration: 2, to: 0},
{ time:1, duration: 2, to: 0},
{ time:2, duration: 2, to: 0},
{ time:3, duration: 2, to: 0}
...
]

On the assumption that we only have a global timing scale factor (vs a
scaling factor for each limb) how would you distinguish case 1 (which
should be equivalent to case 2 if you are allowed to not write 0) from
case 3? I would argue you would not be able to tell if the difference
between two throws on that limb is 1 beat or 2 beats (because there may
be other limbs notated which are twice as fast).

Still I would argue that there is a conceptual difference between 4040
and 22 (using one handed vanilla siteswap, so 8080 or 44 in two
handed siteswap). In one case you are saying that there are certain
beats where the hand would be capable to catch a different ball on that
beat and in the other case you say that you don't have (or want) to
receive a ball in between this throws.

This becomes important if you want to merge certain patterns from
different files and figure out if it is a valid combination.

Also I meant writing each throw / non throw on the "throw times" of the
limb (even though you have one global timescale you need to figure out
what is the time difference in beats between two throws on the

particular limb). So for your last example I would still only write:

{ time:0, duration: 40, to: .... },

{ time:8, duration: 24, to: .... },

{ time:16, duration: 8, to: .... },
...]

because the difference between throws for that limb would be 8 beats,
so this are the throws we have to notate.

Cheers,
Florian

[JaCo Stuifbergen]

(I forgot to send a copy to the JIF group)

Florian,

I think that level 2 of JIF should allow to make diagrams like you have made:

In such a diagram, 22 will look identical to 4040 at a double speed.

So in such a diagram, some conceptual differences may be absent.

However, it has the advantage that it can express:

- limbs at different speeds

- unusual rhythms

- changing speed

I agree that it can be nice to restore the original site-swap values, even if jugglers juggle at different speeds.

Fortunately, some parameters can be added for this purpose.

In your example:

throws = [
{ time:0, duration: 4, to: 0},
{ time:2, duration: 4, to: 0},
{ time:4, duration: 4, to: 0},
{ time:6, duration: 4, to: 0}
...
]

If you set individualBeatLength = 2, you must divide all times and duration by 2. So you obtain 2222.

If you set individualBeatLength = 1, you obtain 4040. (In siteswap notation, we must write a number for every count, so we add zeros to mark time=1, time=3 etc.)

Of course, there will be patterns that cannot be restored to a site-swap notation (or at least not to an easy site-swap notation).

I think of some feeding patterns in which some jugglers must slow down or accelerate when the feeder is relayed (changed).

So individualBeatLength should be an optional parameter.

Above, I wrote "it can be nice to restore the original site-swap values,".

But I am aware that "original site-swap values" are part of a higher-level description.

And I think that we have agreed that we don't require that every high-level description  be recovered from JIF's level 2.

(among high-level descriptions are Prechac notation, synchronous site-swaps, take-out notation and every conceivable file format for juggling patterns)

Co Stuifbergen
=========================
in...@jacos.nl
www.jacos.nl
+31 6 13 02 44 69 (mobile)

Kloosterwei 102
2361 XN  Warmond
the Netherlands
=========================