[pyddr-discuss] Query setup

[Frank Foeth]

Hi Pavel,

> First of all, it just occurred to me that we already have a sort of a
> filtering mechanism in the Endless mode. We might want to see if we can
> reuse some of that. Even if not, it would make a lot of sense to have
> functionality to play through all the songs in a query in the "Endless"
> mode. But, anyway, here are some thoughts...
I quickly leafed through endless, it seems a bit sparce, and not
particularly generalised. I tried to use it at some point, even hacked
the lists of choices (you didn't receive the hack), but after adding the
level sort I never touched it again, For a beginner it's useless as is.

> With queries, sorting becomes orthogonal to the querying: it makes
> perfect sense, for instance, to get a list of songs at 120-150 bpm,
> sorted by difficulty. However, while it makes sense to have complex
> queries, it doesn't make sense having complex sorting modes. So, maybe
> we should leave sorting to be selected with "s", and have queries be
> controlled by the DDR pad.
OK

> I've read through the document you attached. I am not sure whether I
> agree with the interface. 
I needed something to hook thoughts onto. I think more clearly if I can
envision something. Better ideas are always welcome. (Anyway, there was
a serious error in the interface part of the document and a very
misguided example, sorry.)

> I envision the user first constructing a
> query, and then deciding whether to save it or not. As I imagine it,
> most useful queries would be imposing a series of nested constraints
> over the different aspects of the song. 
Agreed.

> ... So, I think we should borrow our approach from the "drill-down" menu
> that, say, an online store like NewEgg.com uses.
I looked at the site, it could indeed provide a clean interface.

>  For example, here is
> how someone might enter the above query:

> 1) In the song selector screen, showing the query so far and the number
> of songs and dances selected on the left side, and the list of options
> on the right side, the user sees the following options:
> - SHOW
> - BPM
> - ARTIST
> - MIX
> - TITLE
> - LEVEL
> - DIFFICULTY
> 2) User selects "BPM", and is given the following options:
> - EQUALS TO
> - GREATER THAN
> - LESS THAN
> - WITHIN 10 OF
> - WITHIN 20 OF
> - WITHIN 30 OF
> 3) User selects "LESS THAN", and is given some BPM values (e.g.
> multiples of 30).
> 4) User selects "150", and gets the following options:
> - SHOW
> - ARTIST
> - MIX
> - TITLE
> - LEVEL
> - DIFFICULTY
> 5) User selects "LEVEL", and gets the following options:
> - EQUALS TO
> - GREATER THAN
> - LESS THAN
> - WITHIN 1 OF
> - WITHIN 2 OF
> - WITHIN 3 OF
> 6) User selects "EQUALS TO", and is given some difficulty values (0
> through 12).
> 7) User selects "5", and is, again, brought to the top-level menu:
> - SHOW
> - ARTIST
> - MIX
> - TITLE
> - DIFFICULTY
> 8) User selects "SHOW" and is shown the list of dances that match the
> criteria.
> 
> If the user wants to save that query, then maybe the user can go into
> the query menu.
To abreviate your menu idea's:
First menu: Show + song parameters,
2nd: math functions for chosen song parameter
3rd: function parameters to go with 2nd
4th: loop to 1, but delete configured song parameter.
Show starts the current song select screen.
There should also be some way to save a query.

Apart from deleting the configured parameters (people make mistakes and
there is no way to undo them) I understand.

I do have slight problems with it. If songselect were the only
interface, it could be ok, but it isn't: Endless' interface could be
replaced with the same new query interface. I wouldn't like to build
separate query interfaces for both to do the exactly the same thing.

Placing it in songselect will also delete the "giving both players their
separate requests" option, which I would like to retain. There simply
isn't enough space in song selects window to let them both make their
choises simultaneously. 

Also it will further complicate songselects already involved encoding.

Putting the players through to the dance selection parts of the program
is a good idea. This would be troublesome to accomplish in the "like the
configuration option screen" idea.

Apart from where to place it, following your idea I think the user has
more freedom than I had in mind. But it won't look as dawnting to a
user, my interface would look complicated. I distrust the mathematical
capabilities of people a lot, so also in your idea there should be
examples in 5) and perhaps all over the place. And personally I would
like a range type statement added to the math list (especially for
deleting things that are too difficult or too easy in endless.)

To allow interfacing to say endless, I still propose to keep the
entrance to the queries in gameselect, furthermore I would like to see a
few standard queries to choose from within gameselect. In this same list
we could place 'go!' (or 'all') to bypass the queries and 'select' to
enter something along the lines you sketched.

Your ideas don't clash with what I wrote about the query set-up. What I
can do is build a basic query.py keeping in mind the interface, I need
it anyway, so I have to keep more things in mind with it. Building it
should not interfere with discussing the interface.

Yours,
Frank