[pike]

so you dont see anything funny with my screenshots ? i get that <selectedcolor> is used by both 'currently playing' and to show which file cursor is on. but why isnt the highlight of 'currently playing' consistent ?

[kraqh3d]

no. this is by design. the context menu code unhighlights whatever was highlighted, so that only a single item is highlighted (the item that the context menu is going to affect). it then re-highlights the previous item when it closes. you've probably never noticed it before as pm3 didnt really highlight until recently.

please double check this with files view and autoplay next item. if it doesnt do it there, then it can be changed.

[pike]

im very sharp with logic. please see my screenshots one more time darkie /and the descriptions thx

[reddington]

- "freshen"... i really like this idea but i have some questions... first, what should the context menu option be called? "freshen" doesn't cut it for me. "refresh songs"? something else? where should it place songs? should it always put its songs beneath the currently playing song, or should they go beneath the last user added song if there are any? and how many songs should it add? 10?

i think 'refresh songs' is good. and i think it should simply remove all non-user queued songs from list (random songs) and fetch an entirely new set. it should definitely leave the user-queued songs as is imo... and just 'freshen' up the random ones. it would be kind of fun to keep hitting that and seeing what songs it grabs.

[kraqh3d]

pike.
lemme double check this when i get home. something is wrong with your screenshots, but i have never experienced anything like what you've shown. the current song is highlighted at window open. on context menu, the item changes. on context menu close, the highlight is restored.

[kraqh3d]

reddington... i was thinking of that too. it should probably remove any random songs, and add in a new set of random songs.

[Loto_Bak]

regarding 'refreshing'. any songs removed should be added to the history table in the db.
expanding on that idea, random entries that are removed should be added to the history so that they do not appear again.

regarding filtering by genre kraq... is there a specific reason it needs to be limited to only genres? i also think the 2nd highlighting method is clumsy.
simplicity is the key for any feature. having a one-touch partymode button is very useful. i think context menu items 'exclude these entries from party mode' and 'prefer these entries for party mode' would accomidate virtually all posibilities. prefered songs would be used until all prefered entries are used. excluded entries would never be played.

i am unsure of the current status of the overlay image development in listmode, but if it works well i think an overlay would be the best method to show users what is prefered or excluded.

just brainstrorming
tanks
dean

[kraqh3d]

regarding 'refreshing'. any songs removed should be added to the history table in the db.
expanding on that idea, random entries that are removed should be added to the history so that they do not appear again

that's not a problem. it's not a history of "played" songs, but of "picked" songs. the song is added into the history when its picked. while the history is now keeps a full history from when party mode is enabled, it still only being used to prevent repeats over the last 25 songs. (this will be tweaked later.)

regarding filtering by genre kraq... is there a specific reason it needs to be limited to only genres?

because its the first iteration of filtering and quite frankly, thats all i feel like doing. this requires more thought. allowing more than one filter type adds complexity. with to filter types, you can easily set up a filter that no songs will match. (you are more than welcome to submit patches to extend its functionality, however.)

i also think the 2nd highlighting method is clumsy.

i'm not really sure if you're refering to what pike is talking about, or the highlighting of genres as the visual indicator of whats allowed in party mode.

simplicity is the key for any feature. having a one-touch partymode button is very useful. i think context menu items 'exclude these entries from party mode' and 'prefer these entries for party mode' would accomidate virtually all posibilities. prefered songs would be used until all prefered entries are used. excluded entries would never be played.

sorry but no. an option to "prefer" certain genres will not be added yet. for now, it'll be a simple "allowed" and "not-allowed" option. that's it. (again, you're more than welcome to submit a patched to extend the functionality.)

putting these options in the context menu to enable the filtering is trivial. how to visually display this to the user is what's under question. i'm thinking the highlighting option would probably be a rather ugly way to do it, but it is the easiest to implement. i' really leaning towards just placing an * in the right column, since the right column is unused at the genre listing.

i am unsure of the current status of the overlay image development in listmode, but if it works well i think an overlay would be the best method to show users what is prefered or excluded.

yes, but today there are no overlays in listview, so this is not an option yet.

[jmarshall]

this is imo how "filtering" should be done for party mode:

smart playlists.

basically a smart playlist consists of an sql where clause that we can pass to the database to get a directory listing which gives a subset of the songs in the database to work from.

i've done a very small amount of work on this, but what i forsee in the short-term is:

1. loading of the sql query via an xml playlist file.

2. structure of the playlist is a set of rules laid out as follows:

field operator parameter

field is the search field in the database (eg genre, artist, year etc.)

operator is the matching condition (eg contains, doesn't contain, is, is not, starts with, ends with, in range etc.)

parameter is the matching parameter.

3. there is more than 1 rule available, and they're either anded together (ie match all of the following) or ored together (match one of the following).

<rule field="genre" condition="contains">parameter</rule>

probably suffices, along with a small amount of heading info (ie whether to and or or and the name of the playlist).

4. once these are present, the user can simply choose ("party mode from here") from a playlist, or from the library.

the above doesn't include "preference" conditions as yet, but they can probably be added to the operator field i believe.

i'm happy to keep cracking at this (currently i'm working on the translation of the rule sets to sql where clauses suitable for our database lookup.)

once we have the playlists loading + listing from the xml files, we can easily add the gui stuff to set them up later.

cheers,
jonathan

[kraqh3d]

i disagree with this. party mode and smart playlists are completely seperate concepts. a playlist, regardless of how its defined, is nothing more than a list of songs to be played. a smart playlist which is nothing more than a sql query which defines the playlist. yes, its an excellent idea, but its still just a playlist.

now, while some of the concepts are similar, party mode is different. it's a jukebox -- not a playlist. songs are picked and played. songs can repeat before all songs are exhausted. and most importantly, when the user adds songs, they are at the top of the list, not at the end of the list.

however, this is not to say that the same technique could not be used to define the ruleset for picking the random songs. how to gui'ify the ruleset is the hardest part of allowing a filtering schema. filtering by genre was just going to be the first iteration of such a system.

[jmarshall]

yes, party mode is a jukebox that plays random tracks (sometimes repeating) from a music source.

that source currently is the entire music library. it's nice to limit the source sometimes - and limiting it to the contents of a smart playlist seems the obvious way to do things. not only is it as general as you can get, but it's also natural to have some idea of the list of songs you are playing from - i would think if a user often wished to place a certain restriction on party mode, then that restriction may often be the same (fitting with having that restriction "saved" in some form - ie a list of songs).

we don't have to call it a playlist but it seems to me to be the ideal way to get it done.

i have some ideas for the gui side of it - but obviously that's for after the feature freeze. as you know, it's tricky to get it efficient with a virtual keyboard!

cheers,
jonathan

[jmarshall]

ok, as an example of what can be done with smart playlists as the base, i've added to cvs filtering via the xml file system/partymode.xml

the xml file is a smartplaylist, but it's only enabled for party mode.

the one in cvs does nothing at all, but has some examples in it.

format is as follows:

<smartplaylist>
<name>party mode</name>
<match>all</match>
<rule field="artist" operator="is">u2</rule>
<rule field="year" operator="lessthan">1985</rule>
</smartplaylist>

the above obviously grabs any u2 pre-85.

the allowed fields are "genre", "artist", "album", "year", and "title". we can easily add more though.

the allowed operators are "is", "isnot", "contains", "doesnotcontain", "startswith", "endswith", "lessthan", "greaterthan".

the <name> tag is not important at this stage - that'll be used for smartplaylists.

the <match> tag can be "all" or "one", indicating whether all must match or just one.

i haven't tested it that rigorously - that's what you guys are for

one thing you will note is that large queries will take longer to return the songs initially - not sure what can be done to optimize that at this point.

cheers,
jonathan

[kraqh3d]

@pike
there was one discrepency with the highlighting during party mode which i've corrected. now the normal now playing, party mode now playing, and files with autoplay next item should all behave exactly the same, as follows (whether or not this is "correct" is another matter):

- currently playing song is always highlighted.
- on context menu open, the selected item is also highlighted
- on context menu close, the selected item is un-highlighted

@jmarshall
i'll have a go with it tomorrow. the code was already setup to support filtering so i hope you were able to integrate this addition rather easily. (that was the intention, anyway.)

i agree that filtering is a necessary evolution but there was another thing which needed to be addressed first -- the history. today its fixed at 25 songs, and theres a song minimum set at double this history size. you can now filter party mode such that it wont start.

[pike]

did a bit of brainstorming on how one could make the filter options in ui

have a scroller that shows the current "ruleset" by default, then a menu:

set restrictions:
--
add/edit/remove
item <2 of x>
-rule field: <list>
-operator: <list>
-data: <input>

then when you select an item to edit it shows this in the ever present /scroller/

anyway just an idea since obviosuly we cant list all items and have separate edit options for them

[pike]

i am unsure what is supposed to happen with party mode when you queue a file from 'files' view, but here i get this:

(focused is the manually queued object)

as you can see 11 objects now and pm mode still active by the looks (disabled menu)

i also experienced some very weird behaviour when adding a song manually from a cuesheet (files view), have you tested this ?