Pilcrow setup

[dcmorse]

@cranhandler:

Progression brainstorm : we give administrators a visible draggable ¶ , placed at the "empty figure" C1 of every existing dance adminisaur drags it to its proper place in each existing dance as this does or doesn't work as expected, we gather valuable feedback on how it should appear for new dances going forward upsides: is not visible to Standard Users until it's fully adopted throughout the DB upsides: ¶ is pronounced 'pilcrow' upsides: you can do the desired "convert empty figure to standing still" technical debt as a warmup to this downsides: you do a lot of building before I can see/use it

dcmorse:

yes, and: we remove the existing progression support from progress, zig zag, slide left and anything else with it. we create a way to add a second progression (for double progression dances) and an anti-progression (for dances that interact with previous neighbor)

We create two modes of neighbor display - chosen by the user in the dance editor:

• [ ] absolute neighbor (neighbors display as 2nd neighbor, 3rd neighbor etc)

• [ ] relative neighbor (neighbors display as next neighbor when first encountered, then are referred to as just neighbor on subsequent references - could this be done even in figure notes?)

cranhandler:

Aha. These are all good storms. Nix figure notes, though

[dcmorse]

(brainstorming)

absolute mode

From the end of a pilcrow on to the end of the next pilcrow*, you scan for every reference to neighbor. When you find one, that figure is printed with the index in front of it. E.g. 2nd neighbor. 3rd neighbor. Etcetara.

relative mode

From the end of a pilcrow on*, you scan for the first reference to neighbor, gentlespoon, or ladle. When you find one, that figure is printed with the word next in front of it (do not scan custom text or notes). Resolves #288.

all modes

:tada: Remove previous neighbor, next/2nd neighbor, 3rd neighbor, and 4th neighbor from all role selection menus!

gotta have anti-pilcrow to access those previous neighbors. And previous-2 neigbors. Sorry.

* = does not wrap around the end of the dance. This slightly hobbles the 'Rotate' button.

[dcmorse]

(brainstorming)

make analogous 'shadow' changes to the above

• Perhaps use ❏ and ❐ instead of ¶ and ⁋
• Enables shadow salmon ladders ala that Michael Fuerst dance
• does nothing to gentlespoons or ladles, rather more simply than neighbor progressions.
• removes final rationale for the ugly dialect hackery that causes shadow to print as 1st shadow and next neighbor to print as 2nd neighbor. Thus it's code complexity cost is rather more neutral than one'd expect.
• removes 2nd neighbor from all menus

[cranhandler]

I'm confused about what ❏ and ❐ mean?

I haven't fully contemplated the 'making analogous shadow changes' post yet, but for everything above, I understand it, I think I like it, I request that we let Cary review and give us feedback before we build it.

I also wonder if there are some dances when I want to see absolute neighbors, and others where I want to see relative neighbors, and that could get annoying to print out in a single program? But there's an easy paper hack (print the dance that is atypical from my viewing preference norm as a separate sheet of paper), so that doesn't need to stand in the way of this implementation.

[dcmorse]

I also wonder if there are some dances when I want to see absolute neighbors, and others where I want to see relative neighbors, and that could get annoying to print out in a single program? But there's an easy paper hack (print the dance that is atypical from my viewing preference norm as a separate sheet of paper), so that doesn't need to stand in the way of this implementation.

Oh, this shines a light on one of my hidden assumptions. I was imagining this toggle is set by the dance-enterer, in the dance editor, not by dance readers. So dances that progress once, in the B1, would probably use relative. Dances with complicated progressions like 2-forward-1-back would probably use relative. Chain salmon pull-by dances would probably use relative.

I'm confused about what ❏ and ❐ mean?

❏ is like ¶, but it changes the way shadow prints. In absolute shadow mode, it prints as 2nd shadow. Another ❏ would change further mentions of shadow to 3rd shadow. If you threw in a ❐ and then referenced a shadow, it'd then be 2nd shadow. Mainly useful in shadow salmon pull-bys, but maybe also tall-tall-towers style dances.

I will chill on the shadow bits and run this by CR.

[dcmorse]

dcmorse writes:

CR writes:

What is a pilcrow?

¶ - the paragraph symbol

When I have a dance that progresses in the middle, I say look for a "new" neighbor. To me, this implies that the new neighbor is now your neighbor. "Next" implies that that person will become your neighbor at some point.

Thank you for this careful definition.

But I have no problem with your concept - relative when it works, absolute when relative gets too complicated.

Re: progression - be aware that you don't always progress with your partner.

These can all happen within a single figure -

• Single progress or unprogress with your partner
• Double progress or unprogress with your partner (1/2 hey on a diagonal)
• Ladies double progress or unprogress (ladies chain on a diagonal)
• Men double progress or unprogress
• Single progress or unprogress with your neighbor
• Double progress or unprogress with your neighbor

Ooh! Good point. Also: yikes!

This makes me realize that my definition of a progression is probably wrong, or at best fuzzy.

I've been thinking of a progression as something that changes who I point to when asked "who are your neighbors?".

The broader definition you put forward - which I think doesn't work with the stuff in the link - or at least I don't see how it can work - seems to be "what three people are in your minor set?".

Suppose from Beckett, there's a ladies [left diagonal] chain. The ladies are now along the side of the set with their 2nd neighbor. The person across is their upstream shadow. The same-role person in that minor set is ... 3rd neighbor's lady. So I see the double progress when ladies eyes meet, but I also see only a single progression when looking at her neighbor gent. Is 'progression' really a useful concept here? I guess if it populates the menus with the right people, then 'yes'. Hm.

[dcmorse]

CR writes:

Each minor set has a position on the floor. If a figure causes me to be in a minor set with a different position on the floor, then I have progressed. (I'm not including down the hall.) See http://www.dance.ravitz.us/chor.php#5 .

In your last paragraph, I assume you meant ladies chain on a diagonal [I did]. I think the above link will help explain.

An example of progressing with your neighbor (and therefore away from your partner) is Whitewater http://www.dance.ravitz.us/#wh .

I forgot - there are also progressions with a shadow.

[dcmorse]

Cary thinks a progression moves you from a patch of dance floor to another patch of dance floor _{View in Slack}

[dcmorse]

@cranhandler

I can see that But Then do you have to mark it in chainsaws? Yuck _{View in Slack}

[dcmorse]

I was hoping to use progression as a concept to limit the number of dancer menu entries. Cary's definition doesn't do that.

@cranhandler replies:

Hmm Do you agree that menu entry lengths are a lesser problem than "we're not capturing progression"?

Um, I don't know. Cary's definition is so weird as to be cluttering, I think. For example, he views 'ladies chain along the left diagonal' to be a double progression for the ladies only. While it's fun to think about abstractly,... I think that, rendered in user interface chrome, would just make people's heads explode.

@cranhandler replies:

Ah, yeah, cluttered iud the right term for calling I see that it's important for choreography But doesn't belong on the calling card

I'm currently entering http://www.dance.ravitz.us/#wh , which I haven't been able to enter before because I didn't know his definition of progression. It just didn't make any sense to me. So to circle back to your question of

Do you agree that menu entry lengths are a lesser problem than "we're not capturing progression"?

my answer is "I don't even know what a useful representation of progression is anymore". I am confuzzled. I'm suspecting that the CR definition doesn't add value for our users.

[dcmorse]

This issue is closed for now, as we need to move ahead on something smaller and simpler. Namely #468 .