Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ThatAdamGuy]

I'd like to be able to create a category, say, "mood," and have it set according to other field values.

For instance, if [BMP]>=120 and [intensity]>=3, then mood=upbeat, etc.
Or if [directory] contains "napster" then set [napster]=yes

I admit that this may be a bit complicated, but I think it could be fun and useful

[Hugo_Elbuho]

Putting my 2 cents of support for this idea!

Cheers,

Hugo

[nila]

I've been thinking about this for ages now.

It's a standard db feature to be able to support default values.

Go write this down in the plugin forum and I'll try add it to my ever growing and HUGE list of things to do

[bjsolem]

I'd like to be able to create a category, say, "mood," and have it set according to other field values.

For instance, if [BMP]>=120 and [intensity]>=3, then mood=upbeat, etc.
Or if [directory] contains "napster" then set [napster]=yes

Couldn't you create a smartlist called 'Upbeat" and do most of the same today?

What would you do with the new conditional field?

[rocketsauce]

As bjsolem said, the mood category is already possible to do as either a smartlist or view scheme (just add the appropriate smartlist rules to the filter list in the view schemes properties).

I tried quickly to build a location-based view scheme, but couldn't figure it out, so maybe that's not possible right now. Maybe someone who knows smartlist rules really well knows how it can be done.

Rob

[Hugo_Elbuho]

Sorry if i'm being much techie with this but what i understand from a programmer point of view is that through a smartlist you would have a set of rules to define/name a group of files, but with this new  idea what you would get is field level ruling in a record per record basis.

For instance, taking the above example

 [BMP]>=120 and [intensity]>=3

is a single rule to define a group of files (a.k.a smartlist) called "Upbeat" for instance

But...

When you set a group of rules to set automatically fill a "Mood" field then you would write sort of:

if  [BMP]>=120 and [intensity]>=3, then "Mood" field is "Upbeat"
if  [BMP]<=50 and [intensity]<3, then "Mood" field is "Mellow"
  else  Mood field is "Undefined"

you define rules for each song hence making everybody able to make more queries, smarlists of whatsoever with the new "Mood" field.

You're not just giving a name to the list of files, but defining conditional field naming.

Thanks for reading.

Hugo

[rocketsauce]

Hugo, if I understand what your saying, I think it can still work that way.

So, you build a smartlist called Upbeat based on the rules:

[BMP]>=120 [intensity]>=3

Then say you want a view scheme or another smartlist that is only upbeat songs by a particular artist, you can do (for example):

[Artist]=Madonna [Playlist]=Upbeat

Rob

[xen-uno]

I'm for it, too. Lately, during deep REM sleep, I've been having cloudy visions of the Criteria API rivaling Visual Basic in depth and scope (for similiar functions in a MC context). Will dreams come true?

10^-27

[Hugo_Elbuho]

Thanks for replying, Rocketsauce,

The idea, as i see it, at the beginning, has nothing to do with the smartlist concept which i find to be absolutely marvelous.

Let's concentrate just in the "Mood" field we're hypothetically creating. How would describe/set EACH SONG'S mood you have based on intensity, BPM by using just a smartlist.

What i think is spoken here (as i thought from the beginning of the thread) is a way to set a song's properties.  Smartlists are more like filters which are based on field's properties.  Kind of two diffent things.

And yes... one can build mood filters (smartlists) and name them with the mood's name...  Thanks God!

My final view and summary:

Smartlists: filters.
Calculated fields:  way to set files's properties

Again, sorry for persistance

[LisaRCT]

I'm for it, too. Lately, during deep REM sleep, I've been having cloudy visions of the Criteria API rivaling Visual Basic in depth and scope (for similiar functions in a MC context). Will dreams come true?

10^-27

Huh?

I've just been dreaming of . . . well, ummm....nevermind  


Could this be used to actually make an 'auto-tagging' function for the 'Mood' and 'Situation' type fields??

[Hugo_Elbuho]

You got it ........almost right!.  But since the concept of a calculated field is that it is a field that is not actually stored in the database but instead calculated on the fly and autotagging sounds like creating those fields and writing on them i think thats is not the case.

They would be more like read only fields based on other field's information.

Does this make any sense to you?  

[Doof]

Ok, answer this...

Functionally, what do you gain by having the Mood field calculated the way you describe that you don't get by setting up the smartlist the way others have suggested?

[rocketsauce]

Smartlists: filters.
Calculated fields:  way to set files's properties

Again, sorry for persistance

No problem.

I understand the difference between the two methods, but in the end, if the goal is to be able to easily group tracks based on some criteria (such as [bpm] and [intensity]), the functionality is the same. Isn't it?

And, btw, I'm not saying that there shouldn't ever be an option for conditional fields, but I would rate it as a low priority, especially since there is already a way to do the same thing by using smartlists.
 
Rob

Edit:

And just as an afterthought, maybe something like a "fill property" smartlist rule might be easier to implement:

[bpm]>=120 [intensity]>=3 [fill property]mood=Upbeat

[ThatAdamGuy]

Here's my reasoning / hopes behind my original post (and wow, I've enjoyed all the interesting and useful commentary!)

I am a subscriber to Napster Premium, and with this service I can download as many tracks as I want and integrate them into my personal library, but I can't burn any tracks without first paying 99 cents.  

The Napster WMAs look the same as my other music files, and so it'd be really helpful for me, when making mix CDs for friends, to have a column (NOT a view) that indicates whether a track is from Napster or not.  This way, for instance, on my Christmas Songs playlist, I can quickly assess how many tunes are Napster tracks and, consequently, how much moolah I'd have to shell out if I wanted to burn the playlist as is.

---

A similar issue could be made with my "Mood" request.  In any given playlist, I might want to see, at a glance, how many of the tunes are "upbeat" and so on.

Though I admit, at least from a personal standpoint, the Napster example is more compelling.

[rocketsauce]

So, create a smartlist(s) based on what every "mood" criteria you want. Then select that smartlist, in the Action Window click File Properties then Tag Info and fill in the Mood field, then add Mood as a column in your view(s).

For your Napster files, create a new custom field called Napster (or something else. I use one called Source). Then using the Hard Disk Location view scheme in the tree, navigate to the directory you have them stored in, in the AW click File Properties than Tag Info and fill the field with "yes", then add Napster as a column in your view(s).

It doesn't work as "automatically" as your suggestion, but it's a pretty easy work-around.

Rob

[Hugo_Elbuho]

From a functionality point of view it can be achieved via smartlists, i must admit.

I was thinking of it more from the perspective that a Calculated field definition would be the place to
store other-field-dependant field's rules (like mood or situation in fact) in a centric way. With that, i mean a "just one place" field definition rules as opposed to disperse smartlists.

This way, taking the last example, if later in time, if you decide that songs' mood is not "tuned" correctly because you figured out that mellow songs have a lower BPM or have decided that upbeat songs
are a little bit faster, you just had to go to Mood calculated-field-definition and set it up again in just one place instead of editing each smartlist separately.  

Besides the calculated information wouldn't be actually stored in the db.

Gain in functionality? Maybe not... More organized perhaps.  Object oriented? Yes! ... now... practical? Who knows! It's a matter of taste.

My last try 2 cents

It's one of life's beauties,we've got (thanks God again) many solutions towards solving a single
problem.

Thanks for all the feedback!!

[rocketsauce]

Ahh. I get...kind of...well, not really...what you're saying. ?
Basically you're concept of how conditional fields would/could be implemented is much more complex than my simple this + this = this understanding of what the original poster was describing.

Rob

[Hugo_Elbuho]

  It's ok...  Anyway, big hugs and greetings from Ecuador!