what is probably happening here is that you're putting a space in between the comma and the word. as the code is written now a proper keyword search term would be 'Velvet Underground,Debussy' NOT 'Velvet Underground, Debussy'

i'll have to write some sort of trim-space-between-delimiter code to filter out the natural instinct of placing spaces between commas.

-seedling (December 17, 2007, 06:56 PM)

Ah!  That's solved the major problem I was having -- that explains the bulk of the test results that weren't spot on! Cool, thanks for that.

Have just been running it and it's excellent. So, thanks again -- I'm sure to use RMTM loads - so if any bugs or weirdness crops up I'll let you know.

Have a great Xmas!

P.

Hi Seedling ---

Thanks again for the Keyword Priority Search :D  --- gave it a thorough testing.

Results are here:
http://www.giantpygmy.net/stuff/random_mix_tape_maker_results.txt

Hope they are helpful.

Keep up the excellent work and again congrats on a great program!

P.

Thanks seedling, that's a very clear outline.

Enjoy your travels.

So, I think it's step 4 that creates my particular problem.

I expected the standard KEYWORD search ("Use Keywords" only ticked) to act ahead of Step 4, because as you can see if you only have 60 mins to fill after the MUST HAVE LIST - the chance of a specific KEYWORD SEARCH occuring among the Randomly Chosen files is slim and kind of negates the KEYWORD SEARCH (unless it's extremely general).

step 4) fill the rest of LIST by choosing songs randomly from DB and testing each selected file for user limits (genre, keywords, redundancy, min/max time, min/max size, year, etc) until LIST is 180min (or as close as possible).  this is where setting a min song limit comes in handy.  if you have not set a min song length, then it will continue to cycle throughout the entire DB until the list is EXACTLY 180min or the DB search has been exhausted. so, if you use a min song length of 2min, then if the LIST is at a total of 178.1min it will stop right there, cuz it will know that it is impossible to fill the list to 180 exact because by using even a 2min song, the LIST will be 180.1min (which, of course, is >180). if you have a min song limit of even 1min, it can be helpful, but usually (unless your list happens to be 179.1-179.9min long) it will still cycle thru the entire DB until exhausted.

at this point, you'll see that your 'cowboy junkies' song only stands a chance of being added only if LIST hasn't been completely filled AND that particular song has been randomly chosen in order to be tested against said user limits.

-seedling (December 12, 2007, 10:18 PM)

STEP 2 and 3 are clearly ideal:

"step 2) if the must have list is used fill LIST with the files in the must have list (subject to exclusive keyword and/or redundancy limits)"

step 3) calculate time of files in LIST (if all files in must have pass the above filters (keyword/redundancy(if used)) then this will be 120min)

What I guess surprised me was that after STEP 3 the Keyword Search didn't take priority over the Purely Random selections of STEP 4

i.e. step 3.1) fill the rest of the LIST by choosing songs THAT FULFIL THE KEYWORD CRITERIA randomly from DB and testing each selected file for user limits (genre, keywords, redundancy, min/max time, min/max size, year, etc) until the LIST is full.

step 3 AGAIN) calculate time of files in LIST (if all files in must have pass the above filters (keyword/redundancy(if used)) then this will be 120min)

THEN IF THERE'S ANY SPACE LEFT:

step 4) fill the rest of LIST by choosing songs randomly from DB and testing each selected file for user limits (genre, keywords, redundancy, min/max time, min/max size, year, etc) until LIST is 180min (or as close as possible).


I suppose what this suggests is a 3 tier approach rather than a 2 tier one.

i.e.

1) MUST HAVE (subject to exclusive keyword and/or redundancy limits) TRUMPS
2) KEYWORD SEARCH (subject to user limits - genre, keywords, redundancy, min/max time, min/max size, year, etc) which in turn TRUMPS
3) RANDOM FILES (fill the rest of LIST by choosing songs randomly from DB and testing each selected file for user limits (genre, keywords, redundancy, min/max time, min/max size, year, etc) until LIST is 180min (or as close as possible). 

The benefit of this approach is that the user can tweak many of the limits and Keyword search (which if Boolean would be very powerful) to the point where they can pretty much guarantee the degree of PURELY random files added.

I'll give one example then leave you alone, as I'm sure I've caused you enough of a headache already.

User has 10 files they must have which use up 60 mins:
1) MUST HAVE TOP 10

They want to include some (due to time and other limits) Bach pieces in the key of C Major (this comes to 60 mins):
2) KEYWORD SEARCH = Bach & "C Major" (if there's too many the user can add '& Fugue' and narrow it)

The rest are Random that fulfil the criteria (so clearly if CLASSICAL was not selected in GENRE) then STAGE 2 would yield 0 files.

3) RANDOM = POP & CLASSICAL, less than 5 mins, max play time = 180 mins, etc ....


That would be my perfect RANDOM MIX TAPE MAKER.

Again I hope you'll find this greedy suggestion of interest and helpful. Obviously I am only one person and what I want does not necessarily apply to everyone (or indeed anyone else).

But if you think what I've said makes sense, then please give it some thought.

I'll leave you to your travels.

Best wishes and good luck with this application --- I'm certain that it will become THE ESSENTIAL playlist support application.

Thanks again for your patience and swift attention.

P.