[pyddr-devel] Level an Difficulty sorting in songselect

[Frank Foeth]

Hi Pavel,

> Sorry for the slow reply. I've been busy.
Don't worry, overall I was too fast, so things came together again.

First some history:
The reason I tried to adapt the current code was because I could not
find level 2 dances (almost all of which are light or basic with the
exception of a few "red" ones). So more than a month ago I quick-fixed
songselect.py. On later inspection, it proved a nice but poorly executed
idea. But I expected other people to have run into the same problem, so
I made some efforts to get decently working code, to which you responded
positively. Now I'm at level basic-4 and I'm still using my hack, not
because it's mine, but because it keeps search time to a minimum, and as
I'm the only user, the difficulty-grade sorting within the level folder
orders the material relatively well compared to the "true" difficulty
(not always though, especially if I try a dance multiple times and
therefore get to good that day).

What I would currently dearly love to incorporate into any selection
interface is a function that objectively establishes the difficulty of a
dance.

Another thing I would like is the ability to find groups of songs with
specific difficulties. E.g. dances with jumps; or songs with rhythmic
difficulties. Currently I can't even see if a dance has jumps, let alone
the number of possible jumps used, etc.

What you wrote below will probably bring the latter closer, but not the
former.

Before I start commenting on what you wrote, I'll add something about
why pydance and not e.g. stepmania.
1. The current interface is more concise and clear (a boon to people
like me), SM's interface is hell for a first time user. 
2. It's written in python and not C or C++, which I consider debugging
hells. I also feel python was a friendly language, but nowadays it's
getting more and more bulky with goodies. On the upside python is very
concise, which aids understanding alien code a lot.

(On the downside pydance is a bit more quirky than SM when dances are
played and the visability of boo and several other comments could be
improved upon. Unfortunately, I'm not the world's greatest designer.)

> The whole issue with not being able to use the "level" or "difficulty"
> sorting modes when folders are turned off got me thinking --- it's
> really intuitive to be able to scroll down to get more difficult steps
> and scroll up to get easier steps. Also, even with folders, there are
> official steps like "Daikenai" that have multiple levels with the same
> difficulties.

We agree. And the latter are a problem in the current implementation.

> Something I think we could do instead is have each song-difficulty
> combination be a separate entry in the song list, when the sort mode is
> "difficulty" or "level". So, without folders, there would be several
> entries for each song, each one with just one difficulty. If we want to
> get really fancy, pressing LEFT or RIGHT (to change the difficulty) will
> move the cursor to the entry with that difficulty.

Just to check that I understand: you want to replace the
songitemdisplays with danceitemdisplays, and link families of the latter
(=song) together to mimic the behaviour currently implemented. 
If this is the proposal, I see no problems.

> While we are at it, we could try implementing "virtual folders" as in
> the TODO file:
> 
>    (Pavel) piman: By the way, here is a feature idea: have a menu that
>            controls which songs are displayed on the list. E.g. "don't
>            display any songs that don't have steps with difficulty less
>            than 6", or something like that.
> 
>    A good way to do this would be something like Evolution's vFolders
>    that let you search for arbitrary criteria. It would also fit okay
>    into the pydance UI ("New Folder", "Add Criteria"...) and current
>    song selector.
> 
>    This would require arbitrary nesting of subfolders, maybe.
> 
>    (Pavel) piman: Makes sense... So an interesting possibility might be
>            to have folders nested to a depth of 3 or so, with top-level
>            folders being what "S" key does right now.
> 
> It shouldn't be too difficult. It would require 3 steps:
> 1) Modify SongItemDisplay to accommodate only displaying a subset of
> steps available for that song in a particular list entry.
> 2) Abstract the songlist display UI from the songlist generation: the UI
> should essentially "walk" a tree of folders and songs given to it.
> 3) Write a routine to generate said "tree".

I read the todo file at some point (not well though), I had a favourable
first impression on the directions you want to take the program in. I
have an article on those virtual folders somewhere, I'll dig it up and
reread it. If your modified SongItemDisplays are my danceitemdisplays, I
understand point 1. The other points should become clear after rereading
the article.
(I do not believe in very radical interface changes though. And unless
the new one is clearly superiour, I feel the old one should remain (or
be replaced by something that mimics the old options).)

As you do not seem to have much time to spend on this, and I nearly
burned away my motivation on the songselect adaptation, I propose to
keep the pacing down a bit. For reasons I won't discuss on a public
list, I can't make promisses as to whether and when anything will be
finished. I'll write a new response after reading about (and hopefully
understanding) virtual folders.

Thanks for the response so far,

Yours,

Frank Foeth