Skip to main content


If you are using a Hotmail or Outlook email address, please change it now, as Microsoft is rejecting all email from our service outright.
Topic: feature request - playlist nesting / grouping (Read 80 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

feature request - playlist nesting / grouping

I'm of the reprehensible persuasion to have my entire library in play on shuffle mode: while there are shortcomings, it keeps me less bored with what's on / coming at any given time. There are, however, often times when I will want to have a different play mode for a specific subset of files, or would want to have different shuffled weighting for a group of files not being played at the frequency I'd prefer (setting tangents on true randomness aside: there are other matters of concern here).
Certain tracks really need to be played in sequence and treated as one file, and while the conventional workaround is to make a file-at-once for those tracks to be played together from beginning to end, that doesn't work as well for all file types (all midi or game rip formats would lose all their usefulness and playback override potentials for one example). Honestly just having a track subset have it's own play mode would be enough for me, it just seems like a very similar pair of features not to bring up together with weighting.
Weighting is admittedly really a  fairly shuffle-mode specific issue, and the workaround would be to add artificial inflation of redundant entries to even out other tracks being played disproportionately often (usually one group having a much larger discography than another with very subtle differences between tracks, causing a larger percentage of a playlist to be one artist's work. While it works to the benefit of diverse playback to keep more tracks in circulation, leaving large discographies with similar tracks in creates that inflation, such that other tracks are played less proportionately without artificial compensation (a messy & untenable solution really with constant maintenance costs as files are added), and the overall selectivity suffers without such measures, or winnowing a large discography to a filtered 'ideal' subset, discluding the variety which may have been otherwise preferable.
My proposed solution would be to allow selections of multiple files to be grouped into a sub-playlist, with it's own selection weight for shuffle playback modes, and a custom playback override setting for the group, such that first the group comes up as a selected entry in the greater track list using the weighting (some default would have to be assumed for any standard track, but this could just be mostly integral math really: count file x as default 1 or [weight] entries, sum the list and average to get the desired ratio), then the subset has it's playback mode to select a file from that list after that is selected.  To the extent that this adds computation time and lag between playback, a next track could be calculated and cached ahead of play while the other tracks are playing: could take some buffer of expected max calculation time for the playlist size and expect a buffer of coming tracks meeting some combined track length to prevent interrupted play, even show the next up and take the playback follows cursor setting into account as some nice feedback.
There's not a whole lot of reason when implementing that much not to allow full nesting of playlists by extension, and it seems easy enough to implement from a file i/o and RNG perspective in either case, though audio certainly isn't my strong point so I don't know if I'm missing something making it a more complicated matter (seems like it would be equally useful for a randomized slideshow from a bunch of images, or any media really, video seems like it would benefit the most honestly).  Mostly I'm guessing it's just unconventional as I haven't seen it done before, as of yet, but I'd also be curious to know what would be a roadblock to adding this (or if I've just been missing something which already exists elsewhere for years).

SimplePortal 1.0.0 RC1 © 2008-2020