Not sure if anyone except me has a need for this, but it'd sure help me a lot... I'd really like an option in jEmplode (from the right click menu probably) to set playlist properties from the tracks contained within that playlist. The main reason I want it is so I can sort my albums by year within artist folders, but I think it'd also be nice to set the "Source", "Artist", and "Genre" fields for playlists when applicable. Obviously this would only be relevant for playlists which contain tracks inside them, and the algorithm would have to deal with fields that aren't the same inside (for instance, playlist contains tracks from different years, or differnet sources.) But I think it could be as simple as the following and still be very useful for me:

For each playlist in the playlist tree (recursively)
If this playlist contains tracks, examine them
For all fields that have the same value for ALL tracks in the playlist (at this level), change the playlist's field to that value

The second feature, then, is a recursive "set playlist order" feature which, after I run the above feature, could sort recursively sort each playlist based on the value of a chosen field. It'd also be nice if you could choose a 2nd or 3rd field to sort by in case the first fields are equal. Or it could even get fancy and have a specified field for each level of the tree (Artist level sorted by "Title", Album level sorted by "Year" etc.)

So how hard would it be to implement these two features? I think it'd be really great, because with a few clicks, I could sort my entire "Albums" playlist tree by year within each artist. I'm sure it'd have other uses too, but I can't think of any others right now

So whaddya say, Mike?

For soup playlists, RMML (and I think the new jEmplode, but maybe it wasn't in that build) automatically rolls up tags to the playlist level (so an Album soup gets the Artist on it) ... I could make it do that for regular playlists too. It only gets a little funky when you change the tags later ...

Re: playlist order -- also could do that without too much pain. Are these soups or did you make these "by hand"? I've been working on making the soup sorting configurable ... It's still in the works, though.

ms

For soup playlists, RMML (and I think the new jEmplode, but maybe it wasn't in that build) automatically rolls up tags to the playlist level (so an Album soup gets the Artist on it) ... I could make it do that for regular playlists too. It only gets a little funky when you change the tags later ...

Ah, yes. Well I, for one, wouldn't need it to automatically detect changes in the tags underneath, though it'd be swell if it did. For my purposes, a "once and done" approach would work fine.

Re: playlist order -- also could do that without too much pain. Are these soups or did you make these "by hand"? I've been working on making the soup sorting configurable ... It's still in the works, though.

I don't use jEmplode soups yet. These are the playlists that I originally got by dragging my entire "Albums" folder from Windows into Emplode. So it goes <Root>/Albums/<Artist>/<Source>/<Tracks>. So I guess they're basically "by hand." When I add new albums, I drag them into the proper artist folder. I'm guessing soup views would do some of this automagically for me, but I'm not yet using jEmplode as my primary emplode, so I've yet to venture into soups yet. So having this functionality in place for "regular" playlists would be nice, but I will definitely experiment with the soups first to see if those meet my needs.

I would definitely use this - currently I have to remember to copy Artist etc up to playlist.

Hm, tried experimenting with soup views but wasn't finding the results I want...

Desired effect: Two top-level soups: Albums and Singles

"Albums" would contain all tracks that have the "source" field filled out, with layers underneath for artist and album. "Singles" would contain all tracks that don't have the source field filled out, with a layer underneath for genre.

So I figured I could start with a "search layer" to my "albums" soup that would return all the tracks that have a non-null source, then add artist and album layers underneath that. But I can't find a search syntax that does the non-null thing. The advanced search syntax seems to be different than that of emplode. Are searches for null and not null supported? If so, what's the right syntax?

if I had to guess, it would be
source != ""

but I haven't tried that to be sure ... what syntax does emplode support?

Tried that, it says "Missing required operator: There are no more tokens on this line."

Emplode supports (source == null) and (source != null). (Parens used for readability.) If I try that in jEmplode, I think its actually looking for the word "null," as if I did a search for (source == "null") or (source != "null") in emplode.

yeah, technically jEmplode will never give you a null back -- it will give you a "" (otherwise java would print "null" in the columns of the playlist table). I would /think/ you could do (source == "") and (source != ""), but I haven't tried recently.

ms

I would /think/ you could do (source == "") and (source != ""), but I haven't tried recently.

Those aren't working for me in v47.

In emplode, IIRC...

null isn't a special word. It's just treated as another tag name by the parser. Since it doesn't actually exist as a tag name, the query process treats it as the empty string.

The only special tag names (as opposed to operators, e.g. LIKE) are true and false.

For non-equality comparison, != and <> should both work. You can also use the unary not operator, which is also available as !.

When comparing a string value with a boolean, the empty string is treated as false and any non-empty string is treated as true.

Internally, there are two different types of tags: those in the *1 files (and hence in the /empeg/var/database file) are all stored and processed as strings. Those in the dynamic data are treated according to their actual type.

When the tags get to the search functionality, any boolean values in the dynamic data are promoted to strings. If they're true, then they're represented by the string "yes". If they're false, then they're represented by the empty string.

When comparing an integer field with a boolean, any non-zero value is treated as true and tthe zero value is treated as false.

Note that some of this is likely to change as v3.0 approaches stability -- it'll be using the database from the Karma, probably, which does have proper types in it.

The long and the short of it is that, in emplode, you can search for source or not source and it'll do the right thing.

I should have chimed in earlier... but i would LOVE to have the feature Tony brings up so i could have my albums sorted in each band playlist by year. I just now realized as i'm reloading my player i'd have to do it by hand... i guess i figured it was something you could already do.