Feature: Session aware "calls-used" list, and also a sequence designer, and ...

[mpogue2]

Pull the files dynamically from a "reference" folder in the Music Directory. This also allows the fonts to be scaled appropriately.

[mpogue2]

Also, allow PDF's to be used for reference material.

[danlyke]

I'd love a list that session dependent lets me check off calls that I've taught.... And keeps those dates.

[danlyke]

check out the "danlyke" branch, with some caveats:

tl;dr: Basically, take all of the .txt files here, drop them into a "Choreography" file in your music folder, and play.

1. The attached danceprogrambla.txt files need to be somewhere in your music path, or you can create your own dance programs as "danceprogram*.txt", which either have one call per line, or the call sequence number (with optional .a, etc) followed by the call name (separated with an optional comma), as in these files.

2. I'm not saving the previously selected dance program (probably by session) yet. This is saving the "when taught", by session.

3. I don't have a "Clear all" button.

4. I don't remember where I had the choreo search generally, it's rough and doesn't update all the time, but if you take the other choreo files here (these are from SquareView, email me for a pdf2text derived from Andy Shore's singing call list, which I haven't attached here 'cause he's copyrighted it and I didn't want to play license games yet), there's some set of choreo searching on the last tab. Because we don't have a database of calls, rather than search for the taught calls at the level, I exclude the calls that haven't been taught. Possibility of false positives, but that's fine.

The things I like about this:

1. We don't yet have to standardize on a call database.
2. It works, kinda, and is a place to start going forward from.

Things I don't like:

1. It isn't really a step towards a standardized call database.
2. I'm not sure how this'll interoperate with the modules ideas.

singers-a2.txt sequence_A1.txt sequence_C4.txt sequence_Plus.txt danceprogram_basic1.txt danceprogram_plus.txt danceprogram_a1.txt danceprogram_mainstream.txt danceprogram_basic2.txt danceprogram_a2.txt

[danlyke]

Okay, I went to a 3 column: rightmost column is a list of text files with choreo. Middle column is the current search results. Double click on one of those to add it to the left column, double click on the item in the left column to remove it.

Not sure this is the right direction, but being able to play with things helps me a lot.

[mpogue2]

Quite a bit better, and very interesting, I think!

Couple of misc UX thoughts: 1) Generally in Western language cultures, flow is L to R. Currently the prototype is R to L. Consider how it might work in the other direction... I may have accidentally encouraged the use of LH pane, because the SD tab currently uses the LH pane for the output side. (The SD tab is somewhat CSDS-like, but maybe this is also something that could be improved on.) 1b) A L to R model reminds me a lot of the Mac OS X Finder, which is quite intuitive. If you haven't played with the Finder before, let me know...Maybe the LH panes becomes a list of "filters", which could be created on-demand (click on a "+" button) and are persistent, reorderable, nameable, and deletable. Then, when you click on a filter in LH pane, the middle pane shows ALL the modules meeting that criteria. Then, you can drag/drop them from middle pane into RH pane to order them into tips. Maybe we then need a separate 3-pane view for named Tip filters, and Tips that meet the filter, and ordered tips in a dance. Seems consistent. Arrange modules to make Tips tab. Arrange Tips to make a Dance tab. Just some brainstorming here... 2) The middle column needs some delineation between modules, I think. A simple line would do! 3) Consider moving away from files (which is really what the third pane is). Files are not really a square dance-focused concept, they're more of a computer-focused concept. I think callers tend to think more in modules that meet a criteria (e.g. the filter concept we've been talking about), rather than the container the text happens to live in on the hard drive... 4) The double-click move, double-click to move back seems quite natural to me...I like it!
5) Drag and drop might also be a possibility, especially for reordering modules within a sequence. It would also work better if we're adding something to the MIDDLE of a sequence. Right now, with only Append, we'd have to delete, then add, then add back the deleted ones. 6) Consider use of font styles (e.g. bold, italic), and foreground and background colors. How could these add to the amount of (relevant, important) data presented on the screen (without overwhelming the user)?

[mpogue2]

Oh, one more thought. 7) SD tab then becomes the way you make Modules (and a Sequence is just an SS->SS module, like any other module). The Modules tab allows assembly into Tips (Brackets in Australia!). The Dance tab allows assembly of Tips (and music?) into a Dance.

[mpogue2]

I will also note that we're way off the original intent of #31, which was "reference material, like Callerlab lists". I think the topic of module/sequence/tip/dance design really deserves it's own Issue. Let's use this one (#31) for the Huge Design Topic you're currently tackling, and I'll move the Reference idea off to another Issue!

[danlyke]

Yeah, I started hanging stuff off this issue because I wanted checkboxes on my call lists, and once I started with that it got out of control. It'd be fairly easy to write the call lists into the music directory if they don't exist, and load them, and do away with the "Sequences" tab for right now.

But, in order:

1. Done (I just reordered them in designer). I started putting stuff over to the right because I'm used to seeing tool bars over there, and that's what the collections of sequences felt like.
2. Done.
3. Yeah, I went with files because I had them, and because I'm still playing with how to manage choreography. So, yes: I think this is the big problem: How do we represent choreo...
4. Good. I've been thinking about a "cursor" notion in the choreography, where double clicks add at the cursor.
5. Hmmm... I wonder if this is as simple as turning it on for list view.
6. I'm open to that, didn't know how much HTML the list view could deal with...

I spent a good portion of last night practicing singing calls with Charlene, and on the basis of that I want to be able to throw sequences into the cue sheet, which means cue sheet markup. So my next prototypes may have some notion of "mark these sequences for inclusion in the cue sheet". But that requires some load and save...

[mpogue2]

Pretty soon you'll be designing a full-blown cue sheet editor. :-) You'd be tackling two big problems then!! (quite impressive, actually... :-) Then it will be synchronized lyrics...and down the rabbit hole you go...

[mpogue2]

OK, I moved the reference material idea over to #107. This one can cover a bunch of stuff -- feel free to split it up if/when you want to!

[danlyke]

So how do you envision choreography being created? Write it out in SD and do a "write sequence to file" occasionally?

Then we go through those files and parse out module points (ie: detect zero boxes and zero lines and other common formations)?

I've got some ideas coming together, but I need a few more views on what other people's workflows look like (especially since I've looked at the Taminations call descriptions and have some hopes for integrating those).

[mpogue2]

In general, I'm in favor of "tighter" integration, while getting rid of computer-sciency concepts, or concepts that are tied to the underlying implementation. I'm also not adverse to hacking on SD itself, to make it easier to integrate.

So, IMHO the idea of "write sequence to a file" is one of those concepts from SD that was relevant back in the 70's, but square dance callers don't (except for us programmers) think in terms of files. There might be some import/export concepts from/to a file, but that would be rarely used, I think.

So, if a module is created in SD, I think there should be a way of saving it that doesn't involve telling SD to "write sequence to file". (Was that your question?)

In place of that, there probably has to be SOME action that says "keep this one around -- I like it, and I want to see it again later or use it in a longer sequence later". From the VUI it might be "save this module". From the GUI it might be Sequence > Save Module, or something similar. Whether it actually saves to files or DB underneath should be opaque to the user.

I'm probably also thinking about something simpler than you right now. I see auto-detection of module points as a SUPER HARD problem, because after every call there's potentially a module point, and which one does the user want? That problem is probably best left for the human to specify, I think. Example: If the module in the LHPane is self-contained, the user can save the whole thing. If the user wants only part of the LHPane, maybe he/she will select it, and then save it? The starting and ending formations are known by SD, and so maybe SD can remember them as part of the module (e.g. SS -> ZB rotated 1/4 CW). Then, when appending a module to this sequence, any module starting with ZB or waves (because of the ocean wave rule), regardless of rotation, could be appended.

I think it's a great idea to talk to other callers about how they work...this is a SUPER HARD problem to tackle, and ideally we can help 80-90% of callers with that.

[mpogue2]

Also, the comment I made before is as far as I got on thinking about this: 7) SD tab then becomes the way you make Modules (and a Sequence is just an SS->SS module, like any other module). The Modules tab allows assembly into Tips (Brackets in Australia!). The Dance tab allows assembly of Tips (and music?) into a Dance.

This is the right workflow (for me), but other callers might have a different workflow.

[danlyke]

Hmmm... Files are an organizational tool that I find convenient, but I agree that after some import they may become irrelevant, if we have a better organizational tool.

So if we start with the premise of storing sequences in the database: Presumably we can do that by importing from SD files, which will be a step towards doing this automagically. It does kind of mean we have a data entry problem, in that things like Andy Shore's singing figures will need to be re-keyed...

Maybe I'll start by porting my Perl script to pipe SD files back into SD to get formation information out to C++ and set up an "Import from SD" option that does that. With a database of sequences and formations we can designate a couple of formations as module points, and find sequences that pass through module points.

I guess it kind of feels like there's a missing integration between the searching and assembly tool and the SD pane, but maybe we don't have the engine for that yet and we'll have to evolve towards it.

[danlyke]

Ugh, also: With simple choreography, there often isn't a way to make SD do what you want. For instance, the very first call in Andy Shore's list is:

4 Ladies Chain 3/4, Heads Promenade 3/4, Centers Square Thru 3/4, ...

So into SD I type:

--> just as they are
--> all 4 ladies chain 3/4
--> heads promenade 3/4, while the others <ANYTHING>

And get:

HEADS promenade 3/4, while the others [???]
Can't do this with these people designated.

Often there are hacks to get around these things, but there's a lot that SD doesn't do very well that makes me think that some near-term process where we can get material in that doesn't necessarily have to be dunned by SD is necessary.

[danlyke]

And the solution to that is "headliners" and "sideliners" for "those in the head position" and "those in the side position", but then we come to SD not having a good "circle up four 1/2" or other fractional circling.

So while it's great to have SD validated choreography, we need to be able to accept other text.

[mpogue2]

Agreed. "headliners", "sidelines" is not great. I never heard any caller use those terms. We could map "those in the head position" --> "headliners" in the VUI, and then go fix it in the GUI later.

But your point is valid -- sd is not the perfect arbiter of correctness. :-)

[danlyke]

Turns out what I really wanted was "head corners". But in any case, I've got a schema for representing this that'd happily include when SD can do what we want, but doesn't mandate it, percolating around.

WIth that in mind: Are we going to store all of this in the same database that we're keeping song metadata in? How are we going to address sharing sequences?

[danlyke]

So now that we've merged the call lists into the main branch (and, dang it, I still need to figure out how to turn off the numbering there), I'm resurrecting the 3 pane system in the danlyke branch. The thing I'm trying to figure out is:

I think that we end up with 3 panes: Library, Sequence or Collection, and Tip. Right now library is my text files of choreography, sequence displays what's in that library, I can move things from that sequence into a tip.

So in that tip, I need to be able to save and restore that, and probably display it in the Lyrics tab. I guess I'm thinking that these end up back in the library? And maybe the library is a tree control with drag and drop? Just pondering organization...

[mpogue2]

I'm not sure that organizing modules in libraries by LEVEL is the cleanest approach. I think modules could be put into containers (for sure), but ultimately each module HAS a level (based on what calls and FASRs are used therein), rather than each module is IN a level.

So, a call is a transformation from one FASR to another. An ordered sequence of calls (where the ending FASR of each call is the starting FASR of the next call) is a Module (which therefore is ALSO a transformation from one FASR to another, typically SS to SS, but it could be SS to ZB, etc.). An ordered sequence of Modules is a Tip. An ordered sequence of Tips is a Dance.

I think that argues for modules living in a database as a pool of modules that have attributes like starting/ending FASR, length, level, and difficulty. Where database COULD be a filesystem, but is probably more likely a real database (so we can query it for all modules meeting some criteria, like level, length, starting/ending FASR, and difficulty).

I think that leads us to several panes:

• a search pane (specify criteria)
• a modules pane (to select)
• a sequence pane (built from modules)
• a tips pane (built from sequences)

The development flow is usually in that order, too, I think. But, the hierarchy is naturally the other way (tips consist of sequences which consist of modules which consist of calls).

I think that argues for doing everything in a DB internally, with the 4 panes as the UX....

Some thoughts...

[danlyke]

Okay, I'm thinking about this a bit more, and trying to develop a schema, at least in my head...

Modules:

• A module is one call or a series of calls that moves from one situation to another.
• A situation is different from a FASR.
• • Facing your corner is the end of a singing call whether it's a Corner Box or that plus a Box the Gnat
• • Invert and Rotate is a zero, but different
• • I want to encode some notation of fractional zeroes
• A module has a beat count
• Modules have some optional notion of hand availability and rotation.
• The editor allows for replacing modules, so that as modules get entered through SD or similar we can evolve. This almost leads to modules needing to be able to contain modules. I'm still thinking about intermediate steps in modules, or maybe that just gets captured in sequences.
• If a call can be mapped to something SD understands, great, but a lot of modules are going to start as just blocks of text (eg: import all of Andy Shore's singing call list). Modules may also have "this is what SD understands, this is what the module text is" (maybe it's calls that have alternatives?)
• Modules have dance programs associated with them.

Sequences

• A sequence is an ordered series of one or more modules
• It has some notion of difficulty and dance program
• It has a beat count. This may be the sum of the module beats, or it may be hand tweaked.

Sequence Collections

I'm still thinking about this. It may be that sequences have collections of tags

Situations

The Callerlab naming looks like:

P = Partner C = Corner O = Opposite R = Right Hand Lady PL = Partner Line (was Zero Line) CL = Corner Line OL = Opposite Line RL = Right Hand Lady Line PLO = Partner Line Out of Sequence CLO = Corner Line Out of Sequence OLO = Opposite Lady Line Out Of Sequence RLO = Right Hand Lady Line Out Of Sequence

CB = Corner Box (was Zero Box) CBO = Corner Box Out (was Corner Box Out of Sequence) RBO = Right Hand Lady Box Out of Sequence (was Across the Street Box) RB = Right Hand Lady Box (RBO + R&L Thru) LRB = Lead Right Box (was Lead To The Right Box)

Swing & Promenade, Allemande Left, Right and Left Grand... all of these are concepts that can have multiple formations.

Also, any of these situations can have 4 rotations.

[mpogue2]

Sounds good to me!

Couple of things to think about:

• It seems to me that a Module is a sequence of calls that represents some transformation. BUT, a call is itself already just a sequence of movements (or sub-calls, if you will) that represents some transformation. So, I think what you said about modules needing to contain modules is already the case! Calls also have starting and ending positions, hand usage, timing, and rotation, just like Modules.
• You might find it interesting to look at CSDS, which apparently has a notion of defining new "calls" (I think by just what their transformation is).
• Taminations also has not only call transformations, but how the dancers get there. You might find it interesting to look at how they encode this.
• It seems to me that the Callerlab naming applies to the entire square, whereas many calls and/or modules and/or sequences can apply just to just part (frequently half) of a square. There's frequently a "who does this apply to" just before a call, that makes a call more specific, or more general. The same might apply to a Module? Would "Heads square thru 4" be a Module, in your thinking?

Anyway, I like your thinking!

[danlyke]

I both love and loathe the "modules are just calls and can contain modules", because SQL sucks for data structures like that. Continuing to think on this.

I'm already looking at the Taminations animation data with an eye towards "if we can figure out what SD thinks is the starting and ending condition play the Taminations data in between...

I'm also trying to let SD do what SD is good at and not try to get in the way, which is why I'm trying to think of this in terms of whole square choreography snippets and not individual moves. As I get deeper into grafting SD into SquareDesk, that attitude may evolve...

[danlyke]

Okay, coming back to this... I need to re-read the thread to reconcile it with my current thinking, but some thoughts of the morning:

Left side: some searching of libraries. I don't yet know how libraries are defined.

Middle top: FASR from and to, a list of modules, and metadata for the selected module. This can be edited. I'm not totally sure how we're going to handle multiple users and the stored central repository. Also not sure how we're going to deal with duplicate data and duplicate sources. "Source" and "Vol" is for typing in from note services, the note service name and then the specific volume...

Right side is the choreography sequence we're building, somehow this stuff gets displayed over in the cuesheet tab.

Click on a range on the right side, and the search from and to at the top of the modules list changes.

Click on a module in the middle and you get to edit the module data. Maybe even retype stuff in the module section (eg: introduce coments, reformat things, not sure). I'm seeing the moduiles as just calls, whereas the right side tab gets calls plus FASR diagrams where we know them.

I'm not sure how to handle from/to specificity: Sometimes I want "partner line to corner box" and I don't care about whether heads or sides are paired on the outsides, sometimes I want "same exact FASR, but rotated 90 degrees"

Just brainstorming out loud, and making sure I keep my brainstorming notes somewhere I can find them.

[danlyke]

Hmmm... Re-reading, I'm liking the Modules + Tips tabs idea, thinking about how to spread this out over the two tabs. That'd give more room to play with search controls. And with some automagic tab switching (maybe select a region in a sequence, right click to flip back over to available modules with from and to search FASRs defined) that could be very usable.

[danlyke]

Oh, also, because playing around with database stuff can leave cruft (the "sync up with the schema" code doesn't delete fields or tables, for instance), I'm trying to figure out if we put this in the song settings database, or elsewhere...