DonationCoder.com Software > Seedling's Software
Hi Everyone / Random MixTape Maker ideas
seedling:
thanks again for the feedback. i'm glad that someone else is using this and really checking it out (and being vocal about it) cuz i'm so used to using it 'my way' i never notice 'strange' behaviour of other methods.
let me explain as best i can in its entirety how this app actually works, cuz you have it partially correct.
DB = directory (an other dirs and sub dirs if recursive checking is on) of audio files
LIST = combined files (either from must have or random picked files)
for this example, i'll use your numbers of max time set to 180min and must-have's set to 120mins
step 1) DB is filled in memory with authenticated, supported media files. (this is only performed again if you change the search directories in order to speed up the process if you want to run it a 2nd, 3rd, etc time)
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)
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.
keywording (by itself) doesn't guarantee that any song with that keyword will be added (that's what the must-have list is for). rather, it is merely another user-defined filter that says 'ok, if the song that has been picked meets this criteria, then add it regardless of other criteria.'
again, perhaps this is just because i'm the only one really testing this for myself. so maybe i need to reword things to make it clear or provide popup hints or something. (which i'd be happy to do).
i'm out travelling until the weekend (but still checking in) so until this weekend i will not be able to make any adjustments.
i hope the above makes sense.
let me know if i can be of any further assistance.
parpfish:
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)
--- End quote ---
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.
seedling:
i can certainly see the benefits of setting things up in the way that you put them; and to that end i will implement (in the next build) an option to use keywords as a priority search. i do not want to make this the default mainly because it defeats the over all randomness of the default app. but it will be implemented as an option if any user chooses to use keywords in such a fashion.
you'll have it by the end of the weekend :)
parpfish:
I really appreciate that! :D :Thmbsup:
Looking forward to it.
Thanks again.
ps. Glad you implimented the WavPack suggestion, as that's how I came across your program via the HA post (http://www.hydrogenaudio.org/forums/index.php?showtopic=59570).
P.
Daleus:
seedling,
Thanks for an excellent bit of software. I have read through the other threads and also want to say thanks on everyone's behalf for being so responsive and helpful in implementing new ideas.
Would it be possible to implement dragging and dropping a playlist onto the blacklist window?
I have a large library of MP3's (don't we all) and I have been tasked to create a collection of compilations from the library. The idea is to come up with a set of CDs.
In order to prevent songs from repeating across CDs in the collection, I have been creating a playlist to fill a CD by time, then moving the songs on the playlist to a seperate folder. From there I drop that new folder onto the blacklist and then proceed to reload the library and make a new playlist - rinse and repeat.
Is there an easier way to do this, for instance, being able to drag and drop a playlist onto the blacklist? Or is there another easier way for me to create a collection of CDs from my library, ensuring the songs are unique from disc to disc?
I realize this may be moving into an area beyond the scope you had planned. If that is the case, no problem - this is still the best "mixing" app I have found and I will continue to use it in the way I outlined above. I just wondered if I had missed a feature or if someone had come up with a clever procedure that might make the task a bit easier.
Thanks again!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version