juggling interchange format - goals and first steps

[Christian Helbling]

Hello

Thank you for having interest in developing a standard for interchanging information
about juggling patterns between different software components.

As a first step, I started the following git repository to state the goals,
first steps and in the future drafts and versions of the standard:

https://github.com/helbling/jif

Cheers
Christian

[Florian Pesth]

Hello everyone,

thanks for the starting document, Christian, this is already very
interesting and a promising start. I'd like to share some ideas
- and I noticed Jaco has made a pull request for some changes to the
document (has Jaco joined this list?).

What would be the preferred way to interact? Of course the programmers
here familiar with github (which are maybe the majority on this list)
can easily make pull requests for changes on the document and discuss
the changes on the respective page on github but this would put the
discussion sort of between Christian and the one doing the pull request
and on github.

Maybe this discussion should take place on the mailing list first and
after a consensus is reached the person initiating the discussion could
make a pull request?

Cheers,
Florian

Am Sat, 10 Oct 2020 13:10:53 +0200
schrieb Christian Helbling <he...@helch.ch>:

[Christian Helbling]

Hi Florian

On 10.10.20 13:48, Florian Pesth wrote:
> Hello everyone,
>
> thanks for the starting document, Christian, this is already very
> interesting and a promising start. I'd like to share some ideas

Great!

> - and I noticed Jaco has made a pull request for some changes to the
> document (has Jaco joined this list?).

Yes, I still have to review that one :)

> What would be the preferred way to interact? Of course the programmer> here familiar with github (which are maybe the majority on this list)> can easily make pull requests for changes on the document and discuss> the

changes on the respective page on github but this would put the> discussion sort of between Christian and the one doing the pull request> and on github.
> Maybe this discussion should take place on the mailing list first and
> after a consensus is reached the person initiating the discussion could
> make a pull request?

Yes, I agree that this should be the preferred way. It's definitely simpler
for me that way.

I think we can still use github issues to discuss particular details and/or problems.

> Cheers,
> Florian

Cheers
Christian

[JaCo Stuifbergen]

Hello all, I am just confirming that I am on the list!
(thanks Swisstian)

[Adrian Goldwaser]

Hi all,

Some thoughts I've had in response to what Swisstian put on Github.

Metadata: my understanding is that these are things that don't affect the pattern? E.g. comment is irrelevant, number of objects can be inferred from the rest of the pattern, etc. If so this seems easy to just list the important things and we can always add anything we miss.

Logical throws: I think once we add to/from juggler then that's enough here (my (WIP) causal editor only uses time/height/hand/toHand/juggler/toJuggler)

Physical throws:  

- I don't think animation data should override throw time - a causal diagram (i.e. 'logical throws') should show the actual throw time IMO, animators shouldn't need to change that, modifying catch time is enough

- I agree about the rest (and there are a *lot* of potential other things here, some of which are their own rabbit holes, e.g. rotation [1,2] or bouncing, we should really work out the important ones which we can't do without)

Uncategorised:

• manipulation/movement during dwell: I think we can just say movement here, and if we want we can have something like isCarry=true so the manipulations can be extracted back out/given sensible defaults by simulators (this is a property on the throw event though, not the dwell time). Movement is a bit awkward to define, I'm not quite sure what movement you're imagining here? Flourishes? Defining an exact path for the hand to take during the dwell time by giving a time parameterisation of x/y/z positions? A set of position/time pairs it must satisfy?
• mapping hand reference to juggler and side: no idea what this is
• juggler positions and movements: I think we could have some kind of events list with throw events, movement events and anything else we come up with that we need (colour changes of props? music?)
• hand movements while not carrying an object: same points as hand movement while holding an object
• movements of other body parts: ditto, is a set of events saying "at time t the leg should be in position z/orientation y" enough? Because that format should give reasonable results for most movement things (hands, jugglers, other limbs) it's only if we want more detailed movements that things get complex.
• length of a time unit in seconds: is this just beats per second? I think our time should be defined as (fractions of) beats, this means throw heights correspond nicely to (2 handed) siteswaps so should make things simple in the majority of cases.

Further considerations

• Generalising hands: can we have 'LH'/'RH' as strings for the hands in the events, e.g. juggler=0, manipulator=LH, then we can do something like juggler=1, manipulator=right_knee or something to extend it if needed, jugglers can be defined as inanimate objects with other things to manipulate with if needed too
• 'repetition might be considered a feature': being able to not repeat things seems useful, but maybe the default should be for things to repeat (as that's the majority case and we want things simple when needed)
• "we might want to have some kind of object relabeling mechanism to shorten the period / file length as it might take quite long until all objects are in their starting positions again at the start of an iteration" I think this is really important, JML has a few different types of symmetries which it defines, the types are delay, switch and switchdelay (I'm not quite sure what the difference is), each can define a delay, a juggler permutation and a 'path' (i.e. prop) permutation (honestly it's likely some subset of those based on what the code looks like it outputs, but it seems to accept all options for all of them in the parsing at least).

<symmetry type="delay" pperm="(1)(2)(3)" delay="1.3714"/> - I think this might just be saying that the pattern repeats? Not sure I understand it otherwise
<symmetry type="switchdelay" jperm="(1,1*)" pperm="(1,2)(3)"/> - Juggler 1s hands swap, props 1/2 swap and 3 stays the same.

Do we want to split throws/catches as separate events? Again, it's something that JML does but I'm not sure why it has it that way, it would make simple cases more complex but may help with more complex cases?

Other pattern definition links that might be useful:

- JML (JugglingLab): https://jugglinglab.org/html/jml.html, https://github.com/jkboyce/jugglinglab/tree/master/source/jugglinglab/jml

- Gunswap (much higher level, not sure if there's an internal one too): http://www.gunswap.co/about/syntax

[1] https://m.box.com/shared_item/https%3A%2F%2Fapp.box.com%2Fs%2F2azk2z9hjtlryvmiclhp

[2] https://juggle.fandom.com/wiki/Rotation_notation

Cheers,

Adrian

--
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/03ea6886-fb30-4359-a659-e01ae391b753n%40googlegroups.com.

[Florian Pesth]

>--
>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/f648db1d-383c-7ecb-cee1-94463eb71d42%40helch.ch.

Hello everyone,

first of, I think we should aim for a format that is expressive enough to be able to be converted to all currently known juggling notation systems, also the weirder ones.

It should also solve more exotic problems to be future proof.

I have some thoughts on body movement as well but will write a separate mail about this later.

Long version below, short version of my suggestions here:

1. Use one handed sideswap numbers (as transitions between states) and notate throws with the position (f.e. hand) and the number of beats it lands at - this allows arbitrary number of hands and both synchronous / asynchronous patterns and transitions between them
2. Also notate he state before and after each throw locally for the position (hand). Allow numbers greater than one in states to allow for multiplexes.
3. Group positions (hands) with the same beat together, if there are multiple "beat groups" define the ratio between them starting from the second ( to the first or by named reference) and the delay between them - this allows for polyrythmic patterns.
4. Exact throw times, object type, object color, flight path, etc. and renaming of props could be optional information to put in the throw field


## One handed sideswaps

One problem which "vanilla" siteswap solves is the lets call it - for the lack of a better word - "impermeability of props" i.e. it is assumed that there can be only one object at a time at the same position in space and that there should be only one object at the defined positions (i.e. hands but could be anything) at regular intervals of time.

Vanilla siteswap also assumes that you describe two hands which throw alternating (asynchronous) at regular time intervalls.

Vanilla siteswap has been extended to include synchronous throws (which lifts the restriction of alternating hands), multiplexes (which lifts the restriction of allowing only one object in the hand) and four hands (assuming again alternating throws now between four hands) but this extensions have been critizised for being clumsy and loosing the elegance of vanilla siteswap.

There have been at least two attempts to fix this by noting where each throw goes (Luke Burrage beatmap notation comes to mind but there has also been some computer format which used rows for each throws - I don't remember the name right now - anyone?).

Also the standard passing notation does something similar for the passes.

## Juggling states (with multiplex extension)

In the commen passing programs like Christians passist and Tillmans Siteswap Generator the number of clubs in each hand for the start of the pattern is notated - which I think we all can agree is usefull. I thin in general keeping track of the juggling state is usefull as it gives us an "interface" where we can see which patterns would match. I suggest also extending the usual 10 notation with higher numbers. If you think about the state as the sounds you hear when not catching any more objects at this time at this hand (the state would be local to the catching position as well) a two would simply mean you hear the sound of two objects hitting the floor at the same time.

## Polyrythmic patterns

There has not been much progress on the written notation of polyrythmic siteswaps. I think this is also something we should consider. We can have multiple beat times and if we define the speed ratio and the delay between them (in terms of one beat group) and then associate each position (hand) with a beat group we should have the pattern defined without giving weird absolute timestamps. Throws should maybe noted as floating point value in the beatgroup they are thrown from - as is common in passing notation to note a 3.5 for example.

Cheers,
Florian

[Florian Pesth]

Sorry Adrian,

wanted to send my reply to the list.


Von: Florian Pesth
Gesendet: 14. Oktober 2020 20:15:19 MESZ
An: Adrian Goldwaser
Betreff: Re: juggling interchange format - goals and first steps

Hello Adrian,

Am 14. Oktober 2020 15:10:59 MESZ schrieb Adrian Goldwaser:
>Hi all,
>
>Some thoughts I've had in response to what Swisstian put on Github.
>

>*Metadata*: my understanding is that these are things that don't affect

>the
>pattern? E.g. comment is irrelevant, number of objects can be inferred
>from
>the rest of the pattern, etc. If so this seems easy to just list the
>important things and we can always add anything we miss.

I think we should include the possibility of a changing the number of objects to be able to describe stuff like Victor Kees ball drop mechanism and him throwing balls of the stage (just as an example - also clay juggling comes to mind where the number of objects may change during the act).

>
>*Logical throws*: I think once we add to/from juggler then that's

>enough
>here (my (WIP) causal editor only uses
>time/height/hand/toHand/juggler/toJuggler)

Agree, to / from and number of beats (equivalent to height usually) should be enough.

>
>*Physical throws*:

>- I don't think animation data should override throw time - a causal
>diagram (i.e. 'logical throws') should show the actual throw time IMO,
>animators shouldn't need to change that, modifying catch time is enough

Could you elaborate a bit on that? Timing data as optional additional data on top of "beats"?

>- I agree about the rest (and there are a *lot* of potential other
>things
>here, some of which are their own rabbit holes, e.g. rotation [1,2] or
>bouncing, we should really work out the important ones which we can't
>do
>without)

I would say bouncing is just a type of throw which takes a certain number of beats.

>
>*Uncategorised*:
>
> - manipulation/movement during dwell: I think we can just say movement

> here, and if we want we can have something like isCarry=true so the
> manipulations can be extracted back out/given sensible defaults by
>simulators (this is a property on the throw event though, not the dwell
> time).

I would be careful defining any keywords. It can be a descriptive metadata... in siteswap terms it is just a 2 (or 1 in one handed siteswap).

Movement is a bit awkward to define, I'm not quite sure what
>movement you're imagining here?

I think there should be a way to describe body movement.

Flourishes? Defining an exact path for
>the
>hand to take during the dwell time by giving a time parameterisation of
> x/y/z positions? A set of position/time pairs it must satisfy?

I think this could be covered by some variant of the Eshkol Wachman movement notation as detailed as one wants to go into. I will write a bit about that in a separate mail.

> - mapping hand reference to juggler and side: no idea what this is

A hand position can be shared between two jugglers for example if thwy stand next to each other and do a partner pattern. Might be useful to relabel hands in this case.

> - juggler positions and movements: I think we could have some kind of

>events list with throw events, movement events and anything else we
>come up
> with that we need (colour changes of props? music?)

Yes I think this could be event based, just like throws.

> - hand movements while not carrying an object: same points as hand

> movement while holding an object

> - movements of other body parts: ditto, is a set of events saying "at

>time t the leg should be in position z/orientation y" enough? Because
>that
> format should give reasonable results for most movement things (hands,
>jugglers, other limbs) it's only if we want more detailed movements
>that
> things get complex.

For this Eshkol wachman seems nice.
Pp
> - length of a time unit in seconds: is this just beats per second? I

>think our time should be defined as (fractions of) beats, this means
>throw
>heights correspond nicely to (2 handed) siteswaps so should make things
> simple in the majority of cases.
>

>*Further considerations*
>
>- Generalising hands: can we have 'LH'/'RH' as strings for the hands in

>the events, e.g. juggler=0, manipulator=LH, then we can do something
>like
> juggler=1, manipulator=right_knee or something to extend it if needed,

I would keep names to be defined by the user - we can still cross reference them.

> jugglers can be defined as inanimate objects with other things to
> manipulate with if needed too

Good idea. We might even give (optionally) Bezier pathes between positions.

> - 'repetition might be considered a feature': being able to not repeat

>things seems useful, but maybe the default should be for things to
>repeat
> (as that's the majority case and we want things simple when needed)

> - "we might want to have some kind of object relabeling mechanism to

> shorten the period / file length as it might take quite long until all
>objects are in their starting positions again at the start of an
>iteration"

> I think this is *really* important, JML has a few different types of

> symmetries which it defines, the types are delay, switch and
>switchdelay (I'm not quite sure what the difference is), each can
>define a
>delay, a juggler permutation and a 'path' (i.e. prop) permutation
>(honestly
> it's likely some subset of those based on what the code looks like it
>outputs, but it seems to accept all options for all of them in the
>parsing
> at least).
>
><symmetry type="delay" pperm="(1)(2)(3)" delay="1.3714"/> - I think
>this
>might just be saying that the pattern repeats? Not sure I understand it
>otherwise
><symmetry type="switchdelay" jperm="(1,1*)" pperm="(1,2)(3)"/> -
>Juggler 1s
>hands swap, props 1/2 swap and 3 stays the same.
>
>Do we want to split throws/catches as separate events? Again, it's
>something that JML does but I'm not sure why it has it that way, it
>would
>make simple cases more complex but may help with more complex cases?

It could be optional information as both are bound the same beat.

>
>Other pattern definition links that might be useful:
>- JML (JugglingLab): https://jugglinglab.org/html/jml.html,
>https://github.com/jkboyce/jugglinglab/tree/master/source/jugglinglab/jml
>- Gunswap (much higher level, not sure if there's an internal one too):
>http://www.gunswap.co/about/syntax
>
>[1]
>https://m.box.com/shared_item/https%3A%2F%2Fapp.box.com%2Fs%2F2azk2z9hjtlryvmiclhp
>[2] https://juggle.fandom.com/wiki/Rotation_notation
>
>Cheers,
>Adrian
>

Cheers,
Florian

>
>On Sun, Oct 11, 2020 at 7:35 AM JaCo Stuifbergen
><j.c.stu...@gmail.com>
>wrote:
>
>> Hello all, I am just confirming that I am on the list!
>> (thanks Swisstian)
>>
>> On Saturday, 10 October 2020 at 18:26:25 UTC+2 Christian Helbling
>wrote:
>>

>https://groups.google.com/d/msgid/juggling-interchange-format/03ea6886-fb30-4359-a659-e01ae391b753n%40googlegroups.com
>>
><https://groups.google.com/d/msgid/juggling-interchange-format/03ea6886-fb30-4359-a659-e01ae391b753n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .

>>
>
>--
>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/CAPORLgHauExj2snqCQVXtak37Z4pEOcHxo1CE4dVKG-G825eaA%40mail.gmail.com.

[JaCo Stuifbergen]

Adrian and Florian, each of you addresses some interesting topics.

I will reply first to Adrian’s mail, then to Florian’s

(and I will save 1 subject for a separate e-mail)

Co Stuifbergen

On Wed, 14 Oct 2020 at 15:11, Adrian Goldwaser <ad.gol...@gmail.com> wrote:

Hi all,

Some thoughts I've had in response to what Swisstian put on Github.

Metadata: my understanding is that these are things that don't affect the pattern? E.g. comment is irrelevant, number of objects can be inferred from the rest of the pattern, etc. If so this seems easy to just list the important things and we can always add anything we miss.

I also think that the meta-data don't affect the pattern, but they may be useful. For example, stating that a pattern was generated (and can be read) by this or that program, or conforms to JIF version x.0, or does/doesn't use advanced options (e.g. if the software needs to flip 2-coloured rings to show some desired effect).

I think that if a pattern has a name (or is known under several names), this will be very helpful to many jugglers.

And of course, lots of information may be added later (inventor, link to a video, copyright :-( ....

).

Logical throws: I think once we add to/from juggler then that's enough here (my (WIP) causal editor only uses time/height/hand/toHand/juggler/toJuggler)

I agree. (in theory, we cannot specify the hand without specifying the juggler)

By the way, the "hand" could also be a foot, head, shoulder, elbow, armpit etcetera.

Physical throws:  

- I don't think animation data should override throw time - a causal diagram (i.e. 'logical throws') should show the actual throw time IMO, animators shouldn't need to change that, modifying catch time is enough

I will react to this in another e-mail

- I agree about the rest (and there are a *lot* of potential other things here, some of which are their own rabbit holes, e.g. rotation [1,2] or bouncing, we should really work out the important ones which we can't do without)

Uncategorised:

• manipulation/movement during dwell: I think we can just say movement here, and if we want we can have something like isCarry=true so the manipulations can be extracted back out/given sensible defaults by simulators (this is a property on the throw event though, not the dwell time). Movement is a bit awkward to define, I'm not quite sure what movement you're imagining here? Flourishes? Defining an exact path for the hand to take during the dwell time by giving a time parameterisation of x/y/z positions? A set of position/time pairs it must satisfy?

• mapping hand reference to juggler and side: no idea what this is
  

• good remark, I also wonder.
  

• juggler positions and movements: I think we could have some kind of events list with throw events, movement events and anything else we come up with that we need (colour changes of props? music?)

• hand movements while not carrying an object: same points as hand movement while holding an object

• movements of other body parts: ditto, is a set of events saying "at time t the leg should be in position z/orientation y" enough? Because that format should give reasonable results for most movement things (hands, jugglers, other limbs) it's only if we want more detailed movements that things get complex.

• length of a time unit in seconds: is this just beats per second? I think our time should be defined as (fractions of) beats, this means throw heights correspond nicely to (2 handed) siteswaps so should make things simple in the majority of cases.
  

• beats per second = 1 / (time unit)
  I think that this should be optional, but if some pattern designer wants to set a recommended speed, I have no objection.
  

"Uncategorized" are in my opinion features that may need a specification later.

)

 

Further considerations

• Generalising hands: can we have 'LH'/'RH' as strings for the hands in the events, e.g. juggler=0, manipulator=LH, then we can do something like juggler=1, manipulator=right_knee or something to extend it if needed, jugglers can be defined as inanimate objects with other things to manipulate with if needed too
  good idea! just make some consistent terms, like LHand, RHand,  LKnee, RKnee, LShoulder, RShoulder.
  (The word "manipulator" also has a different meaning in some patterns (it refers to a juggler), so I hope that we can find another word that expresses "hand, foot, shoulder etc". Would "limb" be OK?)
  

• 'repetition might be considered a feature': being able to not repeat things seems useful, but maybe the default should be for things to repeat (as that's the majority case and we want things simple when needed)
  

• It will be easy to add "repeatable=FALSE", if needed.
  
• "we might want to have some kind of object relabeling mechanism to shorten the period / file length as it might take quite long until all objects are in their starting positions again at the start of an iteration" I think this is really important, JML has a few different types of symmetries which it defines, the types are delay, switch and switchdelay (I'm not quite sure what the difference is), each can define a delay, a juggler permutation and a 'path' (i.e. prop) permutation (honestly it's likely some subset of those based on what the code looks like it outputs, but it seems to accept all options for all of them in the parsing at least).
  I also think that this is really important.
  I am not very worried about file length, but if someone wants to connect patterns, it is important to make the building blocks as short as possible
  

<symmetry type="delay" pperm="(1)(2)(3)" delay="1.3714"/> - I think this might just be saying that the pattern repeats? Not sure I understand it otherwise

"delay": I don't know it. 1.3714 is a weird number, because it is 48/35

<symmetry type="switchdelay" jperm="(1,1*)" pperm="(1,2)(3)"/> - Juggler 1s hands swap, props 1/2 swap and 3 stays the same.

Do we want to split throws/catches as separate events? Again, it's something that JML does but I'm not sure why it has it that way, it would make simple cases more complex but may help with more complex cases?

I will react to this in another e-mail

Other pattern definition links that might be useful:

- JML (JugglingLab): https://jugglinglab.org/html/jml.html, https://github.com/jkboyce/jugglinglab/tree/master/source/jugglinglab/jml

- Gunswap (much higher level, not sure if there's an internal one too): http://www.gunswap.co/about/syntax

[1] https://m.box.com/shared_item/https%3A%2F%2Fapp.box.com%2Fs%2F2azk2z9hjtlryvmiclhp

[2] https://juggle.fandom.com/wiki/Rotation_notation

Cheers,

Adrian

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

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

[JaCo Stuifbergen]

## siteswaps

The evolution of site-swap notation (from vanilla to synchronous, multiplex and fractional notation), there is a conflict between simplicity of notation and the desire to describe more patterns.

It would be nice if JIF supports an elegant notation for easy patterns, and more complex notations for patterns that need a more complex notation.

That should include multiplex throws (and catches, probably) and every possible timing: not only poly-rhythms, but also patterns that require a rhythm change.

(In Bruno's nightmare for 10 clubs, the passes have siteswap value 4.5, so when a feedee walks to the other side, he/she has to shift half a count (e.g. 4 throws in 3.5 beats)

I hope to give a sketch of a proposal tomorrow.

It will not be difficult to add parameters for hand movement, prop colors, etc. later.

## Juggling states (with multiplex extension)

I think that the begin and end state can be derived from the throws (also for multiplexes), so I think that the states should not be required.

## Polyrythmic patterns

I like them!

My proposal will contain a notation for them.

Greetings,

Co Stuifbergen

[Adrian Goldwaser]

Hi Florian/Co,

[quick note because you both had issues with my naming, I'm just naming things whatever I feel like for now because it's more important to work out the structure at the moment than spend time finding the perfect name, we can debate that once we have a draft]

Co - I think we mostly agree except for some miscommunications

Responses to Florian's emails:

RE your suggestion, I mostly agree with Co's comments on it so won't write them out again, specifically we can easily extract state information if needed and if things are based off exact timing then we don't need to special case anything like polyrhythms - it just naturally supports it. 

> I think we should include the possibility of a changing the number of objects to be able to describe stuff like Victor Kees ball drop mechanism and him throwing balls of the stage (just as an example - also clay juggling comes to mind where the number of objects may change during the act).

I claim in Victor Kee's case this is still a fixed number of props (some just get thrown to the floor/out of sight for parts). In the case of clay juggling (I assume this means I can mold two balls together to form a larger one), I think it's niche enough and complicates things enough that it shouldn't be supported - I don't think any simulators will support it and if need be people can work around it (e.g.. an event to change a ball colour to transparent and another to increase the size of a ball).

> Could you elaborate a bit on that? Timing data as optional additional data on top of "beats"?

You need extra timing data to deal with dwell times. Maybe we're using different terms here so it's getting confusing, let me give a simple example (I'm assuming one time unit = 1 beat because it makes everything much more readable):

Time 0: RH throws a 3 [thrown again 3 beats later] to LH

Time 1: LH throws a 3 to RHTime 2: RH throws a 3 to LH

Time 3: LH throws a 3 to RH

...

This gives what we'd need for a causal, but in order to animate it, we need to know when the balls are caught more precisely, otherwise the first ball spends 0 time in the hand (of course simulators can have a sensible default if not set but we need the control for some patterns), so we'd end up with something like:

Time 0: RH throws a 3 to LH, caught at time 2

Time 1: LH throws a 3 to RH, caught at time 3

Time 2: RH throws a 3 to LH, caught at time 4

...

Now the first ball has a beat to spend in the LH before being thrown again.
Pretty much if we do it this way (especially if we set 1 time unit = 1 beat), then anything that can be written in siteswap ends up really simple in JIF still and it's only more complex things that become more complex in JIF.

> I would say bouncing is just a type of throw which takes a certain number of beats.

This is a lot more complex than it sounds, similarly to rotations. With bounce we have number of bounces, how it's throws (passive/active), when in its motion it's caught (going up or down), how it's caught (passive/active), whether it has spin, what surfaces it bounces off, bounce coefficient of the ball, orientation at bounce (for clubs), etc. etc. JugglingLab limits this to lift/force/hyperlift/hyperforce and a number of bounces, Gunswap extends it to multiple surfaces. However we can probably leave out a lot of the details there for now and add them in at a later revision. Possibly I misunderstood and you just meant that it's all orthogonal data that can be specified later (in which case I agree)

> I would be careful defining any keywords. It can be a descriptive metadata... in siteswap terms it is just a 2 (or 1 in one handed siteswap).

Sure, that's exactly what I meant it was, you still have the throw defined as normal, but there's a tag there that things that know/care about manipulators can use to extract out what the manipulations are.

> I think this could be covered by some variant of the Eshkol Wachman movement notation as detailed as one wants to go into. I will write a bit about that in a separate mail.

Hadn't heard of that before (thanks for mentioning it!), seems like a simplified version of it might work (we don't need all the movement types and I'm still not sure what some of the parts of it are), however it doesn't solve the interpolation problem in all cases unless I'm misunderstanding (very possible - I couldn't find good descriptions of it).

> A hand position can be shared between two jugglers for example if thwy stand next to each other and do a partner pattern. Might be useful to relabel hands in this case.

Hand positions are different to hands, hand positions are notated in the throw/catch/movement events. Hands (I hope) stay with the same juggler... Relabelling hands won't actually help notate patterns like that more simply.

Rereading Christian's writeup, I think maybe the idea he had was to assign a number for each hand/limb and then separately map these to juggler hands/limbs (would also explain why there was no 'from/to juggler' in the logical throw.

> > Do we want to split throws/catches as separate events? Again, it's something that JML does but I'm not sure why it has it that way, it would make simple cases more complex but may help with more complex cases?

> It could be optional information as both are bound the same beat.

Not sure I understand this? To illustrate, the two options are (first is how JML does it, second is how we were originally thinking of doing for JIF because it's simpler for simple patterns, I'm just not sure if it's going to complicate things later):

Time 0: RH throws prop 0

Time 2: LH catches prop 0

Time 3: LH throws prop 0

Time 5: RH catches prop 0

Vs

Time 0: RH throws a 3 to LH, caught at time 2

Time 3: LH throws a 3 to RH, caught at time 5

Also as an extra thing, do we want to support balances (club-on-club or club-on-limb) or club-on-club hits? If we allow props to be the 'limb' is that enough to notate this? We have prop location and prop/limb orientation already which (I think) is enough for a head balance, if we allow the 'limb' to be a prop then maybe that's enough to do club hits (location/orientation of both props and a short dwell time catch) or balances.

Cheers,

Adrian

--
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/744f2f1a-cf51-4905-994b-5131a8d758fan%40googlegroups.com.

[JaCo Stuifbergen]

Some comments:

adding / removing objects

(picking up / throwing away objects)
In a causal diagram, this can simply be a line (I prefer the word "chain") that enters the diagram from the outside, or leaves.

One might also consider the floor as a juggler (with 1 hand perhaps?) that can hold a big multiplex.

Clay juggling:

I suppose that this means things like splitting a ball in two, or merging to balls into 1 ball.

This is like adding/removing an object, with special instructions for the physical rendering.

bouncing:

I think that from the site-swap value and the dwell time, an animator can calculate an trajectory, with the desired number of bounces (if the "flight duration" is big enough). lift/hyperlift/force/hyperforce is, for animations, useful information.

It is relevant for the physical throw, not for the causal diagram.

Above, I wrote that a floor can be considered like a hand. But a floor or a wall cannot make the throw independent of the catch,  so for bouncing, they should not be considered hands, but physical constraints

hands vs jugglers

In some situations, I am tempted to describe a pattern by hand in stead of by juggler.

E.g. for poly-rhythms, or if there are many synchronous throws.

But for a computer, the conversion will not be very difficult.

club-on-club

I would consider a balance as a multiplex, with instructions for the physical rendering.

When clubs bounce on each other in the air, I would add instructions for the physical rendering (e.g. trajectory, spins before/after the collision) but it should not require a change in the causal diagram.

If a club or ball is bounced on a club that is held, we may have to set the dwell time (=hold time) very low.

[Christian Helbling]

On 15.10.20 12:50, Adrian Goldwaser wrote:
> [..]

> Rereading Christian's writeup, I think maybe the idea he had was to assign a number for each hand/limb and then separately map these to juggler
> hands/limbs (would also explain why there was no 'from/to juggler' in the logical throw.
>

Yes, that's correct. Sorry for not writing that out more clearly.
In my experience it's handy to have zero-based integers as a reference for things.
This way we have the possibility to add more properties to jugglers and hands/limbs
whenever we want to, without having to change some cryptic short string notation.

Something like this for example (naming to be discussed of course):

{
jugglers: [
{ name: 'Alice' },
{ name: 'Bob' }
],
limbs: [
{ juggler: 0, side:0, limb:"hand"},
{ juggler: 1, side:0, limb:"hand"},
{ juggler: 0, side:1, limb:"hand"},
{ juggler: 1, side:1, limb:"hand"}
],
props: [
{ type:'ball', color:'#00ff00'},
{ type:'club', color:'#ff0000'},
{ type:'ring', color:'#ffffff'},
...
],
throws:
{ time:0, duration:10, fromLimb:0, toLimb:2, prop:0, label:"a" },
{ time:1, duration:7, fromLimb:1, toLimb:0, prop:1, label:"7" },
{ time:2, duration:7, fromLimb:2, toLimb:1, prop:2, label:"7" },
...
],
...
}

And yes, I very much like not to restrict myself to hands.
It is okay for a first draft but it should be easily extendible to
allow other body parts and even other things like the floor (drops, pickups), a table,
the void (for objects that vanish or appear out of nothing) and so on.

This calls for an even more general name than "limbs"..
I'm thinking of everything that can hold/store props. Is that general enough?
Any good name for it?

> Also as an extra thing, do we want to support balances (club-on-club or club-on-limb) or club-on-club hits? If we allow props to be the 'limb' is that
> enough to notate this? We have prop location and prop/limb orientation already which (I think) is enough for a head balance, if we allow the 'limb' to
> be a prop then maybe that's enough to do club hits (location/orientation of both props and a short dwell time catch) or balances.

Interesting thought. My proposal would allow such an extension:
limbs: [ { prop:3 }, ..]
Would make fun things like sticking props to each other possible :)

But it's a bit too advanced for the first version in my taste.

Cheers
Christian

[Adrian Goldwaser]

Yep, I think I agree here - it makes the simpler cases a bit more complex but I think that's fine because it'll help with keeping extensions cleaner.

>    { juggler: 0, side:1, limb:"hand"},

I don't particularly like having a 'side' here, I think I'd prefer RHand/LHand that way we don't need to special case things where there's only 1 of, or define what sides mean for every limb, especially in cases of inanimate objects that aren't as obvious... E.g. I'd prefer to just have "table-leg-1" etc. (especially helpful if the table isn't symmetrical)

> I'm thinking of everything that can hold/store props. Is that general enough?

That seems general enough, unless we want to define limbs specifically for movement events? But I can't think of anything you can move that you couldn't theoretically also use to manipulate a prop (maybe hold/store is a bit too specific and should be manipulate to account for taps/pushes with limbs that may not be able to hold it, but that's just being pedantic at that point)

> Any good name for it?

Yeah that's the hard part... Manipulator is the right meaning except that we already have a meaning for it. I don't have a good name really, the best I can think of is 'handler' or 'controller' but they don't quite fit really...

> But it's a bit too advanced for the first version in my taste.

If we do it that way then yes we can leave it out of the first version - the main thing I want to be sure about is that we're not locking ourselves into an awkward way of doing certain extensions so I think it's worth at least having a cursory think about more advanced uses to make sure there are reasonable ways without having to redesign anything (I think in the case of this one, either Co's suggestion of having it as a multiplex and including more info about how things are held or having props as manipulators should both work without massively changing the spec to handle them, but we should keep it in mind when thinking about talking about prop orientation/motion when held).

Another similar example is rolls (on the floor, across arms/shoulders, over head, etc), which probably fits in fine if we can define positions within a limb and orientation of the prop during a hold but maybe it would mean we should be thinking about limbs differently to make the extension easier.

--
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/d5b0359b-a820-47a1-f9db-02751d8f23da%40helch.ch.

[JaCo Stuifbergen]

> I think I'd prefer RHand/LHand

compromise suggestion:

  { juggler: 0, side:0, limb:"LeftHand"},
  { juggler: 0, side:1, limb:"RightHand"},

Actually, I don't know what is best. I prefer "LHand" and "RHand" etc. over 0 and 1, but I don't have Christians programming experience.

> Any good name for it?

manipulator, handler, controller suggest a very active role, also when the limb is mainly holding the object.

"socket" comes to my mind.

> the main thing I want to be sure about is that we're not locking ourselves into an awkward way of doing certain extensions so I think it's worth at least having a cursory think

I agree.

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/juggling-interchange-format/CAPORLgEnmOagwrQ1mf4P_edNVcZ5azpdMEmu9RZBgzUPTpapmg%40mail.gmail.com.

[JaCo Stuifbergen]

First a technical comment:

I hope that you receive this e-mail. This discussion does not appear on the web-site of the group

https://groups.google.com/g/juggling-interchange-format

Graham, you have a good question.

I think that JIF doesn't have to specify a maximum.

Programs that want to check the validity can set a maximum (say, 1000) and test the pattern.

Or should we require that the patterns in JIF are valid ?

I can imagine that the pattern generator and pattern validator are separate programs, that exchange information using JIF.

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

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

---------- Forwarded message ---------
From: Graham Haslehurst <g.p.has...@gmail.com>
Date: Sun, 18 Oct 2020 at 21:06
Subject: Re: hand references
To: JaCo Stuifbergen <j.c.stu...@gmail.com>

If you are considering multiplexing or clay objects is there a requirement to state maximum capacity for the catching "hand" e.g. 1, 2, infinite? It might help ensure pattern validity and prevent the situation where clubs are magically disappearing and reappearing and the user has no idea why without huge inspection of their pattern. 

Thanks

Graham

To view this discussion on the web visit https://groups.google.com/d/msgid/juggling-interchange-format/CAKHXiF%2BUYZZ5%2Bzc_KHKsSoUytrD1n30ACVcb5HAoLbnwYVas%2BA%40mail.gmail.com.

[Christian Helbling]

On 2020-10-19 11:44, JaCo Stuifbergen wrote:
> First a technical comment:
> I hope that you receive this e-mail. This discussion does not appear on the web-site of the group
> https://groups.google.com/g/juggling-interchange-format

Most of the mails are hidden in one thread:
https://groups.google.com/g/juggling-interchange-format/c/Gv17W3s5u9o

I haven't found a nice thread view yet..

We might need to start new threads for specific topics by writing a new mail to the list instead of always replying
to someone.

> Graham, you have a good question.
>
> I think that JIF doesn't have to specify a maximum.
> Programs that want to check the validity can set a maximum (say, 1000) and test the pattern.

I agree.
The format could still easily be extended to have a global maximum and by-hand maxima,
but I don't think its important enough for an initial version.

> Or should we require that the patterns in JIF are valid ?

In my opinion we should allow invalid/incomplete patterns. For example this would allow a causal diagram editor to save partial
editing state.
Applications can decide what to do in this case. They might chose to reject invalid/incomplete patterns if they wish.
Or do funny and interesting things.

Also: if a pattern is valid might depend on assumptions that could change with other interpretations. For example:
is multiplex allowed? is the pattern physically possible? can a prop move backwards in time by some weird interpretation?

-Christian

[JaCo Stuifbergen]

Technical note:

The subject header of this message is "hand references".

I am sending this message to juggling-inte...@googlegroups.com only.
From experience, we know that on https://groups.google.com/g/juggling-interchange-format/c/Gv17W3s5u9o ,

it is added to a thread with a differen subject.

I suspect that Google checks which message is attached below.

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/428bb8aa-2439-3788-718f-16c62796c8a8%40helch.ch.

[Christian Helbling]

On 18.10.20 20:44, JaCo Stuifbergen wrote:
>> I think I'd prefer RHand/LHand
> compromise suggestion:
>   { juggler: 0, side:0, limb:"LeftHand"},
>   { juggler: 0, side:1, limb:"RightHand"},
> Actually, I don't know what is best. I prefer "LHand" and "RHand" etc. over 0 and 1, but I don't have Christians programming experience.

In my animation code I need to have an integer side value.
However, that is an implementation detail which does not necessarily need to be in the format.

Just having one string is reasonable and okay for me.

We should specify strings for the most commonly used values, so that when people start using the format they use the same values.
I would not use something cryptic there.
I'd suggest using:
"right hand", "left hand", "right foot", "left foot", "forehead", "nose", "chin", "right knee", "left knee", "right shoulder", "left shoulder"

anything missing?

"right chest", "left chest", "center chest"?? (for when you place a club on your chest and let it fall slowly down)
"right armpit", "left armpit"?
"top of head"?

-Christian

[JaCo Stuifbergen]

"right ear" and "left ear"

temple,

and several ways to catch on the elbow.

And several parts of the leg (calf, skin, kneepit (is that the right word?)) and foot (toes, sole, inside ankle, outside ankle)

I think that we won't be able to foresee every bodypart that may be used.

By the way, we should include the juggler in the destination, perhaps

to: {juggler:"A", dock : "right hand"}

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/39b1fafe-1c94-ad55-c9b2-7414e33ede63%40helch.ch.

[Adrian Goldwaser]

> and several ways to catch on the elbow.

I think this raises an important point, do we use 'elbow' then for each catch have details about where it's caught? The same would be true for catching on the back of the hand. I don't think it should be a separate limb but it does make things a bit more ugly when specifying it being caught. I guess all that can be optional parameters but it'll need to be fairly descriptive to really cover all the options here, are we confident that there are good options for this that don't require us to rethink how we represent hands? (in which case we can ignore for version 1) Or is it likely to interact?

> anything missing?

I think you and Co have covered all the main ones, only other ones I can think of are 'neck' (e.g. for neck catches) and back (e.g. for hoop rolling)

To view this discussion on the web visit https://groups.google.com/d/msgid/juggling-interchange-format/CAKHXiFKP6HhG9WY8rAKNe_ysLJiRdJEg_d00b2B0T799vqw65A%40mail.gmail.com.

[JaCo Stuifbergen]

Actually, I think that if we forget an option, we should allow programmers to invent additional names, because we can't foresee every pattern.

(elbow catches or balances, by the way, are complicated for animations, because for certain balances, a juggler lifts the elbow above the shoulder, or must turn the lower arm to create a cradle for the ball)

[Christian Helbling]

On 22.10.20 13:48, Adrian Goldwaser wrote:
>> and several ways to catch on the elbow.
> I think this raises an important point, do we use 'elbow' then for each catch have details about where it's caught? The same would be true for
> catching on the back of the hand. I don't think it should be a separate limb but it does make things a bit more ugly when specifying it being caught.
> I guess all that can be optional parameters but it'll need to be fairly descriptive to really cover all the options here, are we confident that there
> are good options for this that don't require us to rethink how we represent hands? (in which case we can ignore for version 1) Or is it likely to
> interact?

I think we can solve that the same way as we define exact positions of multiple props in one hand. We would need the position and rotationof a prop
relative to the hand there anyway. And also position and rotation of the hand when catching/throwing.
However, it could be handy to store such instructions in the hand definition so it does not have to be repeated on every throw and also so
we can chose on a logical level which type of catch/throw we are doing.
{juggler:0, limb:"right hand"}, // default
{juggler:0, limb:"right hand", catchPosition:.., catchRotation:.., throwPosition:.., throwRotation:..}, // right handed penguin catch
{juggler:0, limb:"right hand", catchPosition:.., catchRotation:.., throwPosition:.., throwRotation:..}, // multiplex catche
{juggler:0, limb:"left hand" },
..

We'll have to discuss positions, movement and rotation anyway at some point.
Maybe when we have found good solutions for that, it will be clear how to solve this one exactly.


>> anything missing?

JaCo Stuifbergen wrote:
> "right ear" and "left ear"
> temple,
> and several ways to catch on the elbow.
> And several parts of the leg (calf, skin, kneepit (is that the right word?)) and foot (toes, sole, inside ankle, outside ankle)

On 22.10.20 13:48, Adrian Goldwaser wrote:
> I think you and Co have covered all the main ones, only other ones I can think of are 'neck' (e.g. for neck catches) and back (e.g. for hoop rolling)

Thanks, we've got a good list now.

JaCo Stuifbergen wrote:
> I think that we won't be able to foresee every bodypart that may be used.

> Actually, I think that if we forget an option, we should allow programmers to invent additional names, because we can't foresee every pattern.

Yes, its not important to define everything. It's good to have the most often used ones defined, so that people use the same ones for the same things.
As long as no one is using anything else than hands we don't have to rush either.

And yes, people can use whatever they want. They probably would have to write the software supporting that themselves though if its not some trivial
case. If there is some standardization need, we can always add new ones.

On 21.10.20 23:06, JaCo Stuifbergen wrote:
> By the way, we should include the juggler in the destination, perhaps
> to: {juggler:"A", dock : "right hand"}

Hmm, "destination" is not too bad as a word.

My suggestion is the following:
- a throw definition refers to hands/limbs in the from and to keys by using zero-based integers
- the hands/limbs are listed in an array with their detailed properties including a zero-based reference to the juggler it belongs
- the jugglers are listed in an array as well with their details (like name, starting position, ..)

Having integer references is really handy for programming stuff.

> (elbow catches or balances, by the way, are complicated for animations, because for certain balances, a juggler lifts the elbow above the shoulder,
or must turn the lower arm to create a cradle for the ball)

lots of hand catches are difficult as well, for example penguins. I hope that many of those can be solved with movement and rotation definitions by
using inverse kinematics on the body model (I don't have that yet for passist, would be really nice though).

Cheers
Christian

[JaCo Stuifbergen]

However, it could be handy to store such instructions in the hand definition so it does not have to be repeated on every throw and also so
we can chose on a logical level which type of catch/throw we are doing.

(side note: "chose" is past tense, the present tense is "choose". I did not invent the english language)

Do you mean definitions like:

A_right_penguin = {juggler:0, limb:"right hand", catchPosition:.., catchRotation:.., throwPosition:.., throwRotation:..}, // right handed penguin catch

or just numbers?

destinations = [{juggler:0, limb:"right hand"}, // default

{juggler:0, limb:"right hand", catchPosition:.., catchRotation:.., throwPosition:.., throwRotation:..}, // right handed penguin catch

...

]

(I understand that both would work)

I like the idea.

Actually, it would be even greater if we can define catch positions independent of the jugglers, like

penguin = { catchPosition:.., catchRotation:.., throwPosition:.., throwRotation:..}

destinations = [{juggler:0, limb:"right hand"}, // default

{juggler:0, limb:"right hand", catchPosition:penguin}, // right handed penguin catch

{juggler:0, limb:"left hand", catchPosition:penguin}, // left handed penguin catch

...

]

Of course, the software would have to figure out how to apply such a definition to right- and left hands.

However, if the file is only meant to be read by computers, it doesn't matter much whether information is repeated.

But it does matter if 1 animator prefers different parameters for a penguin catch, and may not recognize a certain set of parameters as a penguin catch.

Having integer references is really handy for programming stuff.

I have a weak preference for unique strings. "weak preference" means that integer references are all right for me.

(this also applies when references would have to be made to definitions of penguin catch, behind the back catch, under the leg throw 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/6ef30976-424d-2b59-50d0-63d5cacd23da%40helch.ch.

[Adrian Goldwaser]

> I think we can solve that the same way as we define exact positions of multiple props in one hand. We would need the position and rotationof a prop
> relative to the hand there anyway. And also position and rotation of the hand when catching/throwing.

Right, that should work, though that's a lot of extra fields suddenly

> However, it could be handy to store such instructions in the hand definition so it does not have to be repeated on every throw and also so

> we can chose on a logical level which type of catch/throw we are doing.

> Actually, it would be even greater if we can define catch positions independent of the jugglers, like

I think I agree with both of these statements, and I think I'd like to combine them both a bit, if it's defined independently of the hand then we can use it later directly rather than having it be part of hand/limb definitions (which no longer actually reduces repetition). Example below, I've split throw/catch as they are kind of distinct, also happy for these to be indexes into an array again rather than strings, though strings are far more readable here.

// Positions/rotations should be able to be defined in a relative or absolute fashion, these would be relative to hands/side of body (e.g. with positive being away from centre, 0 being neutral position for hand, rotation outwards being positive, etc.)

penguinCatch = { propPosition:.., propRotation:.., handPosition:..., handRotation:...}

penguinThrow = { propPosition:.., propRotation:.., handPosition:..., handRotation:...}
destinations = [{juggler:0, limb:"right hand"}, {juggler:0, limb:"left hand"} ]

throws = [

  {time:0 from:0 to:1 duration:3, catchPosition:penguinCatch, throwPosition:penguinThrow},

  {time:1 from:0 to:1 duration:3, catchPosition:penguinCatch, throwPosition:penguinThrow},

]

symmetry = ...

> > Having integer references is really handy for programming stuff.

> I have a weak preference for unique strings. "weak preference" means that integer references are all right for me.
> (this also applies when references would have to be made to definitions of penguin catch, behind the back catch, under the leg throw etc.)

I find this really depends, using integers for programming is only helpful if you need them as indices in an array - i.e. it can make some things a bit easier to write, most of the time I find it tends to introduce a lot of subtle bugs because you can accidentally assign hands IDs to prop IDs for example (if you did this with strings like 'penguinThrow' and 'rightHand' you'd get an error immediately when looking things up). However that said, I also don't have a strong preference,if using integers you'd probably want a wrapper class around JIF to make it more robust to bugs like this, however it would make the actual representations more concise. I don't mind too much about readability because it should mostly be programs dealing with it.

To view this discussion on the web visit https://groups.google.com/d/msgid/juggling-interchange-format/CAKHXiFJwzWqkN%2Bp_iSmwhoknpxy9SSZjSQO2KH4Q%2BC5WOGC%2BKg%40mail.gmail.com.

[Christian Helbling]

On 25.10.20 04:52, Adrian Goldwaser wrote:
>> I think we can solve that the same way as we define exact positions of multiple props in one hand. We would need the position and rotationof a prop
>> relative to the hand there anyway. And also position and rotation of the hand when catching/throwing.
> Right, that should work, though that's a lot of extra fields suddenly
>
>> However, it could be handy to store such instructions in the hand definition so it does not have to be repeated on every throw and also so
>> we can chose on a logical level which type of catch/throw we are doing.
>
>> Actually, it would be even greater if we can define catch positions independent of the jugglers, like
>
> I think I agree with both of these statements, and I think I'd like to combine them both a bit, if it's defined independently of the hand then we can
> use it later directly rather than having it be part of hand/limb definitions (which no longer actually reduces repetition). Example below, I've split
> throw/catch as they are kind of distinct, also happy for these to be indexes into an array again rather than strings, though strings are far more
> readable here.
>
> // Positions/rotations should be able to be defined in a relative or absolute fashion, these would be relative to hands/side of body (e.g. with
> positive being away from centre, 0 being neutral position for hand, rotation outwards being positive, etc.)
> penguinCatch = { propPosition:.., propRotation:.., handPosition:..., handRotation:...}
> penguinThrow = { propPosition:.., propRotation:.., handPosition:..., handRotation:...}
> destinations = [{juggler:0, limb:"right hand"}, {juggler:0, limb:"left hand"} ]
> throws = [
>   {time:0 from:0 to:1 duration:3, catchPosition:penguinCatch, throwPosition:penguinThrow},
>   {time:1 from:0 to:1 duration:3, catchPosition:penguinCatch, throwPosition:penguinThrow},
> ]
> symmetry = ...

I like that. Good solution.

>> > Having integer references is really handy for programming stuff.
>> I have a weak preference for unique strings. "weak preference" means that integer references are all right for me.
>> (this also applies when references would have to be made to definitions of penguin catch, behind the back catch, under the leg throw etc.)
>
> I find this really depends, using integers for programming is only helpful if you need them as indices in an array - i.e. it can make some things a
> bit easier to write, most of the time I find it tends to introduce a lot of subtle bugs because you can accidentally assign hands IDs to prop IDs for
> example (if you did this with strings like 'penguinThrow' and 'rightHand' you'd get an error immediately when looking things up). However that said, I
> also don't have a strong preference,if using integers you'd probably want a wrapper class around JIF to make it more robust to bugs like this, however
> it would make the actual representations more concise. I don't mind too much about readability because it should mostly be programs dealing with it.

Fair point.
Some mistakes can be avoided by doing out-of-bounds checks but not all of course.
And most would be found early as most keys of the different definitions would be different.

And yes, readability should be optimized for programs (or better the code of the programs), not humans.
Usually you would read and edit a jif by using some causal editor.


I talked with Lukas at passout about this and we ended up preferring integers for simplicity.

When using strings new questions would arise:
- how should users chose those strings? is there some explicit good practice guideline in the spec? or an implicit one by our example jifs?
- am I allowed to use numbers, and if so do they still have to be encoded as strings when using a reference?
in js this works fine:
({"0":'first definition', "1":'second definition'})[1]
- if using numbers, am I allowed to use json arrays instead of json objects for the definitions?
in js this works fine:
['first definition', 'second definition']["1"]
- If we don't allow using arrays for definitions or using integers as references, people might still use them when it just works
in their jif-application of choice (for example passist is using js and probably won't be too strict about its jif input)

If we do not allow to mix integers and strings as references, choosing string references would enforce naming all things having a reference.
So this means even 7 anonymous white balls would need to have reference strings, where we would probably end up using numbers again.

For me, it is still more valuable to have a simple, short format, with not too many different ways to write the same pattern than to
have better human readability and to avoid a few programming mistakes. And in addition we would not need to discuss more details about the
references and about good practice naming and can focus on more important things.

Cheers
Christian

[JaCo Stuifbergen]

If we want to make references by numbers, I am inclined to prefer an array like

throwPositions = ['first definition', 'second definition']

over

catchPositions = {"0":'first definition', "1":'second definition'}

I am not sure that I understood the [1] and ["1"]

Did you mean

['first definition', 'second definition'] ["1"] = throwPositions["1"] = throwPositions[1] ?

and

({"0":'first definition', "1":'second definition'})[1] = catchPositions [1] = catchPositions["1"] ?

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/dc802cb8-6f88-2435-6d52-083f3afa3b12%40helch.ch.

[JaCo Stuifbergen]

I have found the answer to my last question.

Javascript accepts a string as an index, so throwPositions["1"] is the same as throwPositions[1]

I think that the choice is between thinks like

throws = [{... to:"LeftHandOfJugglerA", position:"penguinCatch", ....},...

and

throws = [{... to:5, position:4, ....},...

I suppose that you don't want to write

throws = [ [.... ,   5 , 4 , ....], etcetera

or

throws = [{... "3":"LeftHandOfJugglerA", "4":"penguinCatch", ....},...

or

throws = [{... "3":5, "4":4, ....},...

I think that it is unavoidable that JIF defines some strings or numbers.

E.g. it will be useful to be able to refer to hands, knees, shoulders etc.

Either we reserve numbers, so a programmer can set

destinations = [ {juggler: 0, limb:4} // 4 means: left foot

                        , {juggler:0, limb:5} // right foot

                        , {juggler:1, limb:3} // neck

                        , {juggler:1, limb:8} // right elbow

                        , .....

or

destinations = [ {juggler: 0, limb:"leftFoot"}

                        , {juggler:0, limb:"rightFoot"}

                        , {juggler:1, limb:"neck"}

                        , {juggler:1, limb:"right elbow"}

                        , .....

Back to the discussion:

When using strings new questions would arise:
- how should users chose those strings? is there some explicit good practice guideline in the spec? or an implicit one by our example jifs?

we can specify which strings will not be claimed by the JIF, for exampel all strings that start with "my_" or "custom_".

- am I allowed to use numbers, and if so do they still have to be encoded as strings when using a reference?
  in js this works fine:
    ({"0":'first definition', "1":'second definition'})[1]

 I think that in JSON, we should not refer to object attributes by numbers.

So, use {color: #D8F ,....} and not {0:#D8F}

We may use numbers when we refer to a value in an array, for example

colors = [#2AF, #445 , #80B, #D8F, #DD0, #F05]

{ color: 3}

The number (quantity) of jugglers, limbs, colors etc is in principel unlimited, so array references are acceptabel for me.

- if using numbers, am I allowed to use json arrays instead of json objects for the definitions?

I recommend not to allow this. Javascript will not complain when it is given an object like

{"0":'first definition', "1":'second definition'} in stead of an array

['first definition', 'second definition']

but there may be languages that are not able to handle this.

- If we don't allow using arrays for definitions or using integers as references, people might still use them when it just works
  in their jif-application of choice (for example passist is using js and probably won't be too strict about its jif input)

Do you want to make the standard attractive to programmers? That seems wise, because we can't force programmers to respect a standard.

If for programmers, it is easier to refer to jugglers or destinations etc. by number, JIF should probably do the same.

 

If we do not allow to mix integers and strings as references, choosing string references would enforce naming all things having a reference.
So this means even 7 anonymous white balls would need to have reference strings, where we would probably end up using numbers again.

"ball1", "ball2", "ball3" etc. are also strings.

For me, it is still more valuable to have a simple, short format, with not too many different ways to write the same pattern than to
have better human readability and to avoid a few programming mistakes. And in addition we would not need to discuss more details about the
references and about good practice naming and can focus on more important things.

For attributes of objects, I think that we should keep strings.

And programmers may add attributes, so we can't avoid a decision about naming standards.

[Florian Pesth]

Hi Christian,

Am Tue, 27 Oct 2020 01:08:17 +0100
schrieb Christian Helbling <he...@helch.ch>:

> Fair point.
> Some mistakes can be avoided by doing out-of-bounds checks but not
> all of course. And most would be found early as most keys of the
> different definitions would be different.
>
> And yes, readability should be optimized for programs (or better the
> code of the programs), not humans. Usually you would read and edit a
> jif by using some causal editor.
>
>
> I talked with Lukas at passout about this and we ended up preferring
> integers for simplicity.
>
> When using strings new questions would arise:
> - how should users chose those strings? is there some explicit good
> practice guideline in the spec? or an implicit one by our example
> jifs?
> - am I allowed to use numbers, and if so do they still have to be
> encoded as strings when using a reference? in js this works fine:
> ({"0":'first definition', "1":'second definition'})[1]
> - if using numbers, am I allowed to use json arrays instead of json
> objects for the definitions? in js this works fine:
> ['first definition', 'second definition']["1"]

Not sure if I follow here (but I'm not deep into json nor javascript)
but IMO we should stay with the JSON standard if there is a difference
between Javascript and JSON. I would like to be able to read the JIF
files with any standard JSON parser.

I would also like to have a JSON Schema we can validate against, once
we have specified the format.

> - If we don't allow using arrays for definitions or using integers as
> references, people might still use them when it just works in their
> jif-application of choice (for example passist is using js and
> probably won't be too strict about its jif input)
>
> If we do not allow to mix integers and strings as references,
> choosing string references would enforce naming all things having a
> reference. So this means even 7 anonymous white balls would need to
> have reference strings, where we would probably end up using numbers
> again.
>
> For me, it is still more valuable to have a simple, short format,
> with not too many different ways to write the same pattern than to
> have better human readability and to avoid a few programming
> mistakes. And in addition we would not need to discuss more details
> about the references and about good practice naming and can focus on
> more important things.

I agree. I think we should aim for a format which allows to express
everything we might want to express but as simple and uniformly as
possible.

So I think we should aim more for pythons philosophy "There should be
one-- and preferably only one --obvious way to do it." than perls
philosophy "There's more than one way to do it".

But still I think the format should be expressive enough to be usable
as a storage format for any juggling program.

Cheers,
Florian

>
> Cheers
> Christian
>
>
>
>

[Christian Helbling]

On 02.11.20 20:43, Florian Pesth wrote:
> Hi Christian,
>
> Am Tue, 27 Oct 2020 01:08:17 +0100
> schrieb Christian Helbling <he...@helch.ch>:
>
>> Fair point.
>> Some mistakes can be avoided by doing out-of-bounds checks but not

>> all of course. And most would be found early as most keys oI would also like to have a JSON Schema we can validate against, once
we have specified the format.f the

>> different definitions would be different.
>>
>> And yes, readability should be optimized for programs (or better the
>> code of the programs), not humans. Usually you would read and edit a
>> jif by using some causal editor.
>>
>>
>> I talked with Lukas at passout about this and we ended up preferring
>> integers for simplicity.
>>
>> When using strings new questions would arise:
>> - how should users chose those strings? is there some explicit good
>> practice guideline in the spec? or an implicit one by our example
>> jifs?
>> - am I allowed to use numbers, and if so do they still have to be
>> encoded as strings when using a reference? in js this works fine:
>> ({"0":'first definition', "1":'second definition'})[1]
>> - if using numbers, am I allowed to use json arrays instead of json
>> objects for the definitions? in js this works fine:
>> ['first definition', 'second definition']["1"]
>
> Not sure if I follow here (but I'm not deep into json nor javascript)
> but IMO we should stay with the JSON standard if there is a difference
> between Javascript and JSON. I would like to be able to read the JIF
> files with any standard JSON parser.

I was not too clear about that as both you and Co were confused.
Yes, jif should be in JSON.

I was talking about the implications of using strings as "references" for
limbs, jugglers, props and so on. This was proposed in many examples and
would look something like:
{
..
limbs:{
"A_right_hand": {juggler:"A", limb:"right hand"},
"A_left_hand": {juggler:"A", limb:"left hand"},
..
},
throws: [
{time:0, duration:7, from:"A_right_hand", to:"B_left_hand"},
..
],
..
}

With a spec like this, people might generate valid jifs like this:
{
..
limbs: {
"0": {juggler:"A", limb: "right hand"},
"1": {juggler:"A", limb:"left hand"},
..
},
throws: [
{time:0, duration:7, from:"0", to:"2"},
..
]
..
}

But my js code (that is very generous about its input) would even allow this (or combinations of this with the last example) without any code
modifications at all:
{
..
limbs: [
{juggler:"A", limb: "right hand"},
{juggler:"A", limb:"left hand"},
..
],
throws: [
{time:0, duration:7, from:0, to:2},
..
]
..
}

This example would not be valid as it is not using string references anymore.
Thus, some people might be tempted to generate jifs that perfectly work in some but not all applications (as those might not expect a json array
for the limbs definition and integers as values for from and to).
To avoid that kind of confusion and a specification police, I prefer integer references as in the last example.

> I would also like to have a JSON Schema we can validate against, once
> we have specified the format.

Lukas wished that as well.

I personally don't need it (happy to live in the wild untyped wilderness),
but I don't mind adding that to the specification if someone works it out.

>> - If we don't allow using arrays for definitions or using integers as
>> references, people might still use them when it just works in their
>> jif-application of choice (for example passist is using js and
>> probably won't be too strict about its jif input)
>>
>> If we do not allow to mix integers and strings as references,
>> choosing string references would enforce naming all things having a
>> reference. So this means even 7 anonymous white balls would need to
>> have reference strings, where we would probably end up using numbers
>> again.
>>
>> For me, it is still more valuable to have a simple, short format,
>> with not too many different ways to write the same pattern than to
>> have better human readability and to avoid a few programming
>> mistakes. And in addition we would not need to discuss more details
>> about the references and about good practice naming and can focus on
>> more important things.
>
> I agree. I think we should aim for a format which allows to express
> everything we might want to express but as simple and uniformly as
> possible.
>
> So I think we should aim more for pythons philosophy "There should be
> one-- and preferably only one --obvious way to do it." than perls
> philosophy "There's more than one way to do it".

python 2 or 3?
scnr :)

mostly agree but not for time scaling where people should use their own preferred
scale in my opinion. Or it would be an argument against time scaling in the first
place (which is fine for me as well).

> But still I think the format should be expressive enough to be usable
> as a storage format for any juggling program.

agreed.

Cheers
Christian

[JaCo Stuifbergen]

Thanks Christian.
I think that I understand the problem about integer references vs string references.

I think that the "logical" way will be to use integers for unlimited objects, like

- jugglers

- limbs

- props

- throws

And to use strings for object attributes, like

throws[0] ={ time:3.54, duration:5.76, from:1, to: 4 , prop:3, .....}

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/7795a463-bce0-5911-f709-97282d1d09a2%40helch.ch.