Collection of JIF use cases

23 views
Skip to first unread message

Lukas Bonauer

unread,
Oct 24, 2020, 12:45:32 PM10/24/20
to juggling-interchange-format

Hi all,

I am really happy to see that the discussion on JIF has gathered steam again! Sadly I didn't have the time to chime in so far, and probably won't have for at least another week.

The technical details are very interesting and I will write my opinion on these soon™, but to facilitate a productive discussion I would propose starting a collection of potential use cases. When it comes to finalizing the initial JIF spec, we can then validate our decisions against that document to find out how easy/hard that use case would be to implement given that proposal.

At the moment, everyone has to keep all the possible applications in mind, and I find it easy to overlook some aspects which may not be too top-of-mind for myself.

I think 2 different kinds of use cases are relevant here:

(1) Types of software:

  • Short description of what the core features would be.
  • Input/output data as applicable, on a high level (maybe separated into "core" and "nice-to-have" data?)
  • (optional) Links to existing software of this category.

(2) Classes of juggling patterns: 

  • Defining features / assumptions / broken assumptions for this class of patterns.
  • Concrete example patterns in this class (include basic/popular ones and also obscure ones which might introduce interesting edge cases).
  • (eventually) Decision on how important we consider seamless support for this class to be, and whether there are acceptable workarounds that reduce this to more "standard" pattern class.


Examples for (1) off the top of my head:

  • siteswap generator of various types (input: non-JIF UI, output: JIF with only logical throws)
  • manipulation pattern generator (input: non-JIF UI, output: JIF with only logical throws, focus on juggler movement+relabeling and having a sane representation for intercept/substitute/carry modules)
  • causal diagram visualizer/editor (input: JIF with logical throws, output: same)
  • 3D animator (input: JIF with any level of detail, output: JIF with physical properties mostly populated)
  • prop orbit analyzer (input: JIF with logical throws, output: none)
  • sequencer for juggling shows with programmable LED props** (input: non-JIF UI, output: non-periodic JIF with focus on juggler movement, identifiable props, changing prop colors, etc.)
  • ...

There were already lots of examples for (2) discussed here. When I say "classes of patterns", some examples I have in mind are (they can of course overlap):

  • vanilla siteswap
  • multiplexes
  • n-handed siteswap
  • social siteswap / Prechac
  • manipulation patterns
  • walking patterns (where jugglers are relabeled at the end of the period)
  • poly-rhythmic patterns
  • contact juggling (interaction with body parts other than hands)
  • clay juggling (props can be merged/split/attached to each other)
  • mixed-prop juggling (e.g. clubs and rings in the same pattern)
  • non-periodic patterns (a generally longer, non-repeating sequence, would be nice to be able to specify e.g. "10 rounds of {representation of 531}, followed by a long pause, followed by passing 6 rounds of {representation of 86867}")
  • ...

In the actual collection document, you can go into more detail for each of these and everyone should easily be able to add their own ideas, and ideally also discuss them there.

Any ideas for the location of such a document? Google Docs? Markdown file in the jif repo? GitHub wiki? Some Cloud with a public link? Not sure ...

I think Google Docs would offer a good trade-off, especially with the option for inline comments and discussion, but I am open for other suggestions.

Cheers,
Lukas

----

**If this seems oddly specific, it is because I have written one and would love to interface with JIF-compatible software to make better visualizations!

Christian Helbling

unread,
Oct 24, 2020, 3:40:36 PM10/24/20
to juggling-inte...@googlegroups.com
Hi Lukas

I really like this approach, thanks!

After publishing the first standard,
we can even maintain a list of one juggling pattern per class that can serve as example/test
input for programs and to illustrate jif.

I'll put a markdown file for (1) and (2) into the jif github repo and add stuff as discussed on the mailing list.

If you think that discussing details of that will be more efficient on google docs go for it.
I'll try to maintain a consensus on the git repo, so that can serve as our official common condensed state.

Cheers
Christian


On 24.10.20 18:45, 'Lukas Bonauer' via juggling-interchange-format wrote:
> Hi all,
>
> I am really happy to see that the discussion on JIF has gathered steam again! Sadly I didn't have the time to chime in so far, and probably won't have
> for at least another week.
>
> The technical details are very interesting and I will write my opinion on these soon™, but to facilitate a productive discussion I would propose
> starting a collection of potential use cases. When it comes to finalizing the initial JIF spec, we can then validate our decisions against that
> document to find out how easy/hard that use case would be to implement given that proposal.
>
> At the moment, everyone has to keep all the possible applications in mind, and I find it easy to overlook some aspects which may not be too
> top-of-mind for myself.
>
> I think 2 different kinds of use cases are relevant here:
>
> (1) Types of software:
>
> * Short description of what the core features would be.
> * Input/output data as applicable, on a high level (maybe separated into "core" and "nice-to-have" data?)
> * (optional) Links to existing software of this category.
>
> (2) Classes of juggling patterns: 
>
> * Defining features / assumptions / broken assumptions for this class of patterns.
> * Concrete example patterns in this class (include basic/popular ones and also obscure ones which might introduce interesting edge cases).
> * (eventually) Decision on how important we consider seamless support for this class to be, and whether there are acceptable workarounds that reduce
> this to more "standard" pattern class.
>
>
> Examples for (1) off the top of my head:
>
> * *siteswap generator* of various types (_input_: non-JIF UI, _output_: JIF with only logical throws)
> * *manipulation pattern generator* (_input_: non-JIF UI, _output_: JIF with only logical throws, focus on juggler movement+relabeling and having a
> sane representation for intercept/substitute/carry modules)
> * *causal diagram visualizer/editor* (_input_: JIF with logical throws, _output_: same)
> * *3D animator* (_input_: JIF with any level of detail, _output_: JIF with physical properties mostly populated)
> * *prop orbit analyzer* (_input_: JIF with logical throws, _output_: none)
> * *sequencer* for juggling shows with programmable LED props** (_input_: non-JIF UI, _output_: non-periodic JIF with focus on juggler movement,
> identifiable props, changing prop colors, etc.)
> * ...
>
> There were already lots of examples for (2) discussed here. When I say "classes of patterns", some examples I have in mind are (they can of course
> overlap):
>
> * vanilla siteswap
> * multiplexes
> * n-handed siteswap
> * social siteswap / Prechac
> * manipulation patterns
> * walking patterns (where jugglers are relabeled at the end of the period)
> * poly-rhythmic patterns
> * contact juggling (interaction with body parts other than hands)
> * clay juggling (props can be merged/split/attached to each other)
> * mixed-prop juggling (e.g. clubs and rings in the same pattern)
> * non-periodic patterns (a generally longer, non-repeating sequence, would be nice to be able to specify e.g. "10 rounds of {representation of 531},
> followed by a long pause, followed by passing 6 rounds of {representation of 86867}")
> * ...
>
> In the actual collection document, you can go into more detail for each of these and everyone should easily be able to add their own ideas, and
> ideally also discuss them there.
>
> Any ideas for the location of such a document? Google Docs? Markdown file in the jif repo? GitHub wiki? Some Cloud with a public link? Not sure ...
>
> I think Google Docs would offer a good trade-off, especially with the option for inline comments and discussion, but I am open for other suggestions.
>
> Cheers,
> Lukas
>
> ----
>
> **If this seems oddly specific, it is because I have written one <https://github.com/Bone008/GlowSequencer> and would love to interface with
> JIF-compatible software to make better visualizations!
>
> --
> 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
> <mailto:juggling-interchang...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/juggling-interchange-format/cba6f2d8-cda2-649d-69d4-f74f476dc32e%40yahoo.de
> <https://groups.google.com/d/msgid/juggling-interchange-format/cba6f2d8-cda2-649d-69d4-f74f476dc32e%40yahoo.de?utm_medium=email&utm_source=footer>.


Florian Pesth

unread,
Oct 24, 2020, 6:46:04 PM10/24/20
to juggling-inte...@googlegroups.com

I agree, this are good ideas.

If it is a google doc I would prefer it to be editable by everyone even
without a google account (I don't want one), is this even possible?

Another option would be to have issues on the github repo for each use
case. Issues have the advantage that they could be linked to
commits in the git repo, so changes to examples could kept linked to
the discussion. They need a github account though... (which I have and
I'm fine with, but this is personal preferences - I understand that)

If it helps I have a virtual debian server which I can use to install
some collaborative software if this would help. If we can do with the
free stuff it would be better of course.

Cheers,
Florian

Am Sat, 24 Oct 2020 21:40:33 +0200
schrieb Christian Helbling <he...@helch.ch>:

Graham Haslehurst

unread,
Oct 24, 2020, 7:14:54 PM10/24/20
to Florian Pesth, juggling-inte...@googlegroups.com
I think Google docs do require some kind of Google sign in. 

I think it might also be worth understanding what the limitations of current formats are. If something works well for something, why reinvent it?

Graham

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/20201025004602.4fd77cb5%40babbage.

Adrian Goldwaser

unread,
Oct 25, 2020, 12:38:53 AM10/25/20
to juggling-interchange-format
I agree that docs is a good option as it has comments and people don't need to understand how git works and it still has history if needed, though I also agree with Christian that we put keep the consensus in git once we've done the initial version as further changes will be irregular then.

> If it is a google doc I would prefer it to be editable by everyone even without a google account (I don't want one), is this even possible?
Yes, this is easily doable and it seems like most people are happy with docs if they don't need to log in, I set up a doc with what Lukas gave - you should be able to edit it (I could in an incognito window while signed out), I will send not to the mailing list but to everyone who has participated in the discussion (I don't have the email addresses of other people) so it's not going to get spammed by bots (I don't know how good Google's prevention of this is and don't want to test it) as anyone can edit even without logging in - if I miss you somehow or you haven't sent an email yet here and want the link, please email me.

> I think it might also be worth understanding what the limitations of current formats are. If something works well for something, why reinvent it?
I agree this is worth recording and writing explicitly, JML is really the only option though as far as I'm aware (other than internal formats of various programs). All of the others are way too limited (e.g. passing siteswap).

JaCo Stuifbergen

unread,
Oct 25, 2020, 5:36:30 AM10/25/20
to juggling-interchange-format
Because of Brexit, we don't have to apply British grammar for english, but I prefer:
this is a good idea, or
these are good ideas.

(I agree by the way, and thanks for opening the google doc).
On Sun, 25 Oct 2020 at 00:46, Florian Pesth <fpe...@gmx.de> wrote:
I agree, this are good ideas.

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

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

Florian Pesth

unread,
Oct 25, 2020, 1:48:39 PM10/25/20
to juggling-interchange-format
Hi Co,

sorry for the denglish - I don't intend to butcher english language,
it just happens ;).

Also I'm coming up with a pretty ridiculous polyrythmic feedern pattern
based on 531 which is a pretty good testcase I think :). I will upload
a picture once I have thought it through.

Cheers,
Florian



Am Sun, 25 Oct 2020 10:36:17 +0100
schrieb JaCo Stuifbergen <j.c.stu...@gmail.com>:

> Because of Brexit, we don't have to apply British grammar for
> english, but I prefer:
> this *is* a good idea, or
> *these *are good ideas.

Graham Haslehurst

unread,
Oct 25, 2020, 3:08:51 PM10/25/20
to Florian Pesth, juggling-interchange-format
I wouldn't worry so much about the slips. The quality of English on this list is really high and far surpasses most that would have voted for Brexit.

Graham
Formally of the UK now in NZ... 

--
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/20201025184836.790eb9f6%40babbage.
Reply all
Reply to author
Forward
0 new messages