HydrogenAudio

Hotness is an algorithm that generates a score on a scale of 100 for every song in your library.  It weighs frequency of play, rating, and recentness of last play against each other to determine how "hot" a song is.  Because of its complex nature, its use of an absolute scale, and its awareness of time, it offers a unique alternative to other approaches to meta-rating (such as playcount × rating).

[!--sizeo:3--][span style=\"font-size:12pt;line-height:100%\"][!--/sizeo--]Update: 18Aug2007 1.7.c
[/size]
Lines 14-18 allow for easy alteration of which playback statistics tags to use.  Default baselines have been greatly increased too, just because I find they work best for me.  As always, experiment with them.

• Paste into Columns UI's "Globals" tab in the Playlist view options
• Requires foo_cwb_hooks (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components_0.9/Cwbowron%27s_Title_formating_%28foo_cwb_hooks%29) to calculate date differences, and to automatically add %added% tag to newly imported tracks (under Tools/New File Tagger in Preferences)
• Retrieve with $get_global(hotness)

Should work right out of the box for most setups, please let me know in this thread if there's anything I've overlooked or screwed up.

///////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// v1.7.c (foo_cwb_hooks version)
// July 8, 2007 - by topdownjimmy@gmail.com
///////////////////////////////////////////
//
// configure baselines: define baseline playfrequency and decay period (in days)
//
$puts(baselinefrequency,90) // decrease if songs stay hot too long, or: high to accentuate success, low to accentuate recentness
$puts(baselinedecay,28) // decrease if too many songs are hot, or: high to accentuate success, low to accentuate recentness
//
// configure playback statistics
//
$puts(lp,[%last_played%])
$puts(fp,[%first_played%])
$puts(pc,[%play_count%])
$puts(rating,[%rating%])
$puts(avgrating,3)
//
// DO NOT EDIT BELOW THIS LINE //
$puts(baselinefrequency,$mul($get(baselinefrequency),24))
$puts(baselinedecay,$mul($get(baselinedecay),24))
$puts(lp_age,$add($substr($get(lp),12,13),$mul(24,$cwb_datediff($get(lp),2000-01-01))))
$puts(fp_age,$add($substr($get(fp),12,13),$mul(24,$cwb_datediff($get(fp),2000-01-01))))
$puts(age,$sub($get(lp_age),$get(fp_age)))
$puts(now_age,$add($substr(%cwb_systemdatetime%,12,13),$mul(24,$cwb_datediff(%cwb_systemdate%,2000-01-01))))
$puts(recentness,$sub($get(now_age),$get(lp_age)))
$puts(decay,$div($div($mul($get(pc),$get(baselinefrequency),$get(baselinedecay),$if2($get(rating),$get(avgrating)),100),$mul($max($get(age),$get(baselinefrequency)),$get(avgrating))),100))
$puts(rawhotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))
$puts(forecast,$div($mul($max($sub($get(decay),$add($div($max(0,$sub($get(baselinedecay),$get(recentness))),2),$get(recentness))),0),100),$get(decay)))
$puts(hotness,$div($add($get(rawhotness),$get(forecast)),2))
$set_global(hotness,$get(hotness))
// END HOTNESS //

And here's a single-line version to be used in foo_playlist_tree (http://www.hydrogenaudio.org/forums/index.php?showtopic=29435).  Put it into the "Population Order" field in a query, and limit to 20 (or whatever) subfolders.

$puts(baselinefrequency,45)$puts(baselinedecay,28)$puts(lp,[%last_played%])$puts(fp,[%first_played%])$puts(pc,[%play_count%])$puts(rating,[%rating%])$puts(avgrating,3)$puts(baselinefrequency,$mul($get(baselinefrequency),24))$puts(baselinedecay,$mul($get(baselinedecay),24))$puts(lp_age,$add($substr($get(lp),12,13),$mul(24,$cwb_datediff($get(lp),2000-01-01))))$puts(fp_age,$add($substr($get(fp),12,13),$mul(24,$cwb_datediff($get(fp),2000-01-01))))$puts(age,$sub($get(lp_age),$get(fp_age)))$puts(now_age,$add($substr(%cwb_systemdatetime%,12,13),$mul(24,$cwb_datediff(%cwb_systemdate%,2000-01-01))))$puts(recentness,$sub($get(now_age),$get(lp_age)))$puts(decay,$div($div($mul($get(pc),$get(baselinefrequency),$get(baselinedecay),$if2($get(rating),$get(avgrating)),100),$mul($max($get(age),$get(baselinefrequency)),$get(avgrating))),100))$puts(rawhotness,$div($mul($max($sub($get(decay),$get(recentness)),0),1000),$get(decay)))$puts(forecast,$div($mul($max($sub($get(decay),$add($div($max(0,$sub($get(baselinedecay),$get(recentness))),2),$get(recentness))),0),1000),$get(decay)))$num($div($add($get(rawhotness),$get(forecast)),2),4)

Log[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]

1.7.c, 8Jul2007
-easy alteration of which playback statistics tags to use
-other minor cleanup

1.6.c.1, 6Dec2006
-improved softening technique to avoid spikes in hotness

Update 11Mar05
-added hourly decay version
-oops, updated again for hourly decay bugfix

Update 09Mar05
-added alternate %play_date% version

Update 22Feb05
-fixed avgrating bug

Update 18Feb05
-"begin decay immediately" is now optional
-uses new LAST_PLAYED standard (http://www.hydrogenaudio.org/forums/index.php?showtopic=20719)
-if an %added% tag is absent, it assumes the baseline frequency for the song
-configurable "default rating" (assumes default rating when there is none)
-plan to employ FIRST_PLAYED standard once it's implemented

Code updated 10Feb05
-decay now begins immediately rather than the day after last play

[/size]
History/Approach (some info outdated)[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]

Before using this code, remember that three tags are NECESSARY for it to work: %first_played%, %last_played%, and %play_counter%, provided by foo_playcount 1.9.2 (http://stephan.kochen.nl/proj/foobar2000.html#playcount)

%rating% will also affect things, but isn't essential.


So I had this idea that there are a number of statistics contained within each one of my tracks that are related to the overall "hotness" (or "popularity" or what have you) of a song: %play_counter%, %rating%, %last_played%, and %first_played%.  But no algorithm had been designed yet that would weigh all of those factors in the calculation of one single score that measures what I'm calling "hotness."

Rating is all fine and dandy, but it's so cut and dry.  Same goes for last_played and play_counter.  They're such dead, linear statistics that aren't very interesting to me to watch at all.  And play_counter is rendered meaningless unless it's compared to how long a song's been in your library.  Complexity was the goal of this idea, the dynamic generation of a song's overall...SOMETHINGness that I couldn't easily predict.  It does no good to tell me that I rated a song 5 stars.  I know I did, I was there.  And keep in mind, this isn't about determining a song's quality or "goodness"; goodness is given by rating.  Hotness is something much more interesting, and I hope I'm on my way to a satisfactory representation of it.

To begin, I believe the importance of these factors in decreasing order is:
-recentness of last play
-overall frequency of play (play_counter ÷ days since added ("age"))
-rating

When a song is played, its hotness should be given a boost (the amount of this boost is detailed below).  As time passes since the last time a song was played, that song's hotness should decrease.  So now we've got to define a decay period: the time it takes before a song's hotness dwindles to 0 again.  The two factors that determine the length of this decay period are rating and play frequency.

The definition of this decay period depends on two lengths of time: baseline FREQUENCY and baseline DECAY.  In the code below, baselinefrequency is set at 14 days and baselinedecay at 6 days.  But, depending on your listening habits, you may need to alter these settings.  The effect the settings have isn't immediately intuitive, but a good rule of thumb is:

-the more often you listen to music, the LOWER baselinedecay should be
-the more variety of music you listen to, the HIGHER baselinefrequency should be

Setting baselinefrequency to 14 and baselinedecay to 6 means that a song played on average once every 14 days will decay to 0% hotness 6 days after it's played.  If a song is played TWICE every 14 days, its decay period will DOUBLE (12 days).  If a song is played once every 28 days, its decay period will halve (3 days).

Likewise, rating will affect a song's decay period.  The absence of a rating will assume a default rating of 3.  A rating of 5 will multiply the decay period by 5/3, and a rating of 1 will multiply the decay period by 1/5.

The initial boost of playing a song used to be 100% hotness.  This made for boring playlists when looking at songs that were played "today," so in the current code, the immediate hotness is what the hotness would be TOMORROW if the hotness were to go up to 100% today.  This makes for some interesting effects; for instance, my settings make it so that a song added today and played once today begins at a hotness of 83%.  If I play it again today, I then double its play frequency, thus doubling its decay period, thus boosting its hotness.

Here's the code:

/////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// %last_played% version
/////////////////////////////////////////

// baselines: define baseline frequency and decay periods
//
// baselinefrequency: decrease if songs stay hot too long
// baselinedecay: decrease if too many songs are hot
//
$puts(baselinefrequency,14)
$puts(baselinedecay,7)

// begin decay immediately? (1=yes, 0=no)
$puts(begindecaynow,1)

// default rating for unrated songs
$puts(avgrating,3)

// calculate "age": the number of days the song has been in the library
$if(%added%,
$puts(age,
$sub(
$add(
$mul($right(%_system_year%,2),365),
$select(%_system_month%,0,31,59,90,120,151,181,212,243,273,304,334),
$ifequal($mod(%_system_year%,4),0,$ifgreater(%_system_month%,2,1,0),0),
%_system_day%
),
$add(
$mul($substr(%added%,3,4),365),
$select($substr(%added%,5,6),0,31,59,90,120,151,181,212,243,273,304,334),
$ifequal($mod($substr(%added%,1,4),4),0,$ifgreater($substr(%added%,5,6),2,1,0),0),
$right(%added%,2)
)
)
),
$puts(age,$mul(%play_counter%,$get(baselinefrequency)))
)

// calculate "recentness": number of days since song was last played
$puts(recentness,
$sub(
$add(
$mul($right(%_system_year%,2),365),
$select(%_system_month%,0,31,59,90,120,151,181,212,243,273,304,334),
$ifequal($mod(%_system_year%,4),0,$ifgreater(%_system_month%,2,1,0),0),
%_system_day%
),
$add(
$mul($substr(%last_played%,3,4),365),
$select($substr(%last_played%,6,7),0,31,59,90,120,151,181,212,243,273,304,334),
$ifequal($mod($substr(%last_played%,1,4),4),0,$ifgreater($substr(%last_played%,6,7),2,1,0),0),
$substr(%last_played%,9,10)
)
)
)

// calculate "decay": the specific decay period
$puts(decay,$div($mul(%play_counter%,$get(baselinefrequency),$get(baselinedecay)
,$if2(%rating%,$get(avgrating))),$mul($max($get(age),$get(baselinefrequency)),$get(avgrating))))

// calculate "hotness"
hotness=$div($mul($max($sub($get(decay),$add(
$get(recentness),$get(begindecaynow))),0),100),$get(decay))

//////////////////////////////

For compatibility with foo_playcount's default play_date settings:

/////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// %play_date% version
/////////////////////////////////////////

// baselines: define baseline frequency and decay periods
//
// baselinefrequency: decrease if songs stay hot too long
// baselinedecay: decrease if too many songs are hot
//
$puts(baselinefrequency,14)
$puts(baselinedecay,7)

// begin decay immediately? (1=yes, 0=no)
$puts(begindecaynow,1)

// default rating for unrated songs
$puts(avgrating,3)

// calculate "age": the number of days the song has been in the library
$if(%added%,
$puts(age,
$sub(
$add(
$mul($right(%_system_year%,2),365),
$select(%_system_month%,0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($right(%_system_year%,2),4),$if($or($greater(%_system_month%,2),$greater($mod(%_system_year%,4),0)),1,0)),
%_system_day%
),
$add(
$mul($substr(%added%,3,4),365),
$select($substr(%added%,5,6),0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($substr(%added%,3,4),4),$if($or($greater($substr(%added%,5,6),2),$greater($mod($substr(%added%,1,4),4),0)),1,0)),
$right(%added%,2)
)
)
),
$puts(age,$mul(%play_counter%,$get(baselinefrequency)))
)

// calculate "recentness": number of days since song was last played
$puts(recentness,
$sub(
$add(
$mul($right(%_system_year%,2),365),
$select(%_system_month%,0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($right(%_system_year%,2),4),$if($or($greater(%_system_month%,2),$greater($mod(%_system_year%,4),0)),1,0)),
%_system_day%
),
$add(
$mul($substr(%play_date%,5,6),365),
$select($substr(%play_date%,3,4),0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($substr(%play_date%,5,6),4),$if($or($greater($substr(%play_date%,3,4),2),$greater($mod($substr(%play_date%,5,6),4),0)),1,0)),
$substr(%play_date%,1,2)
)
)
)

// calculate "decay": the specific decay period
$puts(decay,$div($mul(%play_counter%,$get(baselinefrequency),$get(baselinedecay),$if2(%rating%,$get(avgrating))),$mul($max($get(age),$get(baselinefrequency)),3)))

// calculate "hotness"
hotness=$div($mul($max($sub($get(decay),$add($get(recentness),$get(begindecaynow))),0),100),$get(decay))

//////////////////////////////

And an hourly decay version...this version does not include the "begin decay immediately" option because decay will begin in an hour anyway.

/////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// hourly decay version
/////////////////////////////////////////

// baselines: define baseline frequency and decay periods
//
// baselinefrequency: decrease if songs stay hot too long
// baselinedecay: decrease if too many songs are hot
//
$puts(baselinefrequency,14)
$puts(baselinedecay,7)

// default rating for unrated songs
$puts(avgrating,3)

// convert baselines to hours
$puts(baselinefrequency,$mul($get(baselinefrequency),24))
$puts(baselinedecay,$mul($get(baselinedecay),24))

// calculate "age": the number of hours the song has been in the library
$if(%added%,
$puts(age,
$sub(
$add(
$mul(
$add(
$mul($right(%_system_year%,2),365),
$select(%_system_month%,0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($right(%_system_year%,2),4),$if($or($greater(%_system_month%,2),$greater($mod(%_system_year%,4),0)),1,0)),
%_system_day%
),
24
),
%_system_hour%
)
,
$mul(
$add(
$mul($substr(%added%,3,4),365),
$select($substr(%added%,5,6),0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($substr(%added%,3,4),4),$if($or($greater($substr(%added%,5,6),2),$greater($mod($substr(%added%,1,4),4),0)),1,0)),
$right(%added%,2)
),
24
)
)
)
,
$puts(age,$mul(%play_counter%,$get(baselinefrequency)))
)

// calculate "recentness": number of hours since song was last played
$puts(recentness,
$sub(
$add(
$mul(
$add(
$mul($right(%_system_year%,2),365),
$select(%_system_month%,0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($right(%_system_year%,2),4),$if($or($greater(%_system_month%,2),$greater($mod(%_system_year%,4),0)),1,0)),
%_system_day%
),
24
),
%_system_hour%
)
,
$add(
$mul(
$add(
$mul($substr(%last_played%,3,4),365),
$select($substr(%last_played%,6,7),0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($substr(%last_played%,3,4),4),$if($or($greater($substr(%last_played%,6,7),2),$greater($mod($substr(%last_played%,1,4),4),0)),1,0)),
$substr(%last_played%,9,10)
),
24
),
$substr(%last_played%,12,13)
)
)
)

// calculate "decay": the specific decay period
$puts(decay,$div($mul(%play_counter%,$get(baselinefrequency),$get(baselinedecay),$if2(%rating%,$get(avgrating))),$mul($max($get(age),$get(baselinefrequency)),3)))

// calculate "hotness"
hotness=$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay))

//////////////////////////////

Paste into the "Variables" tab under the "Globals" tab in Columns UI settings, and make sure that "Make date info available" and "Use global variables for display" are both checked.  Now you are free to use %_hotness% anywhere in your columns!  It will appear on a scale of 100.  Because this statistic is so effluvial, I think it will be best depicted in color, perhaps as a shade of red on a dot.  To do this, create a column with ● as the display, check "Use custom colour spec," and in the "Colour" tab, type:

$blend(FFFFFF,0000FF,%_hotness%,100)|
$blend(FFFFFF,0000FF,%_hotness%,100)|
FFFFFF|
FFFFFF

You will, of course, have to change some of those colors to match your other colors.

Here's how things look for me:

[a href=\"http://img104.exs.cx/my.php?loc=img104&image=clipboard014hh.png\" target=\"_blank\"][/color][/size]

I read through rather quickly, but the topic is interesting. I personally love the extended playlist generator, and I've been using a simple weighted sorting for my generated charts, for some time now. The reason I started doing this, was as you mentioned, that rating and play count alone, isn't always that interesting. Some songs are really good, but at the same time of the kind I don't listen to that often (e.g. Eric Clapton). Hence, I don't want them to be at the top of my charts. So, what I did was pretty simple, but it still worked out pretty well for my usage and current play counts.
The sorting code is this:

$sub(1000,$add(%PLAY_COUNTER%,$mul(%TRACKRATING%,2)))|$sub(5,$meta(trackrating))|$rand()

For short: Every rating point, counts as two play count points when these two tags are added. If two tracks gets the same total, they are sorted by rating. The ones that are still in the same group are randomized to avoid alphabetic influence.

To me it's really important that such a scheme can be used and works well, with the playlist generator. That makes it easy to update and to limit the number of entries. I also like to keep my column headers disabled, so to me, using them for sorting isn't really an option.

But, I would find a more sophisticated solution than the one I use, interesting, as long as it's still sensible. The code you (topdownjimmy) posted, looks rather slow for larger databases, but I haven't tested it yet, as it produced SYNTAX ERROR.

[Very personal opinion]
I have never understood the desire to start out with a default rating of e.g. 3. At first when I started rating my tracks, I used three levels and struggled with that. Now I use five, and all of them are different degrees of positive. I use them something like this:
5: Goosebumps
4: Very good
3: Good
2: Quite good
1: Stands out (from the masses)

If you need to mark some crappy tracks, add a %crap% tag or something, and use that to apply red color or skip them with foo_skip (havent' verified that that actually works). Going below average to rate for two degrees of crappyness, just doesn't make sense IMHO.
[/Very personal opinion]

Edit: typo

To me it's really important that such a scheme can be used and works well, with the playlist generator.

Yes, unfortunately my hotness scale can't be used in the epg.  The epg is disappointing in that way.  In my globals I define recentness to be usable by strings in the columns, but I can't use those globally defined variables in epg.  Is there a reason for that?  Can someone fix that?, because that would be incredible (how do you generate a playlist of songs you've listened to in the last two weeks?  CAN you?)

But, I would find a more sophisticated solution than the one I use, interesting, as long as it's still sensible. The code you (topdownjimmy) posted, looks rather slow for larger databases, but I haven't tested it yet, as it produced SYNTAX ERROR.

It may be slow, I haven't noticed yet (but then I don't tend to pay attention).  Not sure why you're getting a syntax error.  The second code box isn't valid code, I just threw that together as an illustration, but the first one should work.  I'll see if I can figure it out.

[edit]I found a stray parenthesis (the very last one).  Fixed it above.[/edit]

[Very personal opinion]
I have never understood the desire to start out with a default rating of e.g. 3. At first when I started rating my tracks, I used three levels and struggled with that. Now I use five, and all of them are different degrees of positive. I use them something like this:
5: Goosebumps
4: Very good
3: Good
2: Quite good
1: Stands out (from the masses)

For me it makes sense because I tend to listen to full albums rather than singles or random order, so I do have (and listen to) a lot of songs that I don't like.

[edit again]I wanted to add that the reason I'm doing it this convoluted way is to take recentness into account.  Under your scheme, the fact that I played a song just two days ago doesn't bump it up in the "charts."  I'd like recent plays to "bump" songs.  This will also cover the situation in which I listen to a song 100 times in one day, then don't listen to it for a whole year.  I don't want that song on my "charts" anymore.[/edit again]

Yes, of course my simple solution doesn't come close to yours, as I can't take the time since the last play into account when weighting.

As you noted, "time/date" info isn't available "globally", and is added by each plugin individually. Not really an ideal situation, IMHO, but I don't know if there is a good reason for it. If there isn't, then I hope it could be added at some point.

No wonder your code doesn't work here, even after you fixed it, as I don't use %added% and I might also use another %play_date% format (didn't bother to check). In addition I use %JULIAN_DATE% as my second tag, so I don't have room for %added%.

I really like the idea of what you're doing, but I just don't see anyway I would be able to start using it myself (lack of epg support and no room for another foo_playcount tag).


Edit: rewrote the first part as it didn't make sense.

As you noted, "time/date" info isn't available "globally", and is added by each plugin individually. Not really an ideal situation, IMHO, but I don't know if there is a good reason for it. If there isn't, then I hope it could be added at some point.

Let's hope so. 

No wonder your code doesn't work here, even after you fixed it, as I don't use %added% and I might also use another %play_date% format (didn't bother to check). In addition I use %JULIAN_DATE% as my second tag, so I don't have room for %added%.

%added% is something I add manually whenever I import new music.  If it was done by foo_playcount, it would update every time it was played (not what I want).

I really like the idea of what you're doing, but I just don't see anyway I would be able to start using it myself (lack of epg support and no room for another foo_playcount tag).
[a href="index.php?act=findpost&pid=271385"][{POST_SNAPBACK}][/a]

Yeah, this was more of a distraction and a challenge than anything else.  Right now I'm just implementing it as a colored dot, playing around with different decay settings and whatnot and seeing if the resultant hotness "feels" correct.  Not an extremely useful measurement (or at least, not until playlistgen integrates with columnsui) but still fun.    I'm looking forward to watching the hotness decay, since it's going to be a parabolic change, not linear (the more time passes, the more the hotness decays, the lower the play frequency gets, the shorter the decay period gets....)

edit: oh I just edited it, okay????

%added% is something I add manually whenever I import new music.  If it was done by foo_playcount, it would update every time it was played (not what I want).[a href="index.php?act=findpost&pid=271389"][{POST_SNAPBACK}][/a]

Of course... 

Very interesting idea indeed.

topdownjimmy, did you achieved a good result with this method? Do high rated song actually correspond with songs that are "hot" ?

Very interesting idea indeed.

topdownjimmy, did you achieved a good result with this method? Do high rated song actually correspond with songs that are "hot" ?
[a href="index.php?act=findpost&pid=271395"][{POST_SNAPBACK}][/a]

Well, I'm working on it.   

Like I said, how "correct" it is is very dependent on the baseline frequency/decay settings you give.  Right now I'm liking 14/14 (a play frequency of once every two weeks yields a decay period of two weeks).

I also changed the algorithm a bit, and I like my new system better.  The old way that rating was incorporated into hotness was as a limiting factor, to set a "ceiling" for a song's hotness.  2-star songs could NEVER get above 40% "hot."  That didn't sit right with me, I feel like if a song is played TODAY then its hotness should be 100% today.  The way rating affects hotness now is by altering the length of the decay period.  So, for example, if I play two songs today, and if both have the same frequency, but one is rated 1 and the other is rated 5....their hotness will be at 100% right after play, but the 1-star song will decay 5 times as fast as the 5-star one.  Meaning, the 5-star song will be hot longer than the 1-star one.  This makes more sense to me.

Here's my current code:

(code removed.  the most recent code will always be at the top of this thread.)

If you want to know if it works just try it out.  Just paste the code into your globals, add a column for %_hotness% and see how the figures come out.  But remember, %play_count%, %play_date% and %added% (both YYYYMMDD) are ESSENTIAL tags for this to work.  Rating is not (but it helps).

edit: deleted entire post, because it became irrelevant due to an overhaul of the first post.

Very interesting. I'll surely give a try to it. I've also thought about doing some formatting stuff like that, but as you did it before me, I'll use it

In my globals I define recentness to be usable by strings in the columns, but I can't use those globally defined variables in epg.  Is there a reason for that?  Can someone fix that?, because that would be incredible [a href="index.php?act=findpost&pid=271379"][{POST_SNAPBACK}][/a]

Absolutely incredible

I hope no one minds that I'm "bumping" this thread.  I've made a lot of changes to the algorithm, and the results are much better (I believe).  Small improvements may still be made in the future.  I believe that once %_system_date% tagz are implemented in playlistgen and trackinfo, this will be very useful code to have.

topdownjimmy and i have been communicating recently, basically to help me with this crazy columns_ui, and i kinda have it working.  not quite how he uses it, but it gives me sweet info and everything.  i like to see the numbers too, as colors can be too close to tell a difference (75 and 80 in my screenshot, for instance, are rather close together).

i'm not hip to the rules here, so here's a link to a screenshot (http://img.photobucket.com/albums/v378/SoLid_PrAnkstA/Image3.gif)

Before using this code, remember that three tags are NECESSARY for it to work: %added%, %play_date% (both in the form YYYYMMDD), and %play_counter%.
[/EDIT]
As I have %play_date% in the YYYY-MM-DD format I thought that just by changing this in your code should work...

Code: [Select]

$add(
$mul($substr(%play_date%,3,4),365),
$select($substr(%play_date%,[B]6,7[/B]),0,31,59,90,120,151,181,212,243,273,304,334),
$ifequal($mod($substr(%play_date%,1,4),4),0,$ifgreater($substr(%play_date%,[B]6,7[/B]),2,1,0),0),
$right(%play_date%,2)
)
)
)

...but it doesn't.

Am I doing something wrong or is this completely impossible to use hotness with another time format? I guess that anyway, once a 'recommended' time (playcount) format is reached, this code should be changed because it'll use somethign like YYYY-MM-DD HH:MM:SS.

@topdown

How did you add the %added%-tag? manually?

- Lyx

@topdown

How did you add the %added%-tag? manually?[a href="index.php?act=findpost&pid=274624"][{POST_SNAPBACK}][/a]

%added% is something I add manually whenever I import new music.  If it was done by foo_playcount, it would update every time it was played (not what I want).[a href="index.php?act=findpost&pid=271389"][{POST_SNAPBACK}][/a]

Thanks, shame on me :-)

this looks like a cool idea. i can't seem to get it working. i paste the code into the columns globals section, just at the bottom. then i make a new column and put %_hotness% in the display of that column. i have the %added% test with YYYYMMDD and also %play_date% with YYYYMMDD. after all that i only see ? in that column. what am i doing wrong?

@falconfox
do you have the "make date info available" and "use global variables for display" boxes checked?  it gave me erroneous readings to begin with because the date thing wasn't checked.

yeah i have both of those checked. it is wierd. i really want this thing to work, it seems like a really cool thing to have. There should be a tag of _hotness after i play the song right? i am not getting that tag after i play songs.

There should be a tag of _hotness after i play the song right? i am not getting that tag after i play songs.[a href="index.php?act=findpost&pid=274740"][{POST_SNAPBACK}][/a]

No tag, this is only for display. It uses other tags and time info, to calculate the "hotness", but that value won't be stored anywhere.

Edit: Just to make myself clear. It creates a global variable called "hotness" that can be used in a coloumn as %_hotness%. It's not stored in the file itself.

Wow, surprised at the sudden burst of interest this has received.    I suppose this will be a little more useful once FIRST_PLAYED is added to foo_playcount.  I changed the code in the first post to conform to the LAST_PLAYED standard, as well as a few other changes.

jkwarras, I didn't study the altered code you posted because the code I posted should work with that format.  If it still doesn't, let me know.  I did notice that you didn't mention having %added% tags, so that might be a problem.

edit: might be forced to add some line breaks to the code at some point...these codeboxes behave very differently in mozilla and ie.

how can i make the hotness dots display in different shades of a colour for different hotness values? i'm using lyx's navigator fcs and pasted the main hotness code at the end of the variables section in the globals tab. i also pasted this code: $blend(FFFFFF,0000FF,%_hotness%,100)● in the display tab of the hotness column, and still all the dots are identical shade of black 
BTW great idea with this hotness thing

hey topdownjimmy, i've been watching this thread for a while and am really looking forward to using this. i ried it once, but realized i didnt have the %added% values entered, so have ben waiting till i have some time to go through my archives and tag them appropriately, guestimating when they were "added". i am also eagerly awaiting the standardization of this last played tag and it's incorporation into existing plug-ins.

in other words, i cant wait to use this!

How did you add the %added%-tag? manually?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=274624")

You can also use this plugin to 'auto' do this:
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=29050&hl=foo_filedate]http://www.hydrogenaudio.org/forums/index....hl=foo_filedate[/url]

Rating is all fine and dandy,

Taken on thier own sure, but what if you take it a step further by averaging track ratings into an album rating. Now you know which albums are hot or not at a glance, which in a big library can be very useful. I think of best of's by series, by artist, by year etc.

When a song is played, its hotness should be given a boost (the amount of this boost is detailed below). As time passes since the last time a song was played, that song's hotness should decrease. So now we've got to define a decay period: the time it takes before a song's hotness dwindles to 0 again. The two factors that determine the length of this decay period are rating and play frequency.

I see this being useful when there are many users accessing a common library. But what about one user with a large library. Chances that you would have heard a particular good track would be far and between. OK once we skip ahead many months and play count gets increased it might have some relevance.

What i'm saying is how long will it take for the "hotness" concept to be useful ? Rating took forever, now that its done, have to listen to lots of stuff repeatedly to see results.

I find this subject interesting, just trying to offer some intelligent critiques.

Taken on thier own sure, but what if you take it a step further by averaging track ratings into an album rating. Now you know which albums are hot or not at a glance, which in a big library can be very useful. I think of best of's by series, by artist, by year etc.

Not possible with current formatting-strings. Strings can only see one track at once and cannot look ahead or behind.

i am still not getting any colors for my dots, i have an %added% tag in YYYYMMDD and %play_date% in YYYYMMDD , i have a %play_counter% tage and i have a column of hotness with "$blend(FFFFFF,0000FF,%_hotness%,100)●" in display for the column. then i have the code pasted just at the bottom of the column -> globals ->variables section. i have "use global variables for display checked as well as "make date info available" checked. I really want this to work, but i don't see what i am doing wrong.
Could this be because i don't use ratings at all?

@topdownjimmy: it would be helpful to maybe have a link to playcounter plugin as well as the rating plugin on your first post, it will make it easier for everyone.

i am still not getting any colors for my dots, i have an %added% tag in YYYYMMDD and %play_date% in YYYYMMDD , i have a %play_counter% tage and i have a column of hotness with "$blend(FFFFFF,0000FF,%_hotness%,100)●" in display for the column. then i have the code pasted just at the bottom of the column -> globals ->variables section. i have "use global variables for display checked as well as "make date info available" checked. I really want this to work, but i don't see what i am doing wrong.
Could this be because i don't use ratings at all?

@topdownjimmy: it would be helpful to maybe have a link to playcounter plugin as well as the rating plugin on your first post, it will make it easier for everyone.
[a href="index.php?act=findpost&pid=274905"][{POST_SNAPBACK}][/a]

Ratings aren't necessary for this to work (unrated tracks get a default rating, which is configurable in the code).

I'm not sure if $blend(FFFFFF,0000FF,%_hotness%,100)● is valid code for the display tab, I just threw that together quickly to illustrate what I was getting at.  I've updated the first post with some code that should work; try that.

Quote

When a song is played, its hotness should be given a boost (the amount of this boost is detailed below). As time passes since the last time a song was played, that song's hotness should decrease. So now we've got to define a decay period: the time it takes before a song's hotness dwindles to 0 again. The two factors that determine the length of this decay period are rating and play frequency.

I see this being useful when there are many users accessing a common library. But what about one user with a large library. Chances that you would have heard a particular good track would be far and between. OK once we skip ahead many months and play count gets increased it might have some relevance.

What i'm saying is how long will it take for the "hotness" concept to be useful ? Rating took forever, now that its done, have to listen to lots of stuff repeatedly to see results.

I find this subject interesting, just trying to offer some intelligent critiques.
[a href="index.php?act=findpost&pid=274854"][{POST_SNAPBACK}][/a]

I don't see what you're saying about "having heard a particular good track"...granted people have different listening habits, and that's what the baseline settings are for.  And, hotness will work the same no matter how low or high a song's playcount is; remember, the algorithm bases hotness on play frequency, not playcount alone.  So if you add a song to your library today and play it twice, it already has a frequency of twice the baseline frequency.

I hope that explains things better...when I first started planning for this algorithm, a lot of things weren't making sense to me.  Example: "If the baselinefrequency is 28 and baselinedecay is 7, that's a ratio of 4:1...instead of having to set both blfrequency and bldecay, why not just make the ratio configurable?"  That sounds logical (or at least it did to me), but turns out it doesn't work that way.  Then I had a hard time wrapping my head around what baselinedecay and baselinefrequency MEAN, what they should be set at, and why they should be set that way.  And in fact, the conclusion I came to is very counterintuitive (i.e., baselineFREQUENCY should be lowered if songs stay hot too long...shouldn't it be baselineDECAY that's lowered if songs are staying hot too long?  No.)

Maybe i will implement this idea later if PLAY_FIRST becomes a reality. Anything else - at least for a public FCS - would be quite exotic requirements. Anyways, the reason why i'm posting is that i will probably translate the counterintuitive technical description into a more intuitive practical description in the config (i.e. not explaining how it works, but instead directly asking the user for his listening habits). Of course thats just the plan - i dunno if i will succeed in doing so

After i dig through the code and make me familiar with it, i will probably also change the way how "new songs" are weighted, because my personal opinion is that it should take a while for a track to become hot, even if its played 5 times in the first 2 days. Else, whenever someone gives a new track a more close listen (so, not just one time) it would automatically be threated like a fav. So in short, i'll probably go for a more conservative approach - a bit like that tracks have to "become worthy" before getting a high-rating. So, not a linear but instead a logarithmic approach.

But don't get your hopes up too soon - may take from 2 weeks to 6 weeks until i implement that.

- Lyx

still nothing, even with the new formatting. i am really confused on how i am not getting this to work. with the new code in the color tab, i only  get a ● on the currently played track. i also checked the use custom colors tab. so you changed the required tags to added YYYYMMDD and now last_played to YYYY-MM-DD .

After i dig through the code and make me familiar with it, i will probably also change the way how "new songs" are weighted, because my personal opinion is that it should take a while for a track to become hot, even if its played 5 times in the first 2 days. Else, whenever someone gives a new track a more close listen (so, not just one time) it would automatically be threated like a fav. So in short, i'll probably go for a more conservative approach - a bit like that tracks have to "become worthy" before getting a high-rating. So, not a linear but instead a logarithmic approach.
[a href="index.php?act=findpost&pid=274921"][{POST_SNAPBACK}][/a]

I want to make clear (in case I didn't before) that if you play a song twice on the same day you add it, the algorithm doesn't assign it a frequency of 2 plays per day.  It assigns it a frequency of 2 plays per baselinefrequency.  In code:

$max($get(baselinefrequency),$get(age))

This doesn't entirely solve the issue you bring up (because songs still tend to get played more when they're first added), but it's certainly better than not taking newness into account at all.

I also want to make clear that as time passes since a song's last play, not only does it decay, but its decay accelerates.  Say you add a song to your library and play it five times, thus giving it a decay period of one month.  So its hotness is, say, 95%, and in one month, it will be 0%.  Right?  Not necessarily...its decay period is based on its frequency of play.  So, once its age surpasses the baselinefrequency, its play frequency begins to deline, as does its decay period.  As time-since-last-play increases, decay period decreases, and they collide somewhere in the middle, sooner than was predicted the last time you played it.

still nothing, even with the new formatting. i am really confused on how i am not getting this to work. with the new code in the color tab, i only  get a ● on the currently played track. i also checked the use custom colors tab. so you changed the required tags to added YYYYMMDD and now last_played to YYYY-MM-DD .
[a href="index.php?act=findpost&pid=274922"][{POST_SNAPBACK}][/a]

Try this...make a new column, and in the "Display" tab, put:

%_hotness%

This will give you the hotness as a number from 0-100.  See what number is displayed and you might get a clue to your problem.

i get ? when i just put in _hotness
I'm not giving up!

@falconfox: Make sure there is a square at the end of the last line:

$get(recentness),$get(begindecaynow))),0),100),$get(decay))

The square is available at the top right corner in Columns UI config.

Edit: In the "Globals" part of the config, that is...
Each global variable assignment has to end with a square.

yeah it is all there, i mean i copied the entire code, including the last line of //////// so there is nothing missing

i get ? when i just put in _hotness
I'm not giving up!
[a href="index.php?act=findpost&pid=274925"][{POST_SNAPBACK}][/a]

If you're getting a question mark, that means the main code was copied and pasted incorrectly.  Try copying and pasting again.  If it doesn't work, there might be some conflict with the surrounding Navigator Suite code.

edit: MAKE SURE that you have %last_played% as YYYY-MM-DD and %play_counter%.

yeah i just repasted it and i am getting ? still. i am using azrael 's formatting, and all i did was paste your code to the end of the global -> variable section. maybe there is some conflict?

Else, whenever someone gives a new track a more close listen (so, not just one time) it would automatically be threated like a fav.

Well, hotness isn't intended to measure how much you like a song (that's what rating is for).  I don't really have a problem with a song being "hot" that I don't like.  Besides, if on the second listen I decide I don't like it, I can always rate it a 1, thus decreasing its decay period by more than half.

I think a more accurate description of "hotness" is that it measures how fresh a song is in your mind.  With that in mind, a song you download and play twice should be pretty "hot."

So in short, i'll probably go for a more conservative approach - a bit like that tracks have to "become worthy" before getting a high-rating. So, not a linear but instead a logarithmic approach.
[a href="index.php?act=findpost&pid=274921"][{POST_SNAPBACK}][/a]

I'm really curious to see how you're going to account for "worthiness."  What did you have in mind?  "Don't assign any hotness unless play_counter > 5?"

I also want to make clear that as time passes since a song's last play, not only does it decay, but its decay accelerates.  Say you add a song to your library and play it five times, thus giving it a decay period of one month.  So its hotness is, say, 95%, and in one month, it will be 0%.  Right?  Not necessarily...its decay period is based on its frequency of play.  So, once its age surpasses the baselinefrequency, its play frequency begins to deline, as does its decay period.

But isn't that the opposite of how listening-patterns work in practice? Such a scheme may work for people who listen to music like fast-food. But with people who listen more "deep" it works the opposite way: They may totally dig a track in the first month.... then it becomes boring because of overdose......after 4 months, the play-frequency begins to increase again. But in the third months, its hotness would be displayed lower than it actually is - because although the listener may not listen to it right now because of previous saturation, he still likes it and will play it again later - the track is just "sleeping".

At this point in this post, there would be an explanation of how it imho should work. But i deleted so often what i wrote, because i noticed that i cannot explain what i mean, that i guess it makes sense to explain it when the day comes where i draft a more concrete model.

edit: what i mean is that a track which is new should be at a disadvantage - and a track which is old but has a high playcount should decay slower than it normally would. Or in other words: when a song is new, then better rate it too bad than too good, when a highly played track is old, then better rate it too good than too bad.

- Lyx

falcon: which browser do you use? You may have a charset-problem.

falcon: which browser do you use? You may have a charset-problem.
[a href="index.php?act=findpost&pid=274933"][{POST_SNAPBACK}][/a]

firefox MOOX build

firefox MOOX build
[a href="index.php?act=findpost&pid=274935"][{POST_SNAPBACK}][/a]

Then i dunno - FX should treat unicode-stuff and charsets perfectly. And moox's builds were absolutely okay during the time when i used FX in the past.

because although the listener may not listen to it right now because of previous saturation, he still likes it and will play it again later - the track is just "sleeping".
[a href="index.php?act=findpost&pid=274932"][{POST_SNAPBACK}][/a]

This is, in fact, exactly how I intended hotness to operate.  Like I said, it's not a measure of how much you like a song, it's a measure of how "hot" the song is.  A song that hasn't been played in four months most certainly shouldn't be considered "hot."  Five-stars, maybe, but not "hot."  It sounds like you're arguing against any implementation of decay at all, when decay is what makes hotness interesting.  We already have a measure of how much you like a song, called %rating%.

edit: what i mean is that a track which is new should be at a disadvantage - and a track which is old but has a high playcount should decay slower than it normally would.

This is why play frequency affects how long a song's decay period is.

Or in other words: when a song is new, then better rate it too bad than too good, when a highly played track is old, then better rate it too good than too bad.

- Lyx
[a href="index.php?act=findpost&pid=274932"][{POST_SNAPBACK}][/a]

If a new song is bad, you will rate it a 1, which will decrease its decay period (i.e., speed up its decay), and it will arrive at zero hotness in about two days, although it should be hot for those two days simply because you listened to it recently.

I don't know, i think i am doing everything correctly. Hopefully there isn't any conflict with azrael or firefox.
for the column with %_hotness% , all i get is ?
for the column with [dot] in the display, and the color code in the colour, i get nothing. so i don't know what is wrong with my foobar.. ill try to fix the problem later i guess.

Okay, now i get it - your idea is to rate the "freshness" - the current - only.... while i was trying to make it gauge how "interesting" a song may be for playback.

While you "rate" the result - my idea was create a gauge for the listener which tracks may be interesting to him. The different is that you dont try to guess anything - you just display the result of the current - while i would try to guess a little bit beforehand what may be interesting to the listener in the future.

- Lyx

If a new song is bad, you will rate it a 1, which will decrease its decay period

Good point - i didn't think of that. Pardon me, you have already all those thoughts behind you already which i've yet to go through.

- Lyx

it is wierd, when i have that code in my column display and color, when i have use custom color selected, nothing shows up, but when i unselect it, the [dot] shows up. this is really annoying....

hey, will you make it optional to use YYYYMMDD or YYYY-MM-DD?  i changed all my tagging to the first for hotness to begin with, and don't really feel like changing it back

i'd love you if you did!

edit:  changed some stuff!

hey, will you make it optional to use YYYYMMDD or YYYY-MM-DD?  i changed all my tagging to the first for hotness to begin with, and don't really feel like changing it back

i'd love you if you did!

edit:  changed some stuff!
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=274977")

A masstagger script is available [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=31592&view=findpost&p=274343]here[/url] to convert YYYYMMDD to YYYY-MM-DD.

@topdownjimmy

In your code when calculating the "system-days since millenium" what is this codeline for?

$ifequal($mod(%_system_year%,4),0,$ifgreater(%_system_month%,2,1,0),0),

- Lyx

@topdownjimmy

In your code when calculating the "system-days since millenium" what is this codeline for?

Code: [Select]

$ifequal($mod(%_system_year%,4),0,$ifgreater(%_system_month%,2,1,0),0),

- Lyx
[a href="index.php?act=findpost&pid=275088"][{POST_SNAPBACK}][/a]

That accounts (very poorly) for the extra day in a leap year.  I think I stole that line from someone else's code, and I'm sure it made more sense in its original context.  I never bothered to clean it up because I never thought it'd be taken seriously.    I suppose it should be more like:

$add($div($right(%_system_year%,2),4),$if($or($greater(%_system_month%,2),$greater($mod(%_system_year%,4),0)),1,0))

That's a stab at it, and I'm assuming that $div() operations with remainders round down to the greatest integer.  Correct? 

okay, thanks for explaining this. So i can just scrap this line if i dont need it THAT accurate to save resources.

okay, thanks for explaining this. So i can just scrap this line if i dont need it THAT accurate to save resources.
[a href="index.php?act=findpost&pid=275109"][{POST_SNAPBACK}][/a]

Are you working on something more along the lines of what you were expecting?, like something that will predict what you might be interested in listening to?  How will that work?

I would like to pose a fundamental question.

What is the point of a track's hotness ?  What does it tell you about your collection ?

I approach this by having a list that would tell me what were the best albums i listened to in the last week/month(s) etc using avg album scores.

Still trying to get my head around this hotness concept.

so you mean you rate all your albums and then sort them and then make a list? i dont quite understand what you mean by list...

hotness is a value related to the frequency of play vs the length of time it has been in the playlist vs your personal rating.

sounds like an automated version of what you are doing.

Are you working on something more along the lines of what you were expecting?, like something that will predict what you might be interested in listening to?  How will that work?
[a href="index.php?act=findpost&pid=275111"][{POST_SNAPBACK}][/a]

Nope, i will only think about that when a playcount-plugin exists which generates the first_played-tag automatically. I'm not gonna implement features with exotic requirements.

What i'm working on is just checking if you listened to a track today, and converting the date of recently played tracks to "yesterday", "2 days ago", etc.

- Lyx

so you mean you rate all your albums and then sort them and then make a list? i dont quite understand what you mean by list...

hotness is a value related to the frequency of play vs the length of time it has been in the playlist vs your personal rating.

sounds like an automated version of what you are doing.
[a href="index.php?act=findpost&pid=275118"][{POST_SNAPBACK}][/a]

I use JRiver media center for this. I get an avg score for an album. A smartlist then shows me a list of albums that have a avg rating sorted either by series, artist etc.

im trying to understand the usefulness of this hotness concept, saying  hotness is the frequency of play vs the length of time it has been in the playlist vs your personal rating does not make it clear.

What would you use hotness for ?

It's intended to show you if a track is hot or not. It is hot if you give it a high rating, and listen to it frequently. As time passes by, its hotness decreases, and you have to listen to it some more to make it hot again.

For short, you can think of it as your personal chart, calculated from a set of parameters. Kind of like the charts on e.g. MTV

Note: I haven't read through the code, and I can't use it with it's full functionality as I don't have an ADDED tag, so the above is just my impression of what it's trying to achieve.

Edit: minor correction

@ topdownjimmy:
hey can you post your columns configuration file so i can hopefully get your code to start working. it might help me figure out what i am doing wrong.

Thanks

I've thought about this whole hotness-idea a bit. And currently, i don't see much reason to implement it, even with first_played. Sure, its a very interesting experiment - but its like killing flies with stealth-bombers. Simply being able to sort by play-frequency + a lock-period for new tracks should already be enough to deliver something which in a real-world-scenario comes close to what you're doing. And as soon as no visual-display on a fixed scale is necessary anymore(so, if the user would just look at his play-frequency and know by himself if thats a high number for his habits or not), then you also don't need to play with decay and frequency-variables.

Pragmatic and boring? Yes, maybe - but its the result which counts for me. And in this case, it seems to me as if this would automate something, which every user knows just by looking at a play-freq. stat.

In short, while the whole experiment was very interesting to think through, i think its a solution to a non-existant problem. Well, maybe not non-existant, but with way easier methods to solve.

- Lyx

It's intended to show you if a track is hot or not. It is hot if you give it a high rating, and listen to it frequently. As time passes by, its hotness decreases, and you have to listen to it some more to make it hot again.

For short, you can think of it as your personal chart, calculated from a set of parameters. Kind of like the charts on e.g. MTV


Edit: minor correction
[a href="index.php?act=findpost&pid=275128"][{POST_SNAPBACK}][/a]

ok, so i can see a list of tracks that were recently heard, the ones that were rated higher than others would persist longer. As time went on, i would have this list of tracks there.

But if i want to know the best tracks i listened to say in the last week, month(s), its possible to get this from a query.

The metaphor i was using to understand this hotness concept is the flame icons you see on some bulletin boards when a topic recieves a lot or replies or views. Which led me to think the hotness idea would be useful in a multi-user environment (could be as low as 2 users even), if a library was shared, to get an idea of what track was "hot" or popular, taking into account each users individual rating for the track.

With only one user, it seems to offer little maybe we give it some more time and more will be emerge or add diferent variables into the mix.

It's intended to show you if a track is hot or not. It is hot if you give it a high rating, and listen to it frequently. As time passes by, its hotness decreases, and you have to listen to it some more to make it hot again.

For short, you can think of it as your personal chart, calculated from a set of parameters. Kind of like the charts on e.g. MTV
[a href="index.php?act=findpost&pid=275128"][{POST_SNAPBACK}][/a]

Exactly.  In short: it's "kinda cool." 

I never expected it to get this much attention, and I certainly didn't mean to suggest that people like Lyx should implement it in the configs they make available.  It was just a fun project for me, and I figured if I found it interesting, maybe other people would too.  If you disagree with the methodology laid out in the first post, this just isn't for you.

@ topdownjimmy:
hey can you post your columns configuration file so i can hopefully get your code to start working. it might help me figure out what i am doing wrong.

Thanks
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=275147")

Uploaded:
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=31027&view=findpost&p=275338]http://www.hydrogenaudio.org/forums/index....ndpost&p=275338[/url]

Quote

@ topdownjimmy:
hey can you post your columns configuration file so i can hopefully get your code to start working. it might help me figure out what i am doing wrong.

Thanks
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=275147")

Uploaded:
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=31027&view=findpost&p=275338]http://www.hydrogenaudio.org/forums/index....ndpost&p=275338[/url]
[a href="index.php?act=findpost&pid=275339"][{POST_SNAPBACK}][/a]

This is really wierd, when i used your config, it worked, then when i use mine it gives ?. i copied your exact code into my config and still nothing, maybe there is a conflict with azrael and hotness. that is too bad, i am going to try to change variable names and see if i can get it working...

I got it to work finally. i found out that i needed to paste the code at the *top* of the globals section, instead of the bottom. I don't really know why that makes a difference but it does. thanks and this is sweet!

Maybe i'm totally confused about how this works, but i think i'm having a problem. :/


I added the hotness code (verbatim) to my globals thing in Columns UI. I have LAST_PLAYED and ADDED (both in YYYY-MM-DD HH:mm:ss format) in my tags, and PLAY_COUNTER is in there too, so i have all the required junk.

Then i make my column to show the hotness level, and it appears to work at first. (I'm not using any fancy graphics or anything for now, i'm just putting out the raw %_hotness% thing.) The songs without LAST_PLAYED/ADDED/PLAY_COUNTER appear as '0', which makes sense to me. But then after i start playing songs, i get totally confused.

You say that %_hotness% is supposed to show up on a scale of 100, but mine doesn't. If i play a song once, the number changes from 0 to 26900. If i play it again, it goes to 13500. If i play it again it goes to 9033, and then to 6800, and then to 5460, and so forth. I have no idea why it does this, it makes zero sense to me. Never mind the fact that it's not showing up on a scale of 100... shouldn't it get, you know, hotter as i play it more? Why's it going down?

Did i do something wrong, or am i just not understanding how this works? :(

I have LAST_PLAYED and ADDED (both in YYYY-MM-DD HH:mm:ss format) in my tags,
[a href="index.php?act=findpost&pid=275647"][{POST_SNAPBACK}][/a]

I think that %added% must be in YYYYMMDD format (without -). It's what I'm using and it works.

If that's the case, that's stupid (why two different formats?), but, um....

I tried it anyway (YYYYMMDD), and there was no change. It went from 26900 to 13500 just like it has been. :p


[span style='font-size:8pt;line-height:100%']I would look through the code myself and try to figure it out, but this is just beyond me. Formatting strings i can deal with, but looking at the code for this gives me a head ache. :([/span]

If that's the case, that's stupid

Yes, it is.

(why two different formats?), but, um....

Because you cannot standardize all plugins which make use of date overnight. The whole last_played thingie is just a few days old. The choice is: either leave the chaos as it is, or do something about it. If something is done about it, then there naturally is a "transition-phase" of even more increased chaos. A first_played-tag with the same format as last_played was already proposed. Whats missing is someone who grabs the playcount source, does the proposed changes and then releases it. Once that happened you suddenly have a single plugin which handles all play-stats issues in a uniform-way.

- Lyx

Yes, but he said that he added... the... ADDED... manually, which is why i would figure that it would be the same format. If you're going to do it yourself, you might as well make it consistent. :/

But oh well, i don't really care if it's different. The point is that it does the same thing either way. :(

Yes, but he said that he added... the... ADDED... manually, which is why i would figure that it would be the same format. If you're going to do it yourself, you might as well make it consistent. :/

But oh well, i don't really care if it's different. The point is that it does the same thing either way.
[a href="index.php?act=findpost&pid=275723"][{POST_SNAPBACK}][/a]

It's not entirely manual.  I use a plugin that adds the tag in that format, although I do have to use the context menu to apply it.  I figured the use of this plugin (though not wide-spread, as far as I know) is as close to a standard as we have right now.  There's a link to the plugin in the first post.

It went from 26900 to 13500 just like it has been.

What went from 26900 to 13500?

I have a column with nothing in it but %_hotness%. When there's no PLAY_COUNTER or LAST_PLAYED or whatever, it just shows up as 0. (Which makes sense.) But when i play the song and it updates the play counter, it (%_hotness%) changes from 0 to 26900. When i play the song again it changes to 13500. And so on, it keeps decreasing like that, i already gave the specific numbers above if that matters.

But... i'm guessing that it isn't s'posed to do that at all? <_<

I have a column with nothing in it but %_hotness%. When there's no PLAY_COUNTER or LAST_PLAYED or whatever, it just shows up as 0. (Which makes sense.) But when i play the song and it updates the play counter, it (%_hotness%) changes from 0 to 26900. When i play the song again it changes to 13500. And so on, it keeps decreasing like that, i already gave the specific numbers above if that matters.

But... i'm guessing that it isn't s'posed to do that at all?
[a href="index.php?act=findpost&pid=275858"][{POST_SNAPBACK}][/a]

For all of those like Lav and my self that have weird %_hotness% numbers the problem is resolved by checking "Make data info available" ( Makes %_system_year%, %_system_day%, %_system_month%, %_system_day_of_week%, %_system_hour% available in global variables string ) in the Globals section!

Good Luck, C00I90WN

Oh wow. I NEVER would have figured that out. Thank you~!

Oh wow. I NEVER would have figured that out. Thank you~!
[a href="index.php?act=findpost&pid=275902"][{POST_SNAPBACK}][/a]

No problem! Glad I could help!

Cya, C00I90WN

Rad, now that it more or less works, i have some questions if that's OK. I'm horrible at maths, so i have no hope of ever understanding this on my own.


I'm sort of having a little trouble with the accuracy, i guess. It's not really trouble trouble, just kind of weird. I'm manually playing around with the tags to try to change the 'hotness' value, and i notice that it's not very precise. For example, if i set LAST_PLAYED to like 04:00 this morning it'll be 75% hotness. But if i set it to 23:55 last night, it jumps straight down to 50%. There is no in-between. No 60% or anything.

Is there a way i can make it more precise? Do i have to change the 'baseline' junk? Or am i just being really anal? :x

This is fantastic!

I can't believe I only just noticed this.

I had a similar idea in the following thread:

http://www.hydrogenaudio.org/forums/index....ndpost&p=260739 (http://www.hydrogenaudio.org/forums/index.php?showtopic=30138&view=findpost&p=260739)

although no where near as detailed, and was hoping someone would do this.

and you know what? topdownjimmy did it!

THANK YOU TOPDOWNJIMMY

Is there a way i can make it more precise? Do i have to change the 'baseline' junk? Or am i just being really anal? :x
[a href="index.php?act=findpost&pid=275920"][{POST_SNAPBACK}][/a]

I was thinking about making it change on an hourly rather than daily basis, because that would be more "graceful."  But I'm really not sure how that would affect its processing time, so I decided against it.  To care THAT much is pretty anal (although I'm anal as well )

Does anyone know if this would dramatically affect the resources demanded by hotness?

I had a similar idea in the following thread:

http://www.hydrogenaudio.org/forums/index....ndpost&p=260739 (http://www.hydrogenaudio.org/forums/index.php?showtopic=30138&view=findpost&p=260739)
[a href="index.php?act=findpost&pid=275994"][{POST_SNAPBACK}][/a]

I really like the idea of "auto-rating," which this isn't, really.  Hotness takes recentness into account so heavily that it isn't a good indicator of which songs you actually like the most.

I also created code for "meta-rating," which simply multiplies %rating% by play frequency:

metarating=$div($mul($if2(%rating%,$get(avgrating)),%play_counter%,100),$get(age))

This gives me a wide range of numbers thare are on no absolute scale.  So it's still somewhat useful for sorting purposes, but I would really love it if there were some way to tell what the highest meta-rating was and convert every track's meta-rating to a five-point scale.  Otherwise when I see that a track's metarating is 250, it doesn't tell me anything.  Unfortunately, I think that's impossible.  But I think with that and hotness, I might be totally satisfied.

Oh!

i thought it was a similar sort of thing

looking at the end result only!

I was after something like:

somehow getting the ratings to start decreasing based on the last play date.
i.e. some sort of indication which visually shows which tracks have been played recently and often

and your code gives

a dot which reduces its color based on added, last played date and time, count, and rating

to me, it sounds like a better more complex version of the idea in that thread.  Oh well, what do i know

But I really love this script

Thanks again

decaying on an hourly basis would be pretty sweet. just my 2 cents.

how do i make a database explorer tree of hotness?
like:

-Hotness
--5: Goosebumps
--4: Very good
--3: Good
--2: Quite good
--1: Stands out (from the masses)

as upnorth level names

how do i make a database explorer tree of hotness?
like:

-Hotness
--5: Goosebumps
--4: Very good
--3: Good
--2: Quite good
--1: Stands out (from the masses)

as upnorth level names
[a href="index.php?act=findpost&pid=277258"][{POST_SNAPBACK}][/a]

(a) that scale doesn't exactly mirror the purpose of hotness (i.e., >=80% hotness doesn't mean "goosebumps" necessarily...you might not even like the song)

(b) I don't think system time and date are available to playlisttree, so this is just impossible to begin with  :/

Quote

how do i make a database explorer tree of hotness?
like:

-Hotness
--5: Goosebumps
--4: Very good
--3: Good
--2: Quite good
--1: Stands out (from the masses)

as upnorth level names
[a href="index.php?act=findpost&pid=277258"][{POST_SNAPBACK}][/a]

(a) that scale doesn't exactly mirror the purpose of hotness (i.e., >=80% hotness doesn't mean "goosebumps" necessarily...you might not even like the song)

(b) I don't think system time and date are available to playlisttree, so this is just impossible to begin with  :/
[a href="index.php?act=findpost&pid=277274"][{POST_SNAPBACK}][/a]

sadly you're right. i cant even put hotness in "track info".
thanx anyway.

(b) I don't think system time and date are available to playlisttree, so this is just impossible to begin with  :/
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=277274")

in PT there's %systemdate% which is in the form YYYYMMDD. The problem is not about that becaue I guess you can easily use that builtin function to retrieve systemdate info needed by hotness, the problem is that globals are not used in PT the same way as in columns UI. The only way to get this owrking in PT is by using $get(hotness) in the browser or $globalformat(hotness) in the PT main window. I've tried to get the script working, but without luck, the function seems to return weird results.

You can check here:
[a href="http://www.bowron.us/forum/viewtopic.php?t=79&postdays=0&postorder=asc&start=0]http://www.bowron.us/forum/viewtopic.php?t...der=asc&start=0[/url]

For all of those like Lav and my self that have weird %_hotness% numbers the problem is resolved by checking "Make data info available" ( Makes %_system_year%, %_system_day%, %_system_month%, %_system_day_of_week%, %_system_hour% available in global variables string ) in the Globals section!

Good Luck, C00I90WN
[a href="index.php?act=findpost&pid=275896"][{POST_SNAPBACK}][/a]

Thanks! I was going nuts trying to figure this out.

something strange has occured...

as i was listening to an album, today, one i just added, i noticed it had a lower hotness than tracks i listened to yesterday, which were added in early february...

a you see on the image below, they were played at virtually the same time.  same rating, same playcount.  the only difference is the added date, which is the first of this month, and the 12th of last month.

the "older" track has a 91 hotness, while the "new" track is only 88

screenshot! (http://img.photobucket.com/albums/v378/SoLid_PrAnkstA/weirdhotness.gif)

just thought i'd throw it out, incase anyone else has experienced it...

something strange has occured...

as i was listening to an album, today, one i just added, i noticed it had a lower hotness than tracks i listened to yesterday, which were added in early february...

a you see on the image below, they were played at virtually the same time.  same rating, same playcount.  the only difference is the added date, which is the first of this month, and the 12th of last month.

the "older" track has a 91 hotness, while the "new" track is only 88

screenshot! (http://img.photobucket.com/albums/v378/SoLid_PrAnkstA/weirdhotness.gif)

just thought i'd throw it out, incase anyone else has experienced it...
[a href="index.php?act=findpost&pid=278338"][{POST_SNAPBACK}][/a]

It's probably the format of your ADDED tags...these are supposed to be in the form YYYYMMDD, not YYYY-MM-DD like you have them.  This is the formatting used by the component I use to add the ADDED tags, linked to in the first post of this thread.  Hopefully the playcount component will be updated soon so we can switch to a FIRST_PLAYED standard.

ahh, alright.  that works better...

the last_played is in the correct format, right?  YYYY-MM-DD?  i thought both added and last_played were supposed to be that format...  (oops!)

I've been using Play Count for a while now, but my dates are all in a different format. I left it with the defaults

PLAY_DATE = %D%M%y (Produces 010305)
PLAY_TIME = $H$M$S (Produces 095829)

how do I fix this so I can use 'hotness' ?
Also, I have a bunch of stuff already setup to use the date in that format... can I change 'hotness' some how to work with my date instead of changing everything else?

Thanks

I get hotness=0 for all my songs, no matter what the playcount/added date/last_played/rating.  I believe I am using all the correct date formats and copied all the code correctly.  What else could be wrong?

I hope it's not trying to tell me all my music is really bad.

stripe/ben

I'm trying (again) to make hotness work with playlist tree (http://www.bowron.us/forum/viewtopic.php?t=79&postdays=0&postorder=asc&start=0&sid=80b74c21d34705ce7ef06d3b02029e49) and I'm almost there...I've had to trasnlate %_system_year%,etc... stuff to %systemdate% (which is in the form of YYYYMMDD) in order to get same results. I've also changed %last_played% to %__last_played% because I use mod playcount version (from kode54). And as PT doesn't handle globals as Columns UI I had to remove every square " in the code, and  change the last line in the form of

hotness=

to

$puts(hotness,

because PT can only retrieve in the form of $get(hotness) and not %_hotness%.

Anyway this give me some weird results because it doesn't match with the result I get from the column UI global, you can check it via this screenshot:
[a href=\"http://img184.exs.cx/my.php?loc=img184&image=clipboard4nc.png\" target=\"_blank\"]

$puts(baselinefrequency,14)
$puts(baselinedecay,7)

$puts(begindecaynow,1)

$puts(avgrating,3)

$if(%added%,$puts(age,$sub($add($mul($substr(%systemdate%,3,4),365),$select($substr(%systemdate%,5,6),0,31,59,90,120,151,181,212,243,273,304,334),$ifequal($mod($substr(%systemdate%,1,4),4),0,$ifgreater($substr(%systemdate%,5,6),2,1,0),0),$substr(%systemdate%,7,8)),$add($mul($substr(%added%,3,4),365),$select($substr(%added%,5,6),0,31,59,90,120,151,181,212,243,273,304,334),$ifequal($mod($substr(%added%,1,4),4),0,$ifgreater($substr(%added%,5,6),2,1,0),0),$right(%added%,2)))),$puts(age,$mul(%__play_counter%,$get(baselinefrequency))))

$puts(recentness,$sub($add($mul($substr(%systemdate%,3,4),365),$select($substr(%systemdate%,5,6),0,31,59,90,120,151,181,212,243,273,304,334),$ifequal($mod($substr(%systemdate%,1,4),4),0,$ifgreater($substr(%systemdate%,5,6),2,1,0),0),$substr(%systemdate%,7,8)),$add($mul($substr(%__last_played%,3,4),365),$select($substr(%__last_played%,6,7),0,31,59,90,120,151,181,212,243,273,304,334),$ifequal($mod($substr(%__last_played%,1,4),4),0,$ifgreater($substr(%__last_played%,6,7),2,1,0),0),$substr(%__last_played%,9,10))))

$puts(decay,$div($mul(%__play_counter%,$get(baselinefrequency),$get(baselinedecay),$if2(%rating%,$get(avgrating))),$mul($max($get(age),$get(baselinefrequency)),$get(avgrating))))

$puts(hotness,$div($mul($max($sub($get(decay),$add($get(recentness),$get(begindecaynow))),0),100),$get(decay)))

Thanks you very much.

I'm trying (again) to make hotness work with playlist tree (http://www.bowron.us/forum/viewtopic.php?t=79&postdays=0&postorder=asc&start=0&sid=80b74c21d34705ce7ef06d3b02029e49) and I'm almost there...
[a href="index.php?act=findpost&pid=280765"][{POST_SNAPBACK}][/a]

Wow, thanks for doing this.  Now maybe hotness wil actually be useful.  I shied away from doing this long ago because honestly the propaganda has worked, and I'm terrified of playlist_tree, plus the last time I had it I could never get the systemdate components to work properly at all.  Very cool though, I will surely test this out on my fb2k. 

edit: I'm surprised nobody has pointed out the really horrifying philosophical problem with hotness: its aim seems to be to allow you to easily listen to your hot songs even more than you already have, only making them hotter and sending you along that downward spiral seen all across America on ClearChannel radio...  Looking back I think one of my motivations was that I like to make mix CDs every few months that define my musical tastes at the time, something that could be totally automated by making an 80-minute playlist of the hottest songs in my library.

I've been using Play Count for a while now, but my dates are all in a different format. I left it with the defaults

PLAY_DATE = %D%M%y (Produces 010305)
PLAY_TIME = $H$M$S (Produces 095829)

how do I fix this so I can use 'hotness' ?
Also, I have a bunch of stuff already setup to use the date in that format... can I change 'hotness' some how to work with my date instead of changing everything else?

Thanks
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=278484")

Check the wiki for scripts to convert your current formats to the "standard": [a href="http://wiki.hydrogenaudio.org/index.php?title=Foobar2000#Standardize_my_PLAY_DATE_and_PLAY_TIME_fields]http://wiki.hydrogenaudio.org/index.php?ti...LAY_TIME_fields[/url]

As for changing the code, it wouldn't be too difficult, just a matter of changing the substring indexes.  But this is why we're developing standards.    Maybe at the very least it would be a good idea to offer alternate hotness code that conforms to the default foo_playcount settings.  Sigh...I'm losing hope that that component will ever be rewritten...

WHAT DO WE WANT?  %FIRST_PLAYED%!  WHEN DO WE WANT IT?  NOW!

Also, I have a bunch of stuff already setup to use the date in that format... can I change 'hotness' some how to work with my date instead of changing everything else?

Thanks
[a href="index.php?act=findpost&pid=278484"][{POST_SNAPBACK}][/a]

check the first post, new code added for default play_date setting...hasn't been tested though 

Thanks, I tried it out, however I just get "?" in the column. Any ideas?

Wow, thanks for doing this.
Now maybe hotness wil actually be useful.

You're welcome, let's see if we can make it work.

I shied away from doing this long ago because honestly the propaganda has worked, and I'm terrified of playlist_tree,

Yeah, a lot of people are scared about this component for this reason, but I'm really happy with it, it's still in development so expect some bugs, but I didn't get any serious crash in the last two months.

edit: I'm surprised nobody has pointed out the really horrifying philosophical problem with hotness: its aim seems to be to allow you to easily listen to your hot songs even more than you already have, only making them hotter.

Yeah, I've also thought about that but for me is just like having a 'Most played' playlist and taking it into consideration in your mixing creations, you'll always get some of those tracks in the mix and therefore you'll get them more and more playcounts.

I like the idea behind hotness because it takes a lot of values as reference and 'rate' a song. It's easy to see what songs you like most and play most.

The only thign that I miss in fb2k is the possiblity of having a statistic that allows keeping track of all playcounts over the time, so you could create a 'hot tracks this month' and 'hot tracks last month' and 'hot tracks: global'. That will be much more interesting, because you could see what you did like most lover the time.

I also thought about that:
http://www.hydrogenaudio.org/forums/index....ndpost&p=281175 (http://www.hydrogenaudio.org/forums/index.php?showtopic=30138&view=findpost&p=281175)

I mean, does hotness takes into account the size of the library? because it's for sure that the largest your library is, the less you're likely to play tracks even your favourites one. I often tends to forget about traks that I have and I love, but with so much new tracks and the size of my library going up I get 'distracted'

Anyway this give me some weird results because it doesn't match with the result I get from the column UI global, you can check it via this screenshot:
(http://img184.exs.cx/img184/9994/clipboard4nc.th.png) (http://img184.exs.cx/my.php?loc=img184&image=clipboard4nc.png)
[a href="index.php?act=findpost&pid=280765"][{POST_SNAPBACK}][/a]

hey! can you upload your hotness column string?

I also thought about that:
http://www.hydrogenaudio.org/forums/index....ndpost&p=281175 (http://www.hydrogenaudio.org/forums/index.php?showtopic=30138&view=findpost&p=281175)

I mean, does hotness takes into account the size of the library? because it's for sure that the largest your library is, the less you're likely to play tracks even your favourites one. I often tends to forget about traks that I have and I love, but with so much new tracks and the size of my library going up I get 'distracted'
[a href="index.php?act=findpost&pid=281192"][{POST_SNAPBACK}][/a]

That's what the baseline settings are for...tweak and see how it affects things.  I wish there were a more automatic way to set those, but I think that's impossible (even if you have a huge library, you might only listen to five albums in a week...either over and over or just once each...or you might have music on all day and listen to almost everything you have...very tricky.  Read the rules of the thumb I give in the code for configuring those baselines and let me know if you think they're accurate.  They don't come from practice, but from theory.

That's what the baseline settings are for...tweak and see how it affects things.

Ok, I didn't really read all the settings, thanks for the tip.

-the more often you listen to music, the LOWER baselinedecay should be
-the more variety of music you listen to, the HIGHER baselinefrequency should be

I have quite a large library (around 225 albums) and listen to music around 2-3 hours a weekday and much more on the weekend. So I don't know if I should alter the settings, they seems quite fine for me. Maybe rise a little the decay and frequency could help. But 've never been really good with statistics

Quote

Anyway this give me some weird results because it doesn't match with the result I get from the column UI global, you can check it via this screenshot:
(http://img184.exs.cx/img184/9994/clipboard4nc.th.png) (http://img184.exs.cx/my.php?loc=img184&image=clipboard4nc.png)
[a href="index.php?act=findpost&pid=280765"][{POST_SNAPBACK}][/a]

hey! can you upload your hotness column string?
[a href="index.php?act=findpost&pid=281218"][{POST_SNAPBACK}][/a]

Sure.

$blend(414141,0000FF,%_hotness%,100)%_hotness% ●

Just some thoughts. I got the impression that fresh songs (recently added) get too much hotness, I mean i.e. a track very recently added get around 85 on the first play while older track gets not so great bumps.

For me it takes sense that fresh tracks get better hotness indicators that older ones, but maybe not so higher values. In the mean time, i also got the impression that old tracks even with some playcounts and good rating takes too much to take hotness indicators.

i.e. a track with 5 rating, added the 01-04-2004, played 3 times and last played 09-03-2005 doesn't get any hotness (remains at 0) when it's played today. I would tends to think it deserves at least some tiny points... 

Well, doesn't know if this makes sense or I'm totally wrong

Quote

Quote

Anyway this give me some weird results because it doesn't match with the result I get from the column UI global, you can check it via this screenshot:
[a href="http://img184.exs.cx/my.php?loc=img184&image=clipboard4nc.png" target="_blank"]

Just some thoughts. I got the impression that fresh songs (recently added) get too much hotness, I mean i.e. a track very recently added get around 85 on the first play while older track gets not so great bumps.

For me it takes sense that fresh tracks get better hotness indicators that older ones, but maybe not so higher values. In the mean time, i also got the impression that old tracks even with some playcounts and good rating takes too much to take hotness indicators.

i.e. a track with 5 rating, added the 01-04-2004, played 3 times and last played 09-03-2005 doesn't get any hotness (remains at 0) when it's played today. I would tends to think it deserves at least some tiny points...  

Well, doesn't know if this makes sense or I'm totally wrong
[a href="index.php?act=findpost&pid=281277"][{POST_SNAPBACK}][/a]

No, you're probably totally right.  I haven't been keeping track of playcount and added for very long at all, which is why this kind of feedback is good.  I don't know off the top of my head how you could solve that problem by altering the algorithm itself, but I would refer to the rules of thumb again (or which there are two for each setting):

baselinefrequency:
- decrease if songs stay hot too long
- increase if you listen to a large variety

baselinedecay:
- decrease if too many songs are hot
- decrease if you listen to music very often

Again, those rules don't come from practice, they come from theory.  I myself am no good at statistics, but I wrapped my head around this problem for about a week and reached those rules of thumb pretty confidently (even though I know one or two of them sound counter-intuitive).

Another issue is that you must have "start decay today" turned on, which is why those rarely-played songs are starting at 0.  Of course, changing that would just make them 100% today, and 0% tomorrow (and something really bothers me about having a playlist full of 100% hot songs...boring data.)

I would increase baselinefrequency (because songs aren't staying hot long enough) and see how that feels.  Also, this might be a good argument for implementing hourly rather than daily decay (something that might be very, very beautiful).  I don't know if this would occupy more system resources, but I can't imagine it would be noticable since it would just be doing the same math with numbers in the thousands instead of in the hundreds.  If anyone knows how this would affect things, let me know, otherwise I might just go ahead and putting together an hourly decay version...man would that be sweet, watching all those blinking dots...

@topdownjimmy: thanks for the explanations, I'll play with them

BTW, an hourly based decay would look nice.

@topdownjimmy: thanks for the explanations, I'll play with them

BTW, an hourly based decay would look nice.
[a href="index.php?act=findpost&pid=281373"][{POST_SNAPBACK}][/a]

Success.  I'm about to post an "hourly decay" version in the first post.  Seems to work over here at first glance, lemme know if there are problems. 

Softer gradients, more dynamic data.

I don't know if this would occupy more system resources, but I can't imagine it would be noticable since it would just be doing the same math with numbers in the thousands instead of in the hundreds. If anyone knows how this would affect things, let me know, otherwise I might just go ahead and putting together an hourly decay version

I don't think it will affect the system resources but you could try it, btw hourly based hotness would be perfect.

Another useful thing would be hotness to look in your entire music collection rather than only on active list, that way it would calculate even better the hotness cuz it would take in count all all the files....

EDIT: @topdownjimmy: I haven't noticed that you where going to post an hourly based version! Perfect!

Another useful thing would be hotness to look in your entire music collection rather than only on active list, that way it would calculate even better the hotness cuz it would take in count all all the files....
[a href="index.php?act=findpost&pid=281387"][{POST_SNAPBACK}][/a]

I'm afraid foobar isn't capable of doing anything like that.  :/

Quote

Another useful thing would be hotness to look in your entire music collection rather than only on active list, that way it would calculate even better the hotness cuz it would take in count all all the files....
[a href="index.php?act=findpost&pid=281387"][{POST_SNAPBACK}][/a]

I'm afraid foobar isn't capable of doing anything like that.  :/
[a href="index.php?act=findpost&pid=281389"][{POST_SNAPBACK}][/a]

  Oh too bad

Thx anyway...

Success.  I'm about to post an "hourly decay" version in the first post.  Seems to work over here at first glance, lemme know if there are problems. 
[a href="index.php?act=findpost&pid=281382"][{POST_SNAPBACK}][/a]

Works fine here. I've noticed that hotness values have changed a little (i.e. for the most played track on my library, that had a 55 hotness indicator, with the new version it has a 71 indicator), I guess it has to do with the new hourly decay code.

Thanks

how can i get 100% hotness?

I just tried this also, and I really have to say: good work!
One "problem" I have is that every song I play gets immediately 100 as hotness, but that is only because I dont use the %added% tag (or so I've figured). Anyway, it isn't that big problem with the hourly decay version, which seems to work quite well
I'll also need to check the baseline values for any tweaking they might need, but I'm not there yet, as I installed kode's foo_playcount yesterday (after deleting all %last_played% and %play_date% tags I had). I just don't like the idea of having them as actual metadata, the external database is much better for it (same goes with ratings).

I also felt that a new column for another "rating" would be too much so I added it nicely to my rating column:

%_color_background%'('%_hotness%') '
%_color_pale%$repeat('•',$sub(5,%rating%))
%_color_info%$if(%rating%,$repeat('•',%rating%))

1) color_background is naturally the background color of the foobar window so the actual hotness value shows only in tooltips (the rating column is just wide enough for the 5 stars to show).
2) color_pale is just a light grey color ($rgb(234,234,234)), so if a song has a rating of 3, it shows 2 dots with this color and 3 with the:
3) color_info, which is defined like this in global variables

color_info=$blend($rgb(179,179,179),$rgb(77,107,97),$get(hotness),100)

This goes from a dark blue to the default color of my ratings, so the higher hotness, the darker blue. Works great!
Oh and it's called color_info just because I used to have more info than just the rating with that color

Quote

Success.  I'm about to post an "hourly decay" version in the first post.  Seems to work over here at first glance, lemme know if there are problems. 
[a href="index.php?act=findpost&pid=281382"][{POST_SNAPBACK}][/a]

Works fine here. I've noticed that hotness values have changed a little (i.e. for the most played track on my library, that had a 55 hotness indicator, with the new version it has a 71 indicator), I guess it has to do with the new hourly decay code.

Thanks
[a href="index.php?act=findpost&pid=281474"][{POST_SNAPBACK}][/a]

Yep, that's how it should work.  Instead of showing 24 hours of decay, that track is showing 17 hours of decay (or whatever the values).  How are the baseline experiments going?  What's convenient about that is that you can change those settings in your globals config and immediately see the effects of those changes.  A good way of calibrating your settings would be to create a playlist with all your music and reverse sort by hotness.  See which track is at 50%, or which track has the lowest non-zero hotness, see if that "feels correct," then adjust. 

I just tried this also, and I really have to say: good work!
One "problem" I have is that every song I play gets immediately 100 as hotness, but that is only because I dont use the %added% tag (or so I've figured). Anyway, it isn't that big problem with the hourly decay version, which seems to work quite well
[a href="index.php?act=findpost&pid=281484"][{POST_SNAPBACK}][/a]

This has nothing to do with %added%, in fact hotness should operate fine even without %added%.  The reason that happens is because I turned off immediate decay in this version.  Immediate decay was introduced because previously, every song you played "today" stayed at 100% until tomorrow, which was boring and annoying (especially if tomorrow it went down to 30% or something).  I guess I could put that option back in, although in that case, the 24-hour "clairvoyance" of hotness (i.e., using "tomorrow's" value instead of "today's" value) would be kind of arbitrary (since our unit is now the hour, not the day).

How are the baseline experiments going?  What's convenient about that is that you can change those settings in your globals config and immediately see the effects of those changes.  A good way of calibrating your settings would be to create a playlist with all your music and reverse sort by hotness.  See which track is at 50%, or which track has the lowest non-zero hotness, see if that "feels correct," then adjust. 
[a href="index.php?act=findpost&pid=281530"][{POST_SNAPBACK}][/a]

I'll play with it tomorrow and see the results. For soem reason I can't seems to get sort by hotness working...

BTW, as mentioned here I've also noticed that every track gets now a 100 hotness when played, no matter if this has been never played and added 1 year before. What I suppose it's that this song hotness will decay quicker than other more fresh or played more often.

Quote

How are the baseline experiments going?  What's convenient about that is that you can change those settings in your globals config and immediately see the effects of those changes.  A good way of calibrating your settings would be to create a playlist with all your music and reverse sort by hotness.  See which track is at 50%, or which track has the lowest non-zero hotness, see if that "feels correct," then adjust. 
[a href="index.php?act=findpost&pid=281530"][{POST_SNAPBACK}][/a]

I'll play with it tomorrow and see the results. For soem reason I can't seems to get sort by hotness working...

In the settings for the hotness column, you need to check "Use custom sort spec" and put this code in the "Sort" tab:

$num($sub(100,%_hotness%),3)

You also need to check "Use global variables when sorting by column" checked in the globals tab.

BTW, as mentioned here I've also noticed that every track gets now a 100 hotness when played, no matter if this has been never played and added 1 year before. What I suppose it's that this song hotness will decay quicker than other more fresh or played more often.
[a href="index.php?act=findpost&pid=281571"][{POST_SNAPBACK}][/a]

This is because I turned off immediate decay.  I could add a setting for "clairvoyance" or something that will look x hours ahead and use that hotness (the default daily decay setting was to look 24 hours ahead) so that songs aren't given a hundred percent right off the bat.  I didn't think this would be an issue since songs will start decaying in an hour, but maybe I'll at least make it optional.  Default might be 12 hours or something I guess.

Been following this for some time now and seeing its getting into an interesting phase, ppl playing about with differnent values to make it more meaningful.

I had an idea, i think hotness would be a great way to show people what you are listening to at any point in time.

I let you hash out the details of how much is to be presented etc. but the idea i had was to give a useful picture of whats going on currently, whats hot etc.

If there was a way to generate HTML out of it and post it would make it even better.

Quote

Another useful thing would be hotness to look in your entire music collection rather than only on active list, that way it would calculate even better the hotness cuz it would take in count all all the files....
[a href="index.php?act=findpost&pid=281387"][{POST_SNAPBACK}][/a]

I'm afraid foobar isn't capable of doing anything like that.  :/
[a href="index.php?act=findpost&pid=281389"][{POST_SNAPBACK}][/a]

something you could do to work this in, you could have a variable the user defines, where they just insert the number of tracks in their library, or 0 if they don't want to use this particular feature.
sure, it's not so dynamic, but it would get the job done...

Quote

Quote

Another useful thing would be hotness to look in your entire music collection rather than only on active list, that way it would calculate even better the hotness cuz it would take in count all all the files....
[a href="index.php?act=findpost&pid=281387"][{POST_SNAPBACK}][/a]

I'm afraid foobar isn't capable of doing anything like that.  :/
[a href="index.php?act=findpost&pid=281389"][{POST_SNAPBACK}][/a]

something you could do to work this in, you could have a variable the user defines, where they just insert the number of tracks in their library, or 0 if they don't want to use this particular feature.
sure, it's not so dynamic, but it would get the job done...
[a href="index.php?act=findpost&pid=281711"][{POST_SNAPBACK}][/a]

yeah, but it's an ugly one

cya!

Quote

Quote

Another useful thing would be hotness to look in your entire music collection rather than only on active list, that way it would calculate even better the hotness cuz it would take in count all all the files....
[a href="index.php?act=findpost&pid=281387"][{POST_SNAPBACK}][/a]

I'm afraid foobar isn't capable of doing anything like that.  :/
[a href="index.php?act=findpost&pid=281389"][{POST_SNAPBACK}][/a]

something you could do to work this in, you could have a variable the user defines, where they just insert the number of tracks in their library, or 0 if they don't want to use this particular feature.
sure, it's not so dynamic, but it would get the job done...
[a href="index.php?act=findpost&pid=281711"][{POST_SNAPBACK}][/a]

I'm not so sure that would make things any easier for calibration...even if you have a huge library, you might only listen to a few albums at a time for a few weeks, or you might listen to a broad range of things.  In other words, it's not really about how big your library is, it's about how much of your library you listen to, and how often you listen to anything at all.

I've just changed baselinefrequency to 21 and I think everything seems correct. More old tracks are rated as little hot, and I think this fits more my listening habits

BTW, I've just requested (http://www.bowron.us/forum/viewtopic.php?t=121) to cwbowron to make available a %systemdate% function with system hour (hh:mm:ss) so I can try to adapt it to PT in an hourly basis. Still I can't seesm to get it working correctly (still getting those weird numbers). topdownjimmy, did you get the time to take a look at it?

ok... I just tried the first one out, but it doesn't do anything? There's no errors or anything, it just doesn't show anything. I"m using last_played and play_counter, and the only difference is that I replaced everything so that the sql db version would work.

ok... I just tried the first one out, but it doesn't do anything? There's no errors or anything, it just doesn't show anything. I"m using last_played and play_counter, and the only difference is that I replaced everything so that the sql db version would work.
[a href="index.php?act=findpost&pid=282013"][{POST_SNAPBACK}][/a]

If you're using the mod playcount version (I think it's what you're using by reading your post), you need to replace every %play_counter% by %__playcounter% and every %last_played% by %__last_played%, and also make sure you're using the recommended format in the last_played tag.

Quote

ok... I just tried the first one out, but it doesn't do anything? There's no errors or anything, it just doesn't show anything. I"m using last_played and play_counter, and the only difference is that I replaced everything so that the sql db version would work.
[a href="index.php?act=findpost&pid=282013"][{POST_SNAPBACK}][/a]

If you're using the mod playcount version (I think it's what you're using by reading your post), you need to replace every %play_counter% by %__playcounter% and every %last_played% by %__last_played%, and also make sure you're using the recommended format in the last_played tag.
[a href="index.php?act=findpost&pid=282015"][{POST_SNAPBACK}][/a]

yeah I'm stupid, I accidentally replaced everything

now I have another problem.. how do I get this column to sort? I've tried $num(%_hotness%,3), but it doesn't want to work.. is this some limitation of global vars or something? I can't very well use this outside of this either, meaning that extended playlist generator is out :/

edit: nm, turns out i didn't check "use global vars when sorting"

I can't very well use this outside of this either, meaning that extended playlist generator is out :/
[a href="index.php?act=findpost&pid=282017"][{POST_SNAPBACK}][/a]

I'm trying to make it work with Playlist tree (to be able to maintain a '50 hotest tracks' node), but without luck because globals doesn't seems to work the same way as in columns UI.

Instead of using a daily or hourly decay why not to use the total played time, if you go to preferences in foobar under playback there is a "Status display" that tells you the total time that foobar has been playing your songs. The idea would be to calculate the porcentage of that time that has been used to play a desired song, you have two parameters the playcount and the track total playing time, so [Playcount] * [track total time] would give you the total time that it has been played, then it is a simple percentage formula, of course things like the rating and anything that it may ocurr to you should affect the hotness also...

Cya
C00I90WN

EDIT: Corrected sth

Instead of using a daily or hourly decay why not to use the total played time, if you go to preferences in foobar under playback there is a "Status display" that tells you the total time that foobar has been playing your songs. The idea would be to calculate the porcentage of that time that has been used to play a desired song, you have two parameters the playcount and the track total playing time, so [Playcount] * [track total time] would give you the total time that it has been played, then it is a simple percentage formula, of course things like the rating and anything that it may ocurr to you should affect the hotness also...

Cya
C00I90WN

EDIT: Corrected sth
[a href="index.php?act=findpost&pid=283131"][{POST_SNAPBACK}][/a]

Can't do this, total foobar play time isn't available for use in titleformatting strings.

Quote

Instead of using a daily or hourly decay why not to use the total played time, if you go to preferences in foobar under playback there is a "Status display" that tells you the total time that foobar has been playing your songs. The idea would be to calculate the porcentage of that time that has been used to play a desired song, you have two parameters the playcount and the track total playing time, so [Playcount] * [track total time] would give you the total time that it has been played, then it is a simple percentage formula, of course things like the rating and anything that it may ocurr to you should affect the hotness also...

Cya
C00I90WN

EDIT: Corrected sth
[a href="index.php?act=findpost&pid=283131"][{POST_SNAPBACK}][/a]

Can't do this, total foobar play time isn't available for use in titleformatting strings.
[a href="index.php?act=findpost&pid=283715"][{POST_SNAPBACK}][/a]

Oh too bad... It would have been very nice...

Similar idea, but crippled version for trackinfo panel-

Since trackinfo doesn't have %_system_date% yet, I whipped up this as a slimmed down version:

$puts(popularity,$sub(100,$add($div(50,%play_counter%),$mul(25,$sub(3,%rating%)))))

Here's the math behind it:

popularity=75-(50/playcount)-25(3-rating)

Right now I have it use a blend of 100 on my rating bar, seems to work pretty well.  Check the trackinfo thread for more ... info.
--
dan

So I did some thinking, is there a way to add an "interval" tag to a file everytime it's played?  That is, subtract %last_played% from %system_date% and save the difference as %interval%. I think that would make the hotness string run faster, and open up the use of the trackinfo panel.  Any thoughts?

I'm off to scour the forums for info on this.

--
dan

So I did some thinking, is there a way to add an "interval" tag to a file everytime it's played?  That is, subtract %last_played% from %system_date% and save the difference as %interval%. I think that would make the hotness string run faster, and open up the use of the trackinfo panel.  Any thoughts?

I'm off to scour the forums for info on this.

--
dan
[a href="index.php?act=findpost&pid=284837"][{POST_SNAPBACK}][/a]

This would require making the system date and time globally available in foobar.  Right now hotness is only possible because musicmusic has included such a feature in columns_ui.  This is why hotness can't be displayed in the track info panel, can't be used to generate playlists, etc.  Hopefully this will be something introduced in the next version of foobar (as it seems like a pretty generally useful thing to have).

Oh, it would also require a play counter plugin that parsed titleformat strings, which would also be really cool for things like you describe.

I may be being an idiot here so feel free to laugh...
Whilst the hourly decay version does decay the hotness value every hour it doesn't appear to take the hour in the day that the file was last played in to account, ie all songs played on the same day still have the same value.


so....have I just set it up wrong?

I may be being an idiot here so feel free to laugh...
Whilst the hourly decay version does decay the hotness value every hour it doesn't appear to take the hour in the day that the file was last played in to account, ie all songs played on the same day still have the same value.


so....have I just set it up wrong?
[a href="index.php?act=findpost&pid=285535"][{POST_SNAPBACK}][/a]

HA HA.  No I'm kidding. 

It should take the specific time it was last played into account, however, it doesn't take into account the exact time it was added to your library.  Works here, I'm listening to an album, the first half of which is at hotness 99 and the second half at 100.

Hi, I'm using the last_played version of hotness.  My last_played tags however are not in the correct YYYY-MM-DD format.  They are %D%M%y.  And frankly I don't want to use the masstagger or change the format.  However, I still want to use the last_played version of hotness.  Is there some code that will allow me to convert my last_played tag to the right format before calculating hotness without actually tagging the files?  Thanks.

I got this so far:

$if(%last_played%,'   '20$substr(%last_played%,3,4)-$left(%last_played%,2)-$right(%last_played%,2),'           '))

Which returns the last_played date in a column in the correct format (so I can debug).  But this isn't what I want.  I want to set this equal to something and then input it into the hotness script.

EDIT:

At the top of Globals>Variables I put this:

$puts(lastplayed,'   '20$substr(%last_played%,3,4)-$right(%last_played%,2)-$left(%last_played%,2))

Then I changed all occurances of %last_played% in the hotness script to lastplayed.  But it doesn't work.  This should work shouldn't it?  What am I doing wrong?

topdownjimmy: i tried the pasting the code into the foobar .9b3 and it gives numbers in the 800's and 0's , is is a copying error on my part, or are others experiencing this as well? can you update the code (if needed)??

topdownjimmy: i tried the pasting the code into the foobar .9b3 and it gives numbers in the 800's and 0's , is is a copying error on my part, or are others experiencing this as well? can you update the code (if needed)??
[a href="index.php?act=findpost&pid=301056"][{POST_SNAPBACK}][/a]

I haven't tried yet, I was kind of waiting for the final to be released.  I also imagine there might be some cool things I could do now that PLAY_STAMP is possible, but I still have to figure all that out.

well, it took me a little while to get working, but I'm quite happy with the outcome. Great work on this bit of code  Now, if someone could help me adapt this to Navigator Suite's alternate colour lines, so it fit right in, that'd be awesome

lol nm, shortly after I posted I figured it out

Having read through this thread I noticed that i couldn't get my question answered without actually asking it myself so here goes. do you know how I can use this with the default user interface. I am just trying to integrate this into my current setup and the problem is that I can't figure out what to do with the following script to make it work.

"$blend(FFFFFF,0000FF,%_hotness%,100)|
$blend(FFFFFF,0000FF,%_hotness%,100)|
FFFFFF|
FFFFFF" 

there is also the matter of the number error given by not thicking the "Make data info available" box under the columns UI > general tab.

i think it works with this for the most part, other than the above, with the default user interface. i just have large numbers and all messing with my setup. it is making it slightly less attractive than i would like. i am sorry but i am just not that proficient with foobar2k scripts as i would like.

Having read through this thread I noticed that i couldn't get my question answered without actually asking it myself so here goes. do you know how I can use this with the default user interface. I am just trying to integrate this into my current setup and the problem is that I can't figure out what to do with the following script to make it work.

"$blend(FFFFFF,0000FF,%_hotness%,100)|
$blend(FFFFFF,0000FF,%_hotness%,100)|
FFFFFF|
FFFFFF" 

there is also the matter of the number error given by not thicking the "Make data info available" box under the columns UI > general tab.

i think it works with this for the most part, other than the above, with the default user interface. i just have large numbers and all messing with my setup. it is making it slightly less attractive than i would like. i am sorry but i am just not that proficient with foobar2k scripts as i would like.
[a href="index.php?act=findpost&pid=307508"][{POST_SNAPBACK}][/a]

The default UI doesn't have access to the globals defined in the Columns UI settings.

The default UI doesn't have access to the globals defined in the Columns UI settings.
[a href="index.php?act=findpost&pid=307630"][{POST_SNAPBACK}][/a]

I understand that. my question is, is there a way to make this work with default UI?

I really never did work in columns UI much. I never had time to figure it all out. and i still dont have time. i am curently taking summer term with more credits than the average summer student at my college.

Quote

The default UI doesn't have access to the globals defined in the Columns UI settings.
[a href="index.php?act=findpost&pid=307630"][{POST_SNAPBACK}][/a]

I understand that. my question is, is there a way to make this work with default UI?

I really never did work in columns UI much. I never had time to figure it all out. and i still dont have time. i am curently taking summer term with more credits than the average summer student at my college.
[a href="index.php?act=findpost&pid=307681"][{POST_SNAPBACK}][/a]

Well you're using %_hotness% to access the hotness value.  This is the format for accessing globals defined by Columns UI.  If you're putting all this code into the playlist title format, you'll have to use $puts() and $get().  That's a start.  If I have time I'll try to build it myself.  I was planning on rewriting the whole thing anyway, possibly to take the PLAY_STAMP field into account.

well... i was able to more or less figure out how to get my default UI code to work with columns ui so i have this pretty much solved. thanks for the great code here.

Well I'm looking for suggestions on how to incorporate all the play_stamps into the calculation of hotness.  Seems things could get a lot more accurate this way...

Off the top of my head, play frequency can now be based on the last five or ten plays of a song, rather than the entire history of the song.

For example: play a song once.  Wait a year.  Play it ten times in one day.  In the current algorithm, this would equate to a play frequency of 11 plays per year, which is very low and would cause the hotness to diminish very quickly.

But if we calculate play frequency based on the last ten plays only, this would equate to a play frequency of ten per day, which would make the hotness last a much more appropriate length of time.

That's just an initial thought, but if someone can help me come up with something better, please let me know...

Some major changes are being made to this algorithm due to the introduction of new features of foo_playcount.  Anyone who is using the new version of foo_playcount should try using this code, even if you do not have the PLAY_STAMP field enabled.

For one thing, now that the playcount component adds FIRST_PLAYED, you will never again have to manually tag your files with an ADDED field.

Additionally, now that I have the entire play history of a song at my disposal, I've been considering how best to incorporate this data into a calculation of hotness that is more accurate, or at least more interesting.

At first I considered only accounting for the last 5 or 10 plays; instead of averaging out a play frequency by simply doing (playcount) / (added), I could find the play frequency of just the last 5 or 10 songs.  This would produce a more current estimation of "hotness," by ignoring long stretches of time when you didn't listen to a particular song.

This somehow seemed like a very boring, dead algorithm to me, and I wasn't using all the time stamps I could.

So, instead, I've come up with what I'm calling "parabolic decay."  Parabolic decay works like this:

Let's say in the early history of a song, it doesn't get played very often at all.  Then, a year after you first play it, you being to play it several times a day.  At this point, using the old algorithm, even though you've played it very much recently, its hotness would decay quickly due to its overall low play frequency.

With parabolic decay in place, for the first couple days after the last play, the song's hotness will remain very high, taking into consideration only the last couple times you've played it to calculate play frequency.

As time passes, the algorithm will look further and further back into the song's play history to calculate play frequency.  I'm calling this process the "normalization" of hotness, as the algorithm begins to consider the song's play history as a whole rather than focusing on the recent past.

This demands the introduction of a new user-defined variable: the period for normalization, or the time it takes after the last play of a song for the algorithm to take the entire play history into its scope.

So, for all you people who have been keeping PLAY_STAMP tags recording for no apparent reason, now is the time to help me bugfix! 

At the bottom of this post I'm putting the new code.  If it all works out, it shouldn't require that you have PLAY_STAMP enabled.  It should work for everyone who uses the new version of foo_playcount.  This also means that instead of using the now obsolete ADDED field, it refers to the FIRST_PLAYED field as created by the new version of foo_playcount.

Before you paste this code I recommend you back up your existing code, since I know some of you have had to edit it for your own use.

Please try it out and report back to me in this thread with your feedback.  Thanks!! 

edit: code removed because it was too buggy, and i'm expecting an update to foo_playcount soon.

Some values you can use in your columns to see the inner workings and help debug:

%_playstoconsider% : the number of plays to consider when calculating play frequency
%_age% : the period of time in hours over which play frequency is calculated
%_recentness% : the number of hours since a song was last played
%_decay% : the time in hours for total decay to occur

was thinking about it and began to wonder if its possible to change this to a half-life decay frequeny. i mean it would take age, playcount, and rating into account when calculating the half-life on the decay, but that would be more like a coefficient of decay. i dont know. maybe this is more complex math than one would want to code for this. basically it would be with "#e^(-ax)", the larger the coefficiant of decay "a" the faster the decay rate, and "a" would be calculated with the age, playcount, and rating of the file and "x" is the decay time.

i just thought of this so i have not put much work into actually comming up with something for that function. also. since i am not someone that knows much about scripting for foobar2k, I am not even sure if it is feasable to use "#e" in it. well. let me know what you think. my reasoning with this is because even if a song has had 1 play in a very long time should have some sort of hotness left over. this would only make it so that as the songs get closer to 1 on the hotness scale they will take a little longer to lose their hotness rating that they have. i know this might be different that what you are aiming for topdownjimmy but i thought i might at least try tossing it your way.

the function to find "a" could be something like

a = age (of song in whatever units would work best) / (playcount * rating).

"age" could be calculated using %First_played% or %added%. whichever becomes the actual standard. this means that as the age of the file increases, its half-life becomes shorter and shorter. but this is really simplistic and may lead to some songs decaying super fast after a while. it is just off the top of my head is all.

also if you do think this is doable but need help on the math i used to be pretty good in it.

#e^(-ax)[a href="index.php?act=findpost&pid=310206"][{POST_SNAPBACK}][/a]

I'm all for increased complexity in this algorithm, but unfortunately foobar's tagz language isn't capable of performing exponential functions.

removed this post because it has become outdated and the code was awful.

I'm all for increased complexity in this algorithm, but unfortunately foobar's tagz language isn't capable of performing exponential functions.
[a href="index.php?act=findpost&pid=310213"][{POST_SNAPBACK}][/a]

I kind of had that feeling. that is too bad. i just think it would have been a really kewl concept i think. oh well.

as for the new code, since my added dates are all about a year ago and my playcounts have just been reset and all... plus i am using the SQL versions of both quicktag and playcounter with the only extra variable for playcounter being last_played in its format, the code just doesnt do what i need. i get extreamly low hotness even with a song that has about 4 plays on it (this is a lot considering my collection). for now i shall stay with the hourly decay version. thx anyways though.

plus i am using the SQL versions of both quicktag and playcounter with the only extra variable for playcounter being last_played in its format, the code just doesnt do what i need.
[a href="index.php?act=findpost&pid=310228"][{POST_SNAPBACK}][/a]

Exactly same settings here, I hope that in the future the new foo_playcount version will be implemented in a sql version, so I can use new hotness version.

Exactly same settings here, I hope that in the future the new foo_playcount version will be implemented in a sql version, so I can use new hotness version.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=310260")

@jkwarras
We can only wait and wee what Kode is doing. from what i read though, I think kl33per will need some help implementing the SQL... and i really am not one that could do that. Lets hope something happens though... i wonder how hard it would be to make tagz able to use exponentials. i am not really 100% sure what tagz is. lol.

@topdownjimmy
is it that tagz cant to any exponents (i.e. x^2) is not going to work? or is it just in e^x and e^2 type of functions... having looked at the wiki on tagz it looks like ^ is one of the operators and if it is used with "common" meaning than i would expect it to be used for exponential powers. [a href="http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Tagscript#Operators]http://wiki.hydrogenaudio.org/index.php?ti...cript#Operators[/url]

if it's not impossible to do exponents in tagz then it is still possible to make a fake half-life model, but this would take a little more code than that of 100#e^(-ax). well.. maybe not really more code... but i would have to do some statistics work to get a descent model to set this up with. it is possible without the use of #e though. well... i hope its still a possiblity... if not then it was at least worth a try.

having looked at the wiki on tagz it looks like ^ is one of the operators and if it is used with "common" meaning than i would expect it to be used for exponential powers.[a href="index.php?act=findpost&pid=310272"][{POST_SNAPBACK}][/a]

"Common meaning" of ^ in C/C++ and thus TagScript is bitwise exclusive or (xor).

Quote

having looked at the wiki on tagz it looks like ^ is one of the operators and if it is used with "common" meaning than i would expect it to be used for exponential powers.[a href="index.php?act=findpost&pid=310272"][{POST_SNAPBACK}][/a]

"Common meaning" of ^ in C/C++ and thus TagScript is bitwise exclusive or (xor).
[a href="index.php?act=findpost&pid=310292"][{POST_SNAPBACK}][/a]

i dont understand any of htis but it all sounds really cool, can't wait to try it out

Quote

having looked at the wiki on tagz it looks like ^ is one of the operators and if it is used with "common" meaning than i would expect it to be used for exponential powers.[a href="index.php?act=findpost&pid=310272"][{POST_SNAPBACK}][/a]

"Common meaning" of ^ in C/C++ and thus TagScript is bitwise exclusive or (xor).
[a href="index.php?act=findpost&pid=310292"][{POST_SNAPBACK}][/a]

oh yeah... oops.... the mind of a former math major... lol... well... it has been too long since i took and used C. well... oh well. that is too bad

oh yeah... oops.... the mind of a former math major... lol... well... it has been too long since i took and used C. well... oh well. that is too bad[a href="index.php?act=findpost&pid=310452"][{POST_SNAPBACK}][/a]

No problem. I think that "common meaning" isn't a very good description, and I took a few minutes to add more specific, though quite brief information about the meaning of each operator. You might still need some programming background to understand them, but I hope it at least avoids confusions like this one.

No problem. I think that "common meaning" isn't a very good description, and I took a few minutes to add more specific, though quite brief information about the meaning of each operator. You might still need some programming background to understand them, but I hope it at least avoids confusions like this one.
[a href="index.php?act=findpost&pid=310470"][{POST_SNAPBACK}][/a]

yeah... i have a minimal programming background using quickbasic and 1 coarse of C. so my main referance was to what the math programs used the "^" for, and that wasnt xor. in fact, i cant even remember having to use an xor statement of any kind during C  class.

I've got a little problem:my hotness values are far beyond 100.

I used Play-count with DD/MM/YY I changed my tags to DDMMYY with the masstagger but I still have values unbelievable:
http://eolindel.free.fr/images/hotness.gif (http://eolindel.free.fr/images/hotness.gif)
(hotness is the last column)

I dont have %added% nor ratings values, I copied the code without any change, the play_date version

For songs tagged from the beginning with DDMMYY it is okay (85 for a  track played for the first time)

Any idea for the problem?

Thanks

edit: I don't use SQL lite or anything like this..

should be 4 digits for the year, no?  i think i'm using an older hotness algorithm, but my last_played tags look like:
2005-07-19 12:19:48
and it works.  in columns_ui / globals, make sure "make date info available" is checked, or you'll get outrageous values.

I got "make date info available" avaible and at the beginning of the topic, it is indicated DDMMYY not DDMMYYYY and my tracks tagged DDMMYY from the beginning are right the problem only concerns the tracks that I had to retag..

It's quite like a mystery..

I got "make date info available" avaible and at the beginning of the topic, it is indicated DDMMYY not DDMMYYYY and my tracks tagged DDMMYY from the beginning are right the problem only concerns the tracks that I had to retag..

It's quite like a mystery..
[a href="index.php?act=findpost&pid=314726"][{POST_SNAPBACK}][/a]

the %added% tag needs to be yyyymmdd

But I don't use %added%. You said in your first post that it wasn't necessary, Did it change with the newest versions ?

Um, forgive me, but where exactly do you download this plugin? There's no link in the first post (contrary to what other posts in this thread say). I've searched the thread both by hand and with the search function and I can't find it. The closest I got were the updates at the top of the first post, which turned out to be just underlined text and not links.

What's going on here??

But I don't use %added%. You said in your first post that it wasn't necessary, Did it change with the newest versions ?
[a href="index.php?act=findpost&pid=314740"][{POST_SNAPBACK}][/a]

Okay I understand what your problem is now...

it looks like the files you had to retag have an extra space at the beginning of the PLAY_DATE stamp.  Is that the answer?

Um, forgive me, but where exactly do you download this plugin? There's no link in the first post (contrary to what other posts in this thread say). I've searched the thread both by hand and with the search function and I can't find it. The closest I got were the updates at the top of the first post, which turned out to be just underlined text and not links.

What's going on here??
[a href="index.php?act=findpost&pid=314775"][{POST_SNAPBACK}][/a]

hotness is not a component, it is a (long) string of code to be inserted into your columns_ui globals

Ah...suppose I shouldn't have glazed over the code section so quickly then. Thanks.

Okay, everything works except sorting with Queries using Playlist Tree. My sort criteria have been:

$num($sub(100,%_hotness%),3)
$num(%_hotness%,3)
%_hotness%

None of them work. I have sorting working just fine with my playlist but Playlist Tree Queries don't want to work at all.

Also, not a major deal, but for the hotness color coordination thing posted earlier, where you fade the bright red to white depending on how hot the song is...I can't seem to get background colors for currently playing tracks to work properly. I have selected and selected-nonfocused working just fine, but there doesn't appear to be anything for currently-playing and currently-playing-selected, at least not what the Columns UI color tab help tells me. Any ideas?

you can still use and exponential function without exp( ) . It is called a taylor series. It is an infinite series, but by no means do you have to go to many terms to get a good approximation. The actual series is described here (http://en.wikipedia.org/wiki/Exponential_function#Formal_definition). Basically it would just be something along the lines of:

exp(#) = (#^0)/0! + (#^1)/1! + (#^2)/2! + (#^3)/3! + ...
exp(#) = 1        + #        + (#^2)/2! + (#^3)/3! + ...

I think it would be pretty cool to see something like this implimented into the hotness code. I have always been a fan of the concept.

I have selected and selected-nonfocused working just fine, but there doesn't appear to be anything for currently-playing and currently-playing-selected, at least not what the Columns UI color tab help tells me. Any ideas?
[a href="index.php?act=findpost&pid=314820"][{POST_SNAPBACK}][/a]

Unfortunately you have to use $if(%_isplaying%,...) for that.

Okay I understand what your problem is now...
it looks like the files you had to retag have an extra space at the beginning of the PLAY_DATE stamp.  Is that the answer?
[a href="index.php?act=findpost&pid=314780"][{POST_SNAPBACK}][/a]

yes!! thanks for the answer  (sorry I didn't see your reply before)

I'm going to retag correctly my tags!!

you can still use and exponential function without exp( ) . It is called a taylor series. It is an infinite series, but by no means do you have to go to many terms to get a good approximation. The actual series is described here (http://en.wikipedia.org/wiki/Exponential_function#Formal_definition). Basically it would just be something along the lines of:

Code: [Select]

exp(#) = (#^0)/0! + (#^1)/1! + (#^2)/2! + (#^3)/3! + ...
exp(#) = 1        + #        + (#^2)/2! + (#^3)/3! + ...

I think it would be pretty cool to see something like this implimented into the hotness code. I have always been a fan of the concept.
[a href="index.php?act=findpost&pid=315011"][{POST_SNAPBACK}][/a]

this is true that taylor series would produce that result. i believe that most calculation programs actually use a taylor algorythm to calculate #e but the problem with usign this is still the need for the usage of a power of x during the series. thinking of all possible solutions that i know of i think that the only way to do this would be some sort of code added to foobar itself to be able to handle exponentials and powers. in fact, looking through that entire page i see that every solution to finding #e contains at least one power that cant be hard coded as just a coefficient (at least in any ways that this novice can think of). and i would have loved to have seen this in hotness also but i dont think it is possible with foobar's current capabilities.





BTW... did anyone ever get hotness working with playlist tree? if so can you help me on getting it up and running?

BTW... did anyone ever get hotness working with playlist tree? if so can you help me on getting it up and running?
[a href="index.php?act=findpost&pid=315639"][{POST_SNAPBACK}][/a]

I've really tried to get it working. I had to re-arrange a little bit the code to fit into the PT globals (it doesn't use the same format as column UI, but I think it uses the standard UI globals), but I can't make it work (it display crazy numbers). I've requested many times tocwbowron to look at it, or just allow globals like in Colmn UI but he must not be very interested in that

this is true that taylor series would produce that result. i believe that most calculation programs actually use a taylor algorythm to calculate #e but the problem with usign this is still the need for the usage of a power of x during the series. thinking of all possible solutions that i know of i think that the only way to do this would be some sort of code added to foobar itself to be able to handle exponentials and powers. in fact, looking through that entire page i see that every solution to finding #e contains at least one power that cant be hard coded as just a coefficient (at least in any ways that this novice can think of). and i would have loved to have seen this in hotness also but i dont think it is possible with foobar's current capabilities
[a href="index.php?act=findpost&pid=315639"][{POST_SNAPBACK}][/a]

Maybe using the exponential Taylor serie expressed as:

1+x*(1+x/2*(1+x/3*(1+x/4(1+x/5(...)))))

may reduce the calculation time depending on the priority of operations in the foobar algorythm as it may reduce it by a bunch of multiplications (and i think that "factoriel": "!" (I'm french)  isn't an already existing operation in foobar)

And as a limited development at the sixth or seventh degree might be already sufficient for something as simple as calculating hotness which is still experimental and doesn't need precision but something with the global behavior of the exponential function, if that was what you were talking about

edit: anyway it's true that an already existing exponential function would be nice 

umm... well... lol.. I just thought of something. If accuracy isn't that big of an issue then we don't need to use something like Taylor series to calculate #e. After all, #e is an irrational constant that is calculated by such methods. But the fact is that #e IS A CONSTANT that is approximately 2.71828182846. If we need more accuracy than that then it is a little ridiculous for something like 'hotness'. The only real problem would be coding some sort of method to bring this number to a power of '-at', where '-a' is the coefficient of decay, and 't' is the interval of time. Therein lay the problem that one would need to solve for this to be able to be implemented.

I can’t believe that I didn’t think about #e as a constant before. I am a ‘recovering’ math major after all.

um, i'm having trouble implementing this could some help me. There are 3 versions on the front page so i chose the "play date" version. I copied that into globals > variables and ticked the 2 boxes. Then created a column with the %_hotness% and i get this :S

screenshot (http://azer.homeip.net/ravi/bad.JPG)

those numbers are wrong

[span style='font-size:8pt;line-height:100%']moderation: please refrain from inlining images larger than roughly 800x600 and 80KB. please use thumbnails and/or links for large pictures instead. try PNG for reduced filesize.[/span]

Do we really need to use exponential function for this?  I think you can approximate the behavior of a decay curve like e^(-x) using a rational function like 1/(x*(x+1)+1).

Do we really need to use exponential function for this?  I think you can approximate the behavior of a decay curve like e^(-x) using a rational function like 1/(x*(x+1)+1).
[a href="index.php?act=findpost&pid=319628"][{POST_SNAPBACK}][/a]

some form of that could work. So far i have com up with 100(count*rating)/((age)x*(x+1)+1).
where
count == playcount
rating == song rating
age == age of song in some incrimental value based on the added (or some other standardised) variable.

The problem is that this allows for values over 100 and we are no longer working with percents. we would need to figure out some sort of way to limit it to only being at 100. maybe an $if statement that would just hold the value at 100 until the decay brings the hotness below 100. Another problem would be to choose the units of x (time after song was last played) and age so that they wouldn't cause the song to delay too slow or too fast (there might need to be some conversion involved with this).
Another problem would be if someone doesn't use added or any other variable to base the age of the song on then the function will not work. there would need to be some check for that with an alternate function. Maybe the origional linear script could be used then. I don't know. I am not a coder so I am not sure how much of this is viable for use.

um, i'm having trouble implementing this could some help me. There are 3 versions on the front page so i chose the "play date" version. I copied that into globals > variables and ticked the 2 boxes. Then created a column with the %_hotness% and i get this :S

screenshot (http://azer.homeip.net/ravi/bad.JPG)

those numbers are wrong

[span style='font-size:8pt;line-height:100%']moderation: please refrain from inlining images larger than roughly 800x600 and 80KB. please use thumbnails and/or links for large pictures instead. try PNG for reduced filesize.[/span]
[a href="index.php?act=findpost&pid=319536"][{POST_SNAPBACK}][/a]

i get the same thing. it looks like the hotness variable isn't done being calculated before being the value is shown.

@matth6546 and @12zmcnvow1277

I also had the same thing happen for a while there. Check the format of your variables for last_played and also make sure you have make date info available checked under globals tab.
last_played needs to be in the %Y-%m-%d %H:%M:%S format for this to work correctly. Also, if you use the Added tag then it needs to be in the %Y%m%d format.

i'm using the play_date version, not last_played. and i dont have the added tag.

i'm using the play_date version, not last_played. and i dont have the added tag.
[a href="index.php?act=findpost&pid=319889"][{POST_SNAPBACK}][/a]

if you're using the most recent version of foo_playcount, you need to use the last_played version (or the hourly decay version).  play_date is an obsolete tag used by old versions of foo_playcount.


also, i've been putting off a huge revamp of this code for some time now.  but eventually the nature of hotness will be very different, and will take all play_stamps into account if you have them enabled, allowing for much more nuanced decay curves.  so, turn on play_stamp tagging now to collect data if this is something you'd like to see.

I really like this idea, it's very cool to have all these data that I'd never otherwise look at, and which on their own don't really say anything terribly useful, reduced to a single useful and interesting dimension. Now if I only had some playcounter data that wasn't from the last few days.... Anyway, awesome stuff! 

Just thought I'd suggest an alternate code for the actual display column - to blend between a few different colours on its trip from 100 to 0 hotness, and give a little more potential for differentiation. In my code it goes 100->0 red->orange->yellow->green->blue->blue/black, but it's easy enough to muck around with the colour values. And if the song's never been played, the dot doesn't show up at all. All this just goes straight in the column's display field (the colour field gets left totally alone). All fairly pointless, but there you go.

//colours used, hotness=100:0
$puts(colour100,0000FF)
$puts(colour99,0000FF)
$puts(colour75,00FFFF)
$puts(colour50,00FF00)
$puts(colour25,FF8800)
$puts(colour0,880000)

//dotshading
$if(%last_played%,
$select(
$add($put(hotdiv,$div(%_hotness%,25)),1)
$puts(shade,$sub(%_hotness%,$mul($get(hotdiv),25))),
$blend($get(colour0),$get(colour25),$get(shade),25),
$blend($get(colour25),$get(colour50),$get(shade),25),
$blend($get(colour50),$get(colour75),$get(shade),25),
$blend($get(colour75),$get(colour99),$get(shade),25),
$get(colour100)
)• 
,)

Also spiffy alternate colour sets to paste over the other colour bit:

white->yellow->orange->red->black

$puts(colour100,FFFFFF)
$puts(colour99,FFFFFF)
$puts(colour75,00DDDD)
$puts(colour50,0088FF)
$puts(colour25,0000AA)
$puts(colour0,000000)

white->blue->black

$puts(colour100,FFFFFF)
$puts(colour99,FFFFFF)
$puts(colour75,DDAA22)
$puts(colour50,CC0000)
$puts(colour25,880000)
$puts(colour0,000000)

@matth6546 and @12zmcnvow1277


last_played needs to be in the %Y-%m-%d %H:%M:%S format for this to work correctly. Also, if you use the Added tag then it needs to be in the %Y%m%d format.
[a href="index.php?act=findpost&pid=319806"][{POST_SNAPBACK}][/a]

Is last play part of playcount? because in playcount I only have play date and play time available, do i replace play time with last played? and in playdate, have:

%Y-%m-%d %H:%M:%S ?

Also my tags are tagged %D/%M/%y would i have to play each track once to make them tag at the new standard? or is there someway i can convert all tags to the new way? thanks for your help.

Quote

i'm using the play_date version, not last_played. and i dont have the added tag.
[a href="index.php?act=findpost&pid=319889"][{POST_SNAPBACK}][/a]

if you're using the most recent version of foo_playcount, you need to use the last_played version (or the hourly decay version).  play_date is an obsolete tag used by old versions of foo_playcount.


also, i've been putting off a huge revamp of this code for some time now.  but eventually the nature of hotness will be very different, and will take all play_stamps into account if you have them enabled, allowing for much more nuanced decay curves.  so, turn on play_stamp tagging now to collect data if this is something you'd like to see.
[a href="index.php?act=findpost&pid=319911"][{POST_SNAPBACK}][/a]

thanks man. i just installed the latest play_counter plug-in, pasted in the hourly decay and everything works as it should.

is this the latest playcount version?
http://65.17.81.165/foobar/foo_playcount.dll (http://65.17.81.165/foobar/foo_playcount.dll)
it's 40kb, if it's old can someone give me the link to the newest version, i cant seem to find it

is this the latest playcount version?
http://65.17.81.165/foobar/foo_playcount.dll (http://65.17.81.165/foobar/foo_playcount.dll)
it's 40kb, if it's old can someone give me the link to the newest version, i cant seem to find it
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=320192")

[a href="http://pelit.koillismaa.fi/plugins/tagging.php#125]http://pelit.koillismaa.fi/plugins/tagging.php#125[/url]

Quote

is this the latest playcount version?
http://65.17.81.165/foobar/foo_playcount.dll (http://65.17.81.165/foobar/foo_playcount.dll)
it's 40kb, if it's old can someone give me the link to the newest version, i cant seem to find it
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=320192")

[a href="http://pelit.koillismaa.fi/plugins/tagging.php#125]http://pelit.koillismaa.fi/plugins/tagging.php#125[/url]
[a href="index.php?act=findpost&pid=320355"][{POST_SNAPBACK}][/a]

Thanks for the Link! it would be nice if the link in the playcoun thread was updated too, i thought that was the latest build

hotness 2.0

A completely revamped version of the hotness algorithm, employing %play_stamp% tags supplied by foo_playcount 1.7.6 to create dynamic hotness decay tailored to each song's unique play history.

In order to use this script, you MUST have foo_playcount 1.7.6, with the PLAY_COUNTER, LAST_PLAYED, FIRST_PLAYED, and PLAY_STAMP boxes checked in preferences.  Although I am not releasing the script yet, if it's something you plan to use, I highly recommend turning these options on now to begin collecting data for the script to use as soon as it's installed.


In previous versions of the hotness algorithm, a song's hotness began at 100 and decayed in a linear fashion to 0, over a period of time that was defined by the song's rating and play frequency.

This meant, in short, that periods of heavy or light play were not weighted properly.  Even if you were to play a song many times in the past few days, a low overall play frequency would cause the hotness to decline very quickly.

The new algorithm uses a song's entire play history rather elegantly to construct a unique decay curve for that song.  Here are some graphs to illustrate.

(http://photos22.flickr.com/38765529_43c2858eda_o_d.gif)

This is the play history of a song.  The black dot (node) at the bottom is the first play.  As time passes upward on the graph, each node represents another play.  Notice that it has been played relatively steadily.

Now we are going to take these nodes and spread them out horizontally, an arbitrary three units per node:

(http://photos33.flickr.com/38765530_815acab859_o_d.gif)

This is the basic outline for the hotness decay curve.  The horizontal axis will become time, and the vertical axis will become hotness.

However, we don't want the hotness to begin exactly at 100.  So, in order that the most recent play is taken into account, but not so heavily, we will "deaden" the hotness a little by placing secondary hotness nodes in between each primary playstamp node:

(http://photos30.flickr.com/38765528_4f5142aafa_o_d.gif)

The red line you see is exactly the path hotness will follow throughout its decay.  The timespan that the horizontal axis represents will be determined by rating: a higher rating will "stretch" the decay period horizontally, while maintaining the shape of the curve.  Overall play frequency is no longer considered in this algorithm.*

Now see the dramatic effect this new approach has on an irregularly-played track:

(http://photos22.flickr.com/38765531_20b6528aed_o_d.gif)

Notice that, because the song has been played a lot recently, its hotness will remain quite high for the majority of the decay.

Likewise, a song that was played a lot in the past, then played recently after a very long break, will start with a relatively low hotness, drop off rather quickly, then plateau at a low hotness for the remainder of its decay.


I'm waiting to release the script until I make sure all the bugs are out of it, and to get some feedback.  *For instance, the length of the decay period is now determined only by rating, not by overall play frequency.  Is this a good idea / bad idea?  That's one issue that comes to mind.  Because of the quirks of this algorithm, I may also have to begin using minutes, not hours, as the unit of measure, but I'm doing my best to avoid that.

Any other feedback would be greatly appreciated.

I don't think play_stamp is available in the official 1.7.6 of play_count.  I will try and get a new version out in the next week or so with the feature you suggested as well as finalised play_stamp support (don't worry, the format won't change).

I don't think play_stamp is available in the official 1.7.6 of play_count.  I will try and get a new version out in the next week or so with the feature you suggested as well as finalised play_stamp support (don't worry, the format won't change).
[a href="index.php?act=findpost&pid=323888"][{POST_SNAPBACK}][/a]

I can't find Play Stamp either, how long until you release the code? Will it be beta or are you jumping straight into version 2? can't wait 

Quote

I don't think play_stamp is available in the official 1.7.6 of play_count.  I will try and get a new version out in the next week or so with the feature you suggested as well as finalised play_stamp support (don't worry, the format won't change).
[a href="index.php?act=findpost&pid=323888"][{POST_SNAPBACK}][/a]

I can't find Play Stamp either, how long until you release the code? Will it be beta or are you jumping straight into version 2? can't wait 
[a href="index.php?act=findpost&pid=323970"][{POST_SNAPBACK}][/a]

i'm not sure when i'll release it, i'm waiting for all the changes to foo_playcount to be finalized.  or at least until i find out from kl33per how it will behave when it's done.

i can't wait either, i really like the way this operates. 

Wow... this is taking some interesting turns. I may just switch from the SQL version of playcount to use this. I really would like to keep the playcount data in my SQL database though. oh well.  at least I will be able to use my quicktagger SQL data. lol.

@12zmcnvow1277

And what I did to get %last_played% was just edit one of the variables that my version of playcount used. sorry it took so long to get back on this. have not been able to get to my computer (I am on someone elses at the moment) and wont get back to it till after september 16th.

i have a question.
i have about 5000 songs . some of them from 6 years ago.
none of the songs has FIRST PLAYED tag. only LAST PLAYED. is there a way to add first played automaticlly to all of them by the "date created" in the explorer?

thanx.

To eliazu

You must use foo_quicktag plugin.

pIv,
great but what is the command for putting the date created file in FIRST PLAYED ?
i saw that there is import button in the quicktag plugin properties - can someone upload a file that do so?

To eliazu

You also need plugin foo_filedate: create tag Created or Added or Modified or Accessed.

Then in quicktags you create new field First_played

with value %created%' 00:00:00'

pIv,
great but what is the command for putting the date created file in FIRST PLAYED ?
i saw that there is import button in the quicktag plugin properties - can someone upload a file that do so?
[a href="index.php?act=findpost&pid=324193"][{POST_SNAPBACK}][/a]

for the purposes of hotness, i would recommend that you just let the playcount plugin create the first_played tag.  otherwise the algorithm will reflect what appears to be a large gap between the first play (the creation date) and the first play_stamp (which won't appear until you turn on foo_playcount).  in other words it will think you haven't played it at all between the time it was created and the first time you played it with foo_playcount running.

@pIv - thank you very much!
@topdownjimmy - isn't there a way to solve that? using hottness without play_stamp? arent everyone will have same problem as me?

@pIv - thank you very much!
@topdownjimmy - isn't there a way to solve that? using hottness without play_stamp? arent everyone will have same problem as me?
[a href="index.php?act=findpost&pid=324269"][{POST_SNAPBACK}][/a]

if you want to use hotness, but don't want foo_playcount to write PLAY_STAMP tags, use the old version of hotness (in the first post in this thread).

if you would like to use this version of hotness, but would still like to know when a song was added to your library, i recommend using the quicktag solution mentioned above, and writing the file creation date to a field called ADDED.  i do this in addition to using foo_playcount, so all my files have ADDED (which is done manually) and FIRST_PLAYED (which is done by foo_playcount).

This is a very interesting concept, and I'd love to try it out.

Unfortunately I can't get this to work... I display the %_hotness% field, but the value always remains at '0'.

I'm confused what fields are needed this formatting string.

I have foo_playcount, which update %play_counter% and %play_date% within the file. You mention %last_played% and %play_count% above, but those fields are null after using foo_playcount. Did you really mean  %play_date% and %play_counter%?

I have foo_filedate, but it doesn't seem to modify the %added% field.

If I try to preview the data with "Tools: Preview to Console" I get the following...

INFO (foo_ui_columns) : Preview of track 75: playstamps=0hotness=0playstoconsider=0firstconsideredplay=1fcpstamp=?--? 00:00:00decay=0recentness=0age=0period=336baselinedecay=504baselinefrequency=336frequency=0bir
th=?--? 00:00:00

@Gigglesworth

the current hotness code uses %last_played% as a tag instead of %play_date%, as does the current version of play_count (though there is a %play_date% version over there also). That version of play_count is version 1.7.6 and can be found at

http://pelit.koillismaa.fi/plugins/tagging.php#125 (http://pelit.koillismaa.fi/plugins/tagging.php#125)

foo_filedate will only modify the %added% tag when you manually tell it to do so, and the newest version of play_count uses a tag called %first_played% that will probably replace (or may already have replaced) the %added% tag.

Also make sure that you have the "make date info available" box thicked under preferances > display > columns UI > globals.
Hope this helps.


EDIT: Thinking about your post more, I have a few questions. does your playcount get modified after each time you play a song? this question comes about because you said

I have foo_playcount, which update %play_counter% and %play_date% within the file. You mention %last_played% and %play_count% above, but those fields are null after using foo_playcount. Did you really mean %play_date% and %play_counter%?

and

I have foo_filedate, but it doesn't seem to modify the %added% field.

I am wondering if you have something going on with foobar's ability to edit tags on your system

@Gigglesworth
That version of play_count is version 1.7.6 and can be found at

http://pelit.koillismaa.fi/plugins/tagging.php#125 (http://pelit.koillismaa.fi/plugins/tagging.php#125)

Ah, that's it! I had version 1.5 of play_count, which is referenced in the first post of this thread. When I install 1.7.6 it works great. Thanks for your help!

foo_filedate will only modify the %added% tag when you manually tell it to do so, and the newest version of play_count uses a tag called %first_played% that will probably replace (or may already have replaced) the %added% tag.

I didn't realize that I needed to manually run a command. That explains why %added% wasn't being updated.

Looking at version 2.0 beta 2, looks like %added% is still in there-- not quote sure what it does, and hotness still works without this tag.

Here's the code:

$puts(birth,$if2(%first_played%,$left(%added%,4)-$substr(%added%,5,6)-$right(%added%,2) 00:00:00))

EDIT: Thinking about your post more, I have a few questions. does your playcount get modified after each time you play a song? this question comes about because you said

Yes, it is modified each time. Thanks for checking.

@Gigglesworth

Glad to be of assistance.

Looking at version 2.0 beta 2

don't do that.    it's super buggy and uses a method that i've since ditched.

So...what's goin' on? Decide about releasing it yet?

got a few obstacles left.  what i need is a math/statistics major who cares about this as much as i do.

hotness 2.0...

Between the second and third graphs, how can you swap the axes? For example, in the third graph there is an 'arbitrary' three unit difference between plays, but then you assign the axis a value of 'time'?

Quote

hotness 2.0...

Between the second and third graphs, how can you swap the axes? For example, in the third graph there is an 'arbitrary' three unit difference between plays, but then you assign the axis a value of 'time'?
[a href="index.php?act=findpost&pid=325955"][{POST_SNAPBACK}][/a]

by "arbitrary" i meant arbitrary for the purposes of the graph.  in the real implementation, each three unit difference (what i'm calling a "phase" of decay) is determined very specifically by a number of factors.

deciding exactly what factors those are is one of my biggest obstacles here.  i'm working with a few different methods, but am not really happy with any of them yet.

edit: i should clarify that the vertical time axis in the first two graphs represents time in the play history of the song, and the horizontal time axis in the remaining graphs represents time in the decay period after the song is last played.

I see. I thought it might be something like that.
I was a bit bored today and decided to play around creating a hotness-ish algorithm. However, it uses an exponential function which makes it difficult to implement in tagz or tagscript. What sort of decay function have you been using?

I see. I thought it might be something like that.
I was a bit bored today and decided to play around creating a hotness-ish algorithm. However, it uses an exponential function which makes it difficult to implement in tagz or tagscript. What sort of decay function have you been using?
[a href="index.php?act=findpost&pid=326025"][{POST_SNAPBACK}][/a]

well as i show above, it's just the raw percentage of timestamps within song age.

Quote

@pIv - thank you very much!
@topdownjimmy - isn't there a way to solve that? using hottness without play_stamp? arent everyone will have same problem as me?
[a href="index.php?act=findpost&pid=324269"][{POST_SNAPBACK}][/a]

if you want to use hotness, but don't want foo_playcount to write PLAY_STAMP tags, use the old version of hotness (in the first post in this thread).

if you would like to use this version of hotness, but would still like to know when a song was added to your library, i recommend using the quicktag solution mentioned above, and writing the file creation date to a field called ADDED.  i do this in addition to using foo_playcount, so all my files have ADDED (which is done manually) and FIRST_PLAYED (which is done by foo_playcount).
[a href="index.php?act=findpost&pid=324291"][{POST_SNAPBACK}][/a]

im really annoyed by the PLAY_STAMP tags... and i'd really want to use hotness 2.0 ... am i the only one bothered by that?
hotness 2.0 without PLAY_STAMP wont give similar results?

@topdownjimmy

I was wondering if you would be willing to help me just change the current code enough to use the %first_played% tag rather than the %added% for age. i have switched over to the newer (non-sql) play_counter and would like to make use of the new field that is being added. I know there is new code on the way as soon as kleeper releases the next play_count, but i would just like to be able to use this. I am using a slightly modified version of the last_played version (I only changed %rating% to %__rating% to make use of my SQL quicktag). I have been trying to figure it out myself but i really dont know how to manipulate the Tagz code that well. thanks.

@eliazu

I doubt you could find a way to make hotness 2.0 work without the playstamps. the reason that it will be able to have a dynamic regression line in place of the current linear regression line is because it will have statistical data besides the  number of plays, last time the song was played,rating, and how long the song has been in the library. with the current data (added, first_played, last_played, rating, and play_count) you have 2 date points for the script to referance. with playstamp you will have many date points for the script to work with. this allows for more statistical date for the script to make a less linear regression line. when you have 2 points of data then all you are able to come up with is a linear function between those points, but when you have many points then the function gains the ability to become more complex. sorry, hope that is clear enough on why you can't have the hotness 2.0 without playstamp.

Nice algorithm idea!

But I was just wondering something... why do you use the %added% tag in the script?  Isn't it a bit unnecessary/unreliable?

For instance someone may add a track to their collection, but not get round to playing it for days, months, maybe even years (I have tracks which I added a year ago, I still haven’t listened to).  So often there will be a large gap between %added% and %first_played% tags, won't this mean the hotness is greatly decreased because off the large time gap?  Why can’t you use the time between %first_played% & %last_played%?

I just can't see the point of using %added% when you have the %first_played% tag to use.

(Unless I've misunderstood something?)

Bump?

This still being worked on?

Bump?

This still being worked on?
[a href="index.php?act=findpost&pid=331055"][{POST_SNAPBACK}][/a]

I am sure it is still in being worked on. be patient. this one will not be released till after the version of playcounter that does playstamps is released.

So anything to report on the new ratings system? It's been a while since someone posted on this thread? I'd be interested to know, thanks

I think topdownjimmy is waiting on the new playcount to come out before he finishes the code. I am sure that he and Kl33per are working together to make them work well together.


but this is all my speculation.

I'm waiting to release the script until I make sure all the bugs are out of it, and to get some feedback.  *For instance, the length of the decay period is now determined only by rating, not by overall play frequency.  Is this a good idea / bad idea?  That's one issue that comes to mind.  Because of the quirks of this algorithm, I may also have to begin using minutes, not hours, as the unit of measure, but I'm doing my best to avoid that.

Any other feedback would be greatly appreciated.
[a href="index.php?act=findpost&pid=323882"][{POST_SNAPBACK}][/a]

I really like the idea of Hotness, however, I wonder about just using a 5 level rating system.  I could give a few songs a 5 rating, but I could still consider 1 of them to be the best out of the group. 

I was thinking that perhaps using both a Rating of 0-10 (low to high), and a Ranking of 0-10 (low to high) would further separate the songs from one another.  By multiplying the Rating and Ranking by 5, then adding them together, you would get a value between 0-100.  Let's call this the song's Index.

The Index value obtained from these two numbers could then be used to determine the decay period.

As an example,
Song 1: Ranking 10, Rating 10 results in Index of 100
Song 2: Ranking 8, Rating 10 results in Index of 90
Song 3: Ranking 9, Rating 10 results in Index of 95

If all the songs only relied on Rating, then they would be considered to have the same quality, and thus get the same decay.

I know this would add another type of tag or field, but it should be easy to create in the globals, just like doing it for rating.

Just a thought.

the idea of Hotness, however, I wonder about just using a 5 level rating system.  I could give a few songs a 5 rating, but I could still consider 1 of them to be the best out of the group. 

I was thinking that perhaps using both a Rating of 0-10 (low to high), and a Ranking of 0-10 (low to high) would further separate the songs from one another.  By multiplying the Rating and Ranking by 5, then adding them together, you would get a value between 0-100.  Let's call this the song's Index.

The Index value obtained from these two numbers could then be used to determine the decay period.

As an example,
Song 1: Ranking 10, Rating 10 results in Index of 100
Song 2: Ranking 8, Rating 10 results in Index of 90
Song 3: Ranking 9, Rating 10 results in Index of 95

If all the songs only relied on Rating, then they would be considered to have the same quality, and thus get the same decay.

I know this would add another type of tag or field, but it should be easy to create in the globals, just like doing it for rating.

Just a thought.
[a href="index.php?act=findpost&pid=341561"][{POST_SNAPBACK}][/a]

One major problem with messing with rating and taking it away from the 5 standard is that it may then break other scripts and plugins that need it to be out of 5. This would ruin some of my scripts that I am currently using. Of this I am sure.

As for adding a new tag, I really wouldnt look forward to having to tag all of the thousands of MP3s (I rip everything I own to the computer and have over 10,000 songs to do this with) just to make one script work would be a pain in the behind indeed. If this were something that a plugin like quicktag supported then I would not be as opposed to it because I would be able to hotkey it as I went, but even then it will be a lot of work to rate all my songs.

As far as what you message from topdownjimmy that you replied to, I think that was a rather old one. Hotness is going to go a way that uses playstamps. This is going to change the way it behaves completely (please read rest of thread for how it will change). Therefore we will have already have a lot of tag size to deal with. It would be nice if kl33per could at least put the playstamp tag in a sql database so as to avoid making the metadata of a song increasingly bigger.

@kl33per and topdownjimmy.
TDJ, you may want to limit the length of time at which hotness takes is playstamp sample from, this would make it so that kl33per could possibly impliment something that would let those that really want it set foo_playcount to save only X playstamps. maybe if kl33per had a setting like that then you might be able to include an easilly editable code (basically give some indicator on which points need changing in the code) that would let people customize how many stamps hotness will look for. I dont know how much more work that would be. sorry if it is a lot more.

great work one the script and plugin guys. i look forward to the next release.


edit: thinking about it. this above might be able to be set without having the users change anything. if you were able to make it so that hotness starts its calculation from the earliest playstamp it finds rather than the first_played stamp, you may be able to work with the idea that the other guy posted on the playcount thread about limiting the number of stamps. This will also fix the problems that we all would have with the new hotness script in that we dont have playstamps yet. and therefore our songs are getting increasingly older without any playstamps. this would mean we would have a broken decay rate for our songs. the graphs would not be representative of the early decay for each song and would decay at a faster rate than i would like.

As far as what you message from topdownjimmy that you replied to, I think that was a rather old one. Hotness is going to go a way that uses playstamps. This is going to change the way it behaves completely (please read rest of thread for how it will change). Therefore we will have already have a lot of tag size to deal with. It would be nice if kl33per could at least put the playstamp tag in a sql database so as to avoid making the metadata of a song increasingly bigger.

As far as the message that I referenced, it was the one where he introduces Version 2.0.  So it is in reference to what he will be introducing.

I understand that some people wouldn't want to incorporate this type of idea, but I haven't rated any of my files, yet.  I don't have 10,000, but I do have almost 3,000, which doesn't even comprise half of the songs from my CD collection.  So this is something that I, or others in my situation could take advantage of without a problem.

I was only making a suggestion, as I don't think using a 5 point rating scale is enough to separate one song from another.

@ topdownjimmy

I am just wondering if this is still alive or not. it has been several months now since you have last posted and I am wondering if this is a dead script.

looks like b13 has a %play_count% tag with %last_played%. to me this means that hotness can now be implemented for the first time into foobar .9 .

@topdownjimmy: feel like taking a minute to update the code?

Hey!
Is it working in foobar 0.9 beta13 with foo_ui_columns ?

I don't believe it does.

For now, you can blend a color between rating and playcount to get a mini hotness rating...

Hey everyone. 

Just wanted to let you know that I am still working on this.  I've noticed that there is now %play_stamp% capability in the 0.9 beta, but I have yet to take a look at it.

To address the rating issue: even in its current state, the hotness script allows for any rating scheme you want.  Near the beginning of the code is the option of "baselinerating."  When rating is taken into account, it is measured against the baselinerating.  Thus, you could set the baseline rating to 10, for example, and rate on a scale of 1-20, making any songs with a rating of 20 twice as hot as the average song (roughly speaking).

I'm just refamiliarizing myself with the script now, it having been dormant for months, working out some kinks and finalizing the 2.0 approach described here (http://www.hydrogenaudio.org/forums/index.php?showtopic=31287&view=findpost&p=323882).  I'm still working in the 0.83 framework, though, because that's where all my playstamp data is (I haven't touched the beta since the first few versions...gotta have my last.fm!).  But I will take a look at the 0.9 beta soon, and hopefully hotness 2.0 will be ready shortly after the 0.9 final.

I am so pumped about this news. fyi "Playback statistics" is a .9 component that gives %last_played% and %play_count% .

My question is this then, has there been a release of foo_playcount that actually supports %play_stamp% yet? I have been watching the playcount thread and thus far I do not see it mentioned as being released yet.

The one in 0.9 is not the same as the foo_playcount plugin that is in 0.83.  IIRC, the one in the beta was for testing purposes.

My question is this then, has there been a release of foo_playcount that actually supports %play_stamp% yet? I have been watching the playcount thread and thus far I do not see it mentioned as being released yet.
[a href="index.php?act=findpost&pid=363669"][{POST_SNAPBACK}][/a]

As far as I know, only %play_count% and %last_played% are supported currently in 0.9beta.

As far as I know, only %play_count% and %last_played% are supported currently in 0.9beta.
[a href="index.php?act=findpost&pid=363939"][{POST_SNAPBACK}][/a]

well, I am still using 0.83, and I have no intention of upgrading as of yet. I just have not seen anything about kl33per actually releasing a foo_playcount that has %play_stamp% support. at least not within the foo_playcount thread.

@topdownjimmy:

can this code be updated for foobar .9

.9 has Playback Statistics (http://foobar2000.org/components/foo_playcount.zip) which

Collects statistics about tracks from your Media Library being played. Statistics can be displayed using %last_played% and %play_count%, or using a context menu command.

If you could update the hourly code using the new variables, that would be awesome.

the play count plug-in that was made for .9 is sketchy. it doesn't update last_played if the tag already exists, and it uses play_count instead of play_counter, so the play_count and play_counter tags have to be added to get the actual number of play counts. and as far as i can tell, play_stamp doesn't do anything, it must have been removed from .9 final.

If you could update the hourly code using the new variables, that would be awesome.

I've got the hourly decay version working with the alternative playcount plugin (not playback statistics).

Unfortunately it doesn't write the play_stamp tag yet, so hotness 2.0 will have to wait a bit longer.

Quote from: falconfox on 2006-03-29 19:21:08

If you could update the hourly code using the new variables, that would be awesome.

I've got the hourly decay version working with the alternative playcount plugin (not playback statistics).

Unfortunately it doesn't write the play_stamp tag yet, so hotness 2.0 will have to wait a bit longer.

I do not know this alternative playcount plugin that you are talking about. And I do not know a plugin that is doing the play_stamp tag yet

... nevermind. I see that it is talking about .9 and not .8x... therefore i would not know at all about the alternative plugin.

Quote from: falconfox on 2006-03-29 19:21:08

If you could update the hourly code using the new variables, that would be awesome.

I've got the hourly decay version working with the alternative playcount plugin (not playback statistics).

Unfortunately it doesn't write the play_stamp tag yet, so hotness 2.0 will have to wait a bit longer.

Could you post the updated hourly decay version?

Could you post the updated hourly decay version?

The current code works, it's just a matter of using the foo_playcount plugin as opposed to the playback statistics plugin (the former uses the tag PLAY_COUNTER, the latter uses PLAY_COUNT).  foo_playcount can be found here: http://stephan.kochen.nl/proj/foobar2000.html#playcount (http://stephan.kochen.nl/proj/foobar2000.html#playcount)

If you prefer the playback statistics plugin, just do a search and replace to the code.

Make sure you have all four checkboxes marked at the top of the "Globals" tab as well.

The current code works, it's just a matter of using the foo_playcount plugin as opposed to the playback statistics plugin (the former uses the tag PLAY_COUNTER, the latter uses PLAY_COUNT).

Great, now we are dealing with 2 standards for playcount tags. I think they should stick with a single standard and people can use whatever plugin they want without breaking their scripts that they run.

Quote from: topdownjimmy on 2006-04-16 19:36:13

The current code works, it's just a matter of using the foo_playcount plugin as opposed to the playback statistics plugin (the former uses the tag PLAY_COUNTER, the latter uses PLAY_COUNT).

Great, now we are dealing with 2 standards for playcount tags. I think they should stick with a single standard and people can use whatever plugin they want without breaking their scripts that they run.

I'm pretty confident the PLAY_COUNT tag will fall by the wayside, that component was "for testing purposes" I believe.

I'm pretty confident the PLAY_COUNT tag will fall by the wayside, that component was "for testing purposes" I believe.

I agree that it probably will. I am currently trying to get myself converted over to 0.9 and looking for all of the ported components for it. They need a thread dedicated to showing where to find ALL of the 0.9 plugs I think.

Quote from: topdownjimmy on 2006-04-17 03:07:35

I'm pretty confident the PLAY_COUNT tag will fall by the wayside, that component was "for testing purposes" I believe.

I agree that it probably will. I am currently trying to get myself converted over to 0.9 and looking for all of the ported components for it. They need a thread dedicated to showing where to find ALL of the 0.9 plugs I think.

That thread exists but it sure isn't kept up very well.

Quote from: Farinhir on 2006-04-17 03:12:53

Quote from: topdownjimmy on 2006-04-17 03:07:35

I'm pretty confident the PLAY_COUNT tag will fall by the wayside, that component was "for testing purposes" I believe.

I agree that it probably will. I am currently trying to get myself converted over to 0.9 and looking for all of the ported components for it. They need a thread dedicated to showing where to find ALL of the 0.9 plugs I think.

That thread exists but it sure isn't kept up very well.

They should sticky it then and have plug writers give updates there... would save trouble if spending 6 hours trying to get 0.9 up to a repectable standard. Now I am trying to figure out how to impliment the hotness script into 0.9.

Just replace your %play_count% or %play_counter% text with $add(%play_count%,%play_counter%). Now you have both values, and backward compatibility.

Just replace your %play_count% or %play_counter% text with $add(%play_count%,%play_counter%). Now you have both values, and backward compatibility.

I am just using the version of Foo_playcount that was ported to 0.9. That saves me all the trouble. The link for those that want it is http://stephan.kochen.nl/proj/foobar2000.html (http://stephan.kochen.nl/proj/foobar2000.html)

have fun all

Quote from: unabatedshagie on 2006-04-16 06:21:29

Could you post the updated hourly decay version?

The current code works, it's just a matter of using the foo_playcount plugin as opposed to the playback statistics plugin (the former uses the tag PLAY_COUNTER, the latter uses PLAY_COUNT).  foo_playcount can be found here: http://stephan.kochen.nl/proj/foobar2000.html#playcount (http://stephan.kochen.nl/proj/foobar2000.html#playcount)

If you prefer the playback statistics plugin, just do a search and replace to the code.

Make sure you have all four checkboxes marked at the top of the "Globals" tab as well.

Ah, it's just from the sounds of this (http://www.hydrogenaudio.org/forums/index.php?showtopic=31287&st=225#) post it was like you have to change some of the code for it to work.

I'm having a small problem now that the confusion has been sorted out, I'm using Navigator beta fcs

this is what foobar looks like with the four boxes checked at the top
(http://img159.imageshack.us/img159/926/screenshot170420060805458qt.png) (http://imageshack.us)

an this is what it's like when I uncheck enable lagacy support for globals and use global variables when sorting be column
(http://img80.imageshack.us/img80/9909/screenshot170420060806152vz.png) (http://imageshack.us)

Is there anyway to get this to work correctly without making the rest of the display look naff?

The difference between Play counter and playback statistics is that the latter stores the data in the DB while the first tags the files. Personally I much rather have the data stored in the DB rather than the file tags. But either way, I can't get it working  The hotness value is always undefined for me.

Finally figured it out! I removed the use of the legacy global variables and replaced them with the global set and get functions used in the columns ui for 0.9. I also added the color blending to the globals so that it does not need to be blended twice.

Replace the "calculate "hotness" portion of the code with: (may be different for the other codes, but this is from the hourly decay version)

// calculate "hotness"
$puts(hotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))

$set_global("hotness",$get(hotness))
$set_global("hot_color",$blend(FFFFFF,0000FF,$get(hotness),100))

Now you can set the color in the column styles using

$set_style(text,$get_global("hot_color"),$get_global("hot_color"))

and sort using

$get_global("hotness")

The difference between Play counter and playback statistics is that the latter stores the data in the DB while the first tags the files. Personally I much rather have the data stored in the DB rather than the file tags. But either way, I can't get it working  The hotness value is always undefined for me.

Finally figured it out! I removed the use of the legacy global variables and replaced them with the global set and get functions used in the columns ui for 0.9. I also added the color blending to the globals so that it does not need to be blended twice.

Replace the "calculate "hotness" portion of the code with: (may be different for the other codes, but this is from the hourly decay version)

Code: [Select]

// calculate "hotness"
$puts(hotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))

$set_global("hotness",$get(hotness))
$set_global("hot_color",$blend(FFFFFF,0000FF,$get(hotness),100))

Now you can set the color in the column styles using

Code: [Select]

$set_style(text,$get_global("hot_color"),$get_global("hot_color"))

and sort using

Code: [Select]

$get_global("hotness")

Thanks for that, with a little bit of tweaking I managed to fix my problem too
(http://img110.imageshack.us/img110/9281/screenshot170420061244078hr.png) (http://imageshack.us)

After some more playing around, I noticed you could blend the text color and selected text color simultaneously.

$set_global("hot_color",$blend(FFFFFF|FFFFFF,0000FF|0000FF,$get(hotness),100))

Now you only have to set the regular text color!

$set_style(text,$get_global("hot_color"))

After some more playing around, I noticed you could blend the text color and selected text color simultaneously.

Code: [Select]

$set_global("hot_color",$blend(FFFFFF|FFFFFF,0000FF|0000FF,$get(hotness),100))

Now you only have to set the regular text color!

Code: [Select]

$set_style(text,$get_global("hot_color"))

ok, now I am trying to figure out how to use your blending with my color scheme which is given by the follow code (well this was actually someone else's but I have adopted it)

//colours used, hotness=100:0
$puts(colour100,0000FF)
$puts(colour99,0000FF)
$puts(colour75,00FFFF)
$puts(colour50,00FF00)
$puts(colour25,FF8800)
$puts(colour0,880000)

//dotshading
$if(%last_played%,
$select(
$add($put(hotdiv,$div($get_global("hotness"),25)),1)
$puts(shade,$sub($get_global("hotness"),$mul($get(hotdiv),25))),
$blend($get(colour0),$get(colour25),$get(shade),25),
$blend($get(colour25),$get(colour50),$get(shade),25),
$blend($get(colour50),$get(colour75),$get(shade),25),
$blend($get(colour75),$get(colour99),$get(shade),25),
$get(colour100)
)•

Also... I was thinking that it would be interesting to see hotness maybe get integrated into a plugin that might allow us to have foobar change how it works with random play. Basically, I was thinking that it would be kewl if one could have it where the hotter songs  are less likely to get played than the cooler songs with random track on. I understand that it would probably have to remain also as a global for us to continue to use it as we have. This was just an idea that I thought was kind of interesing.

is it possible for the hotness to also be displayed in the trackinfo component, can it share global variables from columns?

Also... I was thinking that it would be interesting to see hotness maybe get integrated into a plugin that might allow us to have foobar change how it works with random play. Basically, I was thinking that it would be kewl if one could have it where the hotter songs  are less likely to get played than the cooler songs with random track on. I understand that it would probably have to remain also as a global for us to continue to use it as we have. This was just an idea that I thought was kind of interesing.

I have also been thinking that a scriptable shuffle mode would be pretty cool - it would expand on the different shuffle modes like track, album etc. already available. I'm sure it's technically possible, though of course I have no coding skillz...

though of course I have no coding skillz...

That is also my case. I have forgotten everything I learned about C. My main interest nowdays is studying Japanese.

I'd love to see hotness as a plugin, simply so its value would be completely global. Creating an autoplaylist would certainly be useful.

Or, perhaps it would be better to have a plugin that provided a space to create truely global variables. Exactly like the area in Columns UI but with the variables available to all other plugins etc. Is that possible? Seems surprising that no-one has implemented it already if it is...

Or, perhaps it would be better to have a plugin that provided a space to create truely global variables. Exactly like the area in Columns UI but with the variables available to all other plugins etc.

Maybe that would be better time spent... but I would also like to see a way to make hotness more useful rather than just a trivial but fun digit on the right side of the playlist. I like having it there. It has also been interesting to see how its concept has changed. But it think it is time that it could start to pull its weight around and actually start affecting other things. I personally like to hear almost all of my music and listen to extremely large playlists. I would love to be able to set up a random criteria that would make it so that the hotter the song, the less likely it is going to be pleyed. Maybe something like a song with hotness of 100 has no probability of being played with this random criteria. The probability of a song being selected would then increase slowly depending on how low its hotness value has become. So a song (or many songs) with 0 hotness would have the highest priority for being selected.

The idea of this plugin would not only use hotness, it would also be able to use other tags that have been made available through the many other plugins to customize how people would have their random play worked. This thought came to be because I was listening to a large playlist of over 100 songs and realized that I had heard the same couple of songs a number of times in under 2 hours.

I would also be greatful if someone was able to help me get my multicolor blend worked into the new code... - see 5 posts up for details

I would also be greatful if someone was able to help me get my multicolor blend worked into the new code... - see 5 posts up for details

i haven't studied it extensively, but keep in mind that when foobar divides 10 by 25, it gives 0, not 0.4.  the trick of course is to multiply hotness by 100 before dividing.

It appears that the next version of Columns UI would have truly global variables.

It appears that the next version of Columns UI would have truly global variables.

Really? If that is true then all we would need is a plug that would allow us to use them for random play... sorry... off topic.

Hi guys!

the use of play_counter doesn't seam to work. I'm using the hourly decay version with an "album rating" tag.
As u can see in my screen, song #2, #5 and #6 have been played at the same time though they have very different play_counter stats.

I just paste/copy the standard hourly decay version and changed "rating" to "album rating" (which actually works)
I'm using the play counter mod at version 1.92 and have foobar 0.91

(http://img112.imageshack.us/img112/5935/13xy6.th.jpg) (http://img112.imageshack.us/my.php?image=13xy6.jpg)

Could anyone help me with that?

Hi guys!

the use of play_counter doesn't seam to work. I'm using the hourly decay version with an "album rating" tag.
As u can see in my screen, song #2, #5 and #6 have been played at the same time though they have very different play_counter stats.

I just paste/copy the standard hourly decay version and changed "rating" to "album rating" (which actually works)
I'm using the play counter mod at version 1.92 and have foobar 0.91

(http://img112.imageshack.us/img112/5935/13xy6.th.jpg) (http://img112.imageshack.us/my.php?image=13xy6.jpg)

Could anyone help me with that?

hotness heavily weighs how recently a song was played.  it also doesn't care how many times a song was played, except in regard to how frequently it's been played.  furthermore, the code for the hourly decay version is very old, relying on the ADDED tag field rather than the FIRST_PLAYED tag field provided by foo_playcount.  if you don't have ADDED tag in a particular song, the hotness code assumes you listen to it with an average frequency.

i've been waiting for an update to the foo_playcount plugin for some time now, to include PLAY_STAMP tags for every time a track has been played, but because this doesn't appear to be happening, i should probably just update the old algorithm for better use with 0.9.x.  i'll see if i can do that today.

I think playstamps will be considered by many to be a bit excessive. But yes any updates that work with exsiting data and the currently available plugins for 0.9 would be much appreciated

i've been waiting for an update to the foo_playcount plugin for some time now, to include PLAY_STAMP tags for every time a track has been played, but because this doesn't appear to be happening, i should probably just update the old algorithm for better use with 0.9.x.  i'll see if i can do that today.

That would be awesome if you can update it.

It would also be nice if you can include the use of the play_counter variable.
Meaning by that -> the hotness of a song that has been played 100 times does not decay as fast as a song with only 10 play times.

that would look like this (after 24 hours):

artist : song : playcount : hotness
xxx  : aaa  : 100        : 88
xxx  : bbb  : 10          : 76

not sure if this is possible tho

Quote

i've been waiting for an update to the foo_playcount plugin for some time now, to include PLAY_STAMP tags for every time a track has been played, but because this doesn't appear to be happening, i should probably just update the old algorithm for better use with 0.9.x.  i'll see if i can do that today.

That would be awesome if you can update it.

It would also be nice if you can include the use of the play_counter variable.
Meaning by that -> the hotness of a song that has been played 100 times does not decay as fast as a song with only 10 play times.

that would look like this (after 24 hours):

artist : song : playcount : hotness
xxx  : aaa  : 100        : 88
xxx  : bbb  : 10          : 76

not sure if this is possible tho

the code has a very specific goal.  what i wanted to create was an alternative to playcount as a measure of the song's "quality" or "enjoyment" or whatever.  instead i focus on frequency.  if you play song #1 ten times in a week, it will decay more slowly than a song that you play fifty times in ten weeks.  so, it does take playcount into account, but only to calculate overall play frequency.

I think playstamps will be considered by many to be a bit excessive. But yes any updates that work with exsiting data and the currently available plugins for 0.9 would be much appreciated

yes, many may find playstamps excessive, but surely the option to use them could be made available.  i for one would love to have this data, as it allows for much more nuanced decay curves, as explained a few pages ago.

see first post for updated code

For those of you using navigator 1.4.2 here is a version of the code which works regardless of the color scheme used.

Thanks to topdownjimmy for making the code in the first place and to OCedHrt for working out how to disable legacy support for globals in columnsui.

replace this part of the code

// calculate "hotness"
$puts(hotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))

$set_global("hotness",$get(hotness))
$set_global("hot_color",$blend($get(bg_color2),$get(special_color),$get(hotness),100))

create a hotness column and make sure use custom style spec is checked

in display tab put

$get_global(symbol_rating)

this uses the rating symbol that the rest of the playlist uses (suppose you could use any symbol that you want here)

in the style tab put

$set_style(text,$get_global("hot_color"))

thanks jimmy for update, its really better than play_count!

I thought about a better visual. I'd like to have a text instead of the dot or a number.
something like this

song hotness text
xxx 0-15 "don't click me"
yyy 30-60 "u maybe like it"
zzz 60-100 "HOOOOT"

i have probs with coding though, can someone help me?

I thought about a better visual. I'd like to have a text instead of the dot or a number.
something like this

song hotness text
xxx 0-15 "don't click me"
yyy 30-60 "u maybe like it"
zzz 60-100 "HOOOOT"

i have probs with coding though, can someone help me?

Thanks for the idea ! Quickly done:

$if(
$greater($get_global("hotness"),66),Hot!!!, //hotness > 66
$if(
$greater($get_global("hotness"),33),Warm, //hotness > 33
$if(
$greater($get_global("hotness"),0),Cold..., //hotness > 0

)))

And of course a big thanks to Jimmy for this great code !

Well. I finally figured out the problem with the style code in my post way back on Apr 22 2006, 20:40. I have basically done a full rewrite on it to get the effects that I wanted and I thought I would share it with others. Also, if any of you know of a better way to get this type of effect let me know.

$if(
$strcmp($get_global("hotness"),100),0000FF|0000FF,

$if(
$and(
$greater(100,$get_global("hotness")),$greater($get_global("hotness"),74)),
$blend(0000FF|0000FF,00FFFF|00FFFF,$div($mul($get_global("hotness"),25),25),25),

$if(
$and(
$greater(75,$get_global("hotness")),$greater($get_global("hotness"),49)),
$blend(00FF00|00FF00,00FFFF|00FFFF,$div($mul($get_global("hotness"),25),25),25),

$if(
$and(
$greater(50,$get_global("hotness")),$greater($get_global("hotness"),24)),
$blend(00FF00|00FF00,FF8800|FF8800,$div($mul($get_global("hotness"),25),25),25),

$if(
$and(
$greater($get_global("hotness"),0),$greater(25,$get_global("hotness"))),
$blend(880000|880000,FF8800|FF8800,$div($mul($get_global("hotness"),25),25),25),880000|880000

)))))

This basically blends from red to yellow for hotness between 100 and 75, yellow to green for 75 to 50, green to light blue for 50 to 25, and light blue to navy for 25 to 0.


edit: spelling errors and making code more manageable for display
Edit 2: Corrected code.

See Above

that works only if i replace $get_global("hotness") with %_hotness% other wise it's all dark blue for me

but still some of the 99 are darkblue..

Quote from: Farinhir on 2006-06-11 18:04:59

See Above

that works only if i replace $get_global("hotness") with %_hotness% other wise it's all dark blue for me

I am sorry. I forgot to mention that I was using part of unabatedshagie's code for my calculate hotness. The setup on my style code was dependant upon this change. So yeah, for those that are still using Topdownjimmy's unaltered code, replace the

 $get_global("hotness")

with

 %_hotness%

I replaced my calculate hotness with

 
// calculate "hotness"
$puts(hotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))

$set_global("hotness",$get(hotness))

hope that helps to explain how to set up the color scheme if you want to try it. Thank you brilliantGreen (great band by the way) for pointing that out.

EDIT: ok. The reason that It is turning blue is because the songs at hotness 99 were aparently not being included in the above. Therefore I changed the value from 99 to 100 in the 2nd $if(). I am posting the update in the earlier post so that I am not using a ton of landscape for this.

Edit: corrected code

You have got another two mistake in the code, you don't need the last ')', if i don't remove the last ')' nothing happend until i remove it.
And the repalcement is "%_hotness%" anfd not "%__hotnesss%".

You have got another two mistake in the code, you don't need the last ')', if i don't remove the last ')' nothing happend until i remove it.
And the repalcement is "%_hotness%" anfd not "%__hotnesss%".

Ok... Code has been corrected. I wrote that code after pulling an alnight study session for my exams that I am currently getting ready for so I was exhausted. Interestingly enough, the code worked for me with the extra ')'. Thanks for pointing these out to me.

Hey. I got a problem. I use Azreal (http://www.hydrogenaudio.org/forums/index.php?showtopic=33450&hl=azreal) for my formatting. The problem is that when i checkmark "Enable legacy support for globals" the colors get all screwed up, but the %_hotness% variable works. When i disable it, all the colors look fine, but %_hotness% doesn't work any longer. I am wondering if there is some fix for this.

Also, playcount 1.2 doesn't seem to be working with the latest beta. is hotness going to be converted back to the official playcount method or should i manually edit the code?

I posted a way above to edit the hotness code to make it work with the enable legacy support for globals disabled.

Af for the official playcount plugin, it doesn't add first_played data so it's impossible to make the hotness code work with it, you will need to wait until the "unofficial" one gets updated.

I posted a way above to edit the hotness code to make it work with the enable legacy support for globals disabled.

Af for the official playcount plugin, it doesn't add first_played data so it's impossible to make the hotness code work with it, you will need to wait until the "unofficial" one gets updated.

Alright, i looked at your edit and everything is working properly now. Thanks!

Is anybody even working on updating the unofficial playcount component.  There appears to not be any recent activity in its corresponding thread, and I am unware of anyone showing an interest in updating it?

Is anybody even working on updating the unofficial playcount component.  There appears to not be any recent activity in its corresponding thread, and I am unware of anyone showing an interest in updating it?

Watch this thread for updates un your favorite Foobar plugs. They will post yellow date next to the updated components.


lol... sorry.. just realized that i had forgotten to post the link...  not that it matters much now

Quote from: Stuart60611 on 2006-08-01 18:21:34

Is anybody even working on updating the unofficial playcount component.  There appears to not be any recent activity in its corresponding thread, and I am unware of anyone showing an interest in updating it?

Watch this thread for updates un your favorite Foobar plugs. They will post yellow date next to the updated components.

Unofficial playcount has been updated (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=42625&view=findpost&p=417705).

I posted a way above to edit the hotness code to make it work with the enable legacy support for globals disabled.

Af for the official playcount plugin, it doesn't add first_played data so it's impossible to make the hotness code work with it, you will need to wait until the "unofficial" one gets updated.

Weird, seems like I already posted code that worked without "enable legacy support for globals" months ago ^^. Additionally, hotness does not require first_played to work properly. I haven't been using that since the beginning.

-Update-
Oh you already referred to me before ^^. Anyways, some more detail reguarding that first_played thing. The original hotness script uses the tag %added% to calculate age, which not used by either official or unofficial playcount, so it hasn't been doing anything with the age of the file if you have been using the script I posted a few months back.

Here's a script for usage with the official playcount:

/////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// hourly decay version
/////////////////////////////////////////

// baselines: define baseline frequency and decay periods
//
// baselinefrequency: decrease if songs stay hot too long
// baselinedecay: decrease if too many songs are hot
//
$puts(baselinefrequency,14)    
$puts(baselinedecay,7)    

// convert baselines to hours
$puts(baselinefrequency,$mul($get(baselinefrequency),24))    
$puts(baselinedecay,$mul($get(baselinedecay),24))    

// calculate "age": the number of hours the song has been in the library
// actually it's just hardcoded ^^
$puts(age,$mul(%play_counter%,$get(baselinefrequency)))    

// calculate "recentness": number of hours since song was last played
$puts(recentness,
$sub(
$add(
$mul(
$add(
$mul($right(%_system_year%,2),365),
$select(%_system_month%,0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($right(%_system_year%,2),4),$if($or($greater(%_system_month%,2),$greater($mod(%_system_year%,4),0)),1,0)),
%_system_day%
),
24
),
%_system_hour%
)
,
$add(
$mul(
$add(
$mul($substr(%last_played%,3,4),365),
$select($substr(%last_played%,6,7),0,31,59,90,120,151,181,212,243,273,304,334),
$add($div($substr(%last_played%,3,4),4),$if($or($greater($substr(%last_played%,6,7),2),$greater($mod($substr(%last_played%,1,4),4),0)),1,0)),
$substr(%last_played%,9,10)
),
24
),
$substr(%last_played%,12,13)
)
)
)    

// calculate "decay": the specific decay period
$puts(decay,$div($mul(%play_count%,$get(baselinefrequency),$get(baselinedecay),$if2(%rating%,$get(avgrating))),$mul($max($get(age),$get(baselinefrequency)),3)))    

// calculate "hotness"
$puts(hotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))

$set_global(hotness,$get(hotness))
$set_global(hot_color,$blend(FFFFFF|FFFFFF,0000FF|0000FF,$get(hotness),100))

/////////////////////////////////////////

Of course, all credits to the original person who came up with the idea of hotness

If you looked at the code I posted I credited you with writing the code, I just changed a couple of things.

As for the first_played issue, you are right. I forgot that it doesn't use first_played. My bad 

If you looked at the code I posted I credited you with writing the code, I just changed a couple of things.

As for the first_played issue, you are right. I forgot that it doesn't use first_played. My bad 

I noticed that afterwards

You could use the first_played data if you want. Replace %added% with %first_played% and it should work as intended. However, I prefer to keep my playback statistics out of the files so I'm glad I can get rid of the unofficial playcount  Was once a live saver though, great job to the guys who help(ed) maintain it.

Quote from: unabatedshagie on 2006-08-06 12:51:29

If you looked at the code I posted I credited you with writing the code, I just changed a couple of things.

As for the first_played issue, you are right. I forgot that it doesn't use first_played. My bad 

I noticed that afterwards

You could use the first_played data if you want. Replace %added% with %first_played% and it should work as intended. However, I prefer to keep my playback statistics out of the files so I'm glad I can get rid of the unofficial playcount  Was once a live saver though, great job to the guys who help(ed) maintain it.

Can this code work without the firstplayed or added fields?

Quote from: OCedHrt on 2006-08-06 12:59:23

Quote from: unabatedshagie on 2006-08-06 12:51:29

If you looked at the code I posted I credited you with writing the code, I just changed a couple of things.

As for the first_played issue, you are right. I forgot that it doesn't use first_played. My bad 

I noticed that afterwards

You could use the first_played data if you want. Replace %added% with %first_played% and it should work as intended. However, I prefer to keep my playback statistics out of the files so I'm glad I can get rid of the unofficial playcount  Was once a live saver though, great job to the guys who help(ed) maintain it.

Can this code work without the firstplayed or added fields?

The one I posted a few posts back does not use the first_played or added fields. Even the original code did not require them, though it had the option to use the added field.

Did the development of hotness move from topdownjimmy's hands?

Did the development of hotness move from topdownjimmy's hands?

It's not really development. Merely keeping the script up-to-date with changes in columnsui and foobar.

Actually I would like to develop it further, unfortunately neither of the playcount components support %play_stamp%, so I'm unable to make any progress.

one question. Ive updated the official playback statics component to the version released today, that has the %fist_played% stamps. now I have a lot of files with a %first_played% stamp with today's date and a much older %last_played% stamp. would the hotness code still work? how could I fix it?

If the component updated the %first_played% stamp, wouldn't it also update the %last_played% stamp, so that both are the same?

You make it sound as though you're dealing with files that didn't used to have %first_played% stamps.  In that case there would be no danger in copying the %last_played% values to %first_played% using masstagger.

I am having a problem with the code listed several posts above.  I use $get_global(hotness) in the column's custom sort tab and have use custom sort checked.  When I click on the column header it sorts correctly but it places the single digit numbers next to the double digit numbers.  For example, I get several 2s and then 20, 21, etc. 

Also, is there a way to display hotness in a track info panel?

I am having a problem with the code listed several posts above.  I use $get_global(hotness) in the column's custom sort tab and have use custom sort checked.  When I click on the column header it sorts correctly but it places the single digit numbers next to the double digit numbers.  For example, I get several 2s and then 20, 21, etc. 

Also, is there a way to display hotness in a track info panel?

use

$num($get_global(hotness),3)

i think cwb_hooks will allow you to use hotness in track info.  i plan to code for this.

Hello. With the new Official Playback Statistics 1.3.2 (http://www.foobar2000.org/components/index.html), i noticed that:

1.) %first_played% has become %first_played_timestamp%
2.) %last_played% has become %last_played_timestamp%

obviously this screws things up. I know it is a simple find and replace, but it might just be a good idea to fix the first post. As long as you editting that first post, can you add a script that uses the official plugin and "no legacy support for globals".

Also, i think it is safe to remove any unofficial plugin support, since it isn't working anyways.

Also, i think it is safe to remove any unofficial plugin support, since it isn't working anyways.

I don't use hotness, but just letting you know, it does work, even with the newest fb. There was an update released a little while ago that fixed the problems.

Saying that, it doesn't work for WMA files..

Hello. With the new Official Playback Statistics 1.3.2 (http://www.foobar2000.org/components/index.html), i noticed that:

1.) %first_played% has become %first_played_timestamp%
2.) %last_played% has become %last_played_timestamp%

obviously this screws things up. I know it is a simple find and replace, but it might just be a good idea to fix the first post. As long as you editting that first post, can you add a script that uses the official plugin and "no legacy support for globals".

Also, i think it is safe to remove any unofficial plugin support, since it isn't working anyways.

What the heck is the developer of the "official" playback statistics thinking by changing the tag standards? Long before fb2k v0.9.0 had come out we were all using mostly %first_played%. %last_played%, and %play_counter%. I don't know if these were posted on the official accepted tags list or not, but I do know that they were unofficially accepted as a standard tag set for the playcount plugs. There needs to be some talks within the fb2k community about standards for these then, and I will be in support of the %first_played%. %last_played%, and %play_counter% standard because I do not plan to change 9000+ songs tags (even with masstagger it will tack too much time) and all my interface setup uses those tags. Even if the tags are not set as the official standard, they should not be changed by only one person's ideals. Especially when too many people are using the "unoffical " standard.

Can someone point me in the direction of this so called "official" playback statistics' thread so that I might speak my complaints there. I, personally, will not change over unless the entire community decides to do so. It is easier for me to change other peoples scripts to match my tags than for my tags to be changed over to match their scripts.

Hello. With the new Official Playback Statistics 1.3.2 (http://www.foobar2000.org/components/index.html), i noticed that:

1.) %first_played% has become %first_played_timestamp%
2.) %last_played% has become %last_played_timestamp%

obviously this screws things up. I know it is a simple find and replace, but it might just be a good idea to fix the first post. As long as you editting that first post, can you add a script that uses the official plugin and "no legacy support for globals".

Also, i think it is safe to remove any unofficial plugin support, since it isn't working anyways.

I'm using the latest official playcount plugin and hotness, and %first_played% and %last_played% haven't changed, plus since when it was made possible to write to files with the official plugin, it has always been %first_played_timestamp% and %last_played_timestamp% that were written to the file.
So i don't get what you mean by saying they changed?

Quote from: falconfox on 2006-09-26 18:46:54

Hello. With the new Official Playback Statistics 1.3.2 (http://www.foobar2000.org/components/index.html), i noticed that:

1.) %first_played% has become %first_played_timestamp%
2.) %last_played% has become %last_played_timestamp%

obviously this screws things up. I know it is a simple find and replace, but it might just be a good idea to fix the first post. As long as you editting that first post, can you add a script that uses the official plugin and "no legacy support for globals".

Also, i think it is safe to remove any unofficial plugin support, since it isn't working anyways.

I'm using the latest official playcount plugin and hotness, and %first_played% and %last_played% haven't changed, plus since when it was made possible to write to files with the official plugin, it has always been %first_played_timestamp% and %last_played_timestamp% that were written to the file.
So i don't get what you mean by saying they changed?

Sigh... The original playback statistics that worked with 0.8.3 was made by tboehrer/kl33per. They used the format that I mentioned and that the unofficial playcount plug continues to use. The official playback statistics is trying to introduce new tags rather than using the older ones that everyone was using before. I am guessing that you have not used fb2k 0.8.3 with the older playcounter plug that kl33per/tboehrer started. The tags that the unofficial plugin use have been around much longer than that of the official. Why do you think that there are 2 plugs that do the same thing, with the unofficial having more people supporting it? Just because something is labeled "official" doesn't automatically make it better.

An example would be saying that the creative drivers are better for creative sound cards than the KX project drivers. But anyone who has ever tried the KX drivers long enough to understand them knows that the creative drivers are inferior for those of us that record music and care about our sound. Another thing to think about is that Topdownjimmy has be developing "hotness" longer than the "official" playback statistics plug came out. What standard does he sill endorse. The older one which most people who have been using foobar since before the 0.9 release are on.

Edit: there is another thread out there somewhere about tag standards. If we are to continue this discussion then we should dig that old thread out of retirement I think.

I'm not understanding the problem.

Since the official playcount plugin for 0.9x started supporting writing statistics to files, the tags written were %first_played_timestap% and %last_played_timestamp%, while %first_played% and %last_played% are still there for calling the statistics information. Nothing has changed as far as i know.

The hotness code in my foobar uses %first_played% and %last_played%, and it works perfectly with the official plugin 1.3.2 ( now if i could get it to work with single_column_playlist ).

I'm not understanding the problem.

Since the official playcount plugin for 0.9x started supporting writing statistics to files, the tags written were %first_played_timestap% and %last_played_timestamp%, while %first_played% and %last_played% are still there for calling the statistics information. Nothing has changed as far as i know.

The hotness code in my foobar uses %first_played% and %last_played%, and it works perfectly with the official plugin 1.3.2 ( now if i could get it to work with single_column_playlist ).

I have used the hotness code with both official and unoffical playcount without issue.  You just need to adjust the code to use %playcount% for offical and %playcounter% for unofficial, where applicable in the code.  As far as using hotness with the single column playlist, I have not tried it, but I think it should work fine in the sasme way that you access the variable in the normal Columns UI playlist b/c the single column playlist has been recently updated to support global variables.  As such, if you use the hotness code for the global tab listed in this thread, it should work.

I have used the hotness code with both official and unoffical playcount without issue.  You just need to adjust the code to use %playcount% for offical and %playcounter% for unofficial, where applicable in the code.  As far as using hotness with the single column playlist, I have not tried it, but I think it should work fine in the sasme way that you access the variable in the normal Columns UI playlist b/c the single column playlist has been recently updated to support global variables.  As such, if you use the hotness code for the global tab listed in this thread, it should work.

My issue with it is primarily the introduction of the %play_count% tag rather than sticking to %play_counter% which most of us used. I understand how to change the code to suit the new tags. The problem for me (and I am sure for many others) is having to change from one tag standard to another after all your tags have been written in the old standard. I have an excess of 9000 tracks with all of them having the %play_counter% tag. Since I do not have a nice dual core system, it will take several hours for my computer to process a masstagger script to change them all. Now I do now have the luxury to be able to do such a thing either as I need to be able to use my computer for work. Now I know that the %play_counter% tag did not have the debating about it as some of the other tags did, but they should not just add a new format when most were on a perfectly fine format for that tag. Then there is the ussue of these

1.) %first_played% has become %first_played_timestamp%
2.) %last_played% has become %last_played_timestamp%

A long time ago there was a long thread where people were trying to figure out tag standards. The following page was a result of that and you will see that the %first_played% %last_played% are on there.

http://wiki.hydrogenaudio.org/index.php?ti...d_Tag_Standards (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standards)

If you want to see all that went into that debate then the link to the thread is also posted on that page. I am just frustrated because there was a standard that was agreed upon and now someone trying to change it. Part of the reason for a needed standard for these tags is when someone wants to write a plug that will call upon one of them. Are they to write the plug to cover all possible variants on that tag. If they do then their plug will be a memory hog and slow fb2k down quite a bit.

EDIT:

I have used the hotness code with both official and unoffical playcount without issue.

If this were just about the hotness code then it would be an easy fix. Truth be told that I have ALL my scripts set for the standard that started with the afore mentioned page. For me to change over would be a lot of unnecessary work.

I hear you on the playcounter issue.  I was on the forum when the thread you posted above was active and was as surprised as you were with the methodology chosen for the official playback statistics release and only use unofficial as well.  However, I think it is best that this issue be discussed on another thread b/c this thread really should be dedicated to hotness.

Let me make it clear that none of these issues have merit.

The official play counter uses different file tags, but exposes "play_count," "first_played," and "last_played" through the media library. The reason why the file tags are actually called "last_played_timestamp" and "first_played_timestamp" is because they're not actually a date timestamp like "first_played" and "last_played," but are rather in a different format. Using the media library exposed "first_played" and "last_played" will present the tags if they exist, else if not, convert the timestamps dynamically into the relevant format. Additionally, the "play_count" exposed by the media library combines both "play_count" and "play_counter" tags if they exist.

I would guess that the intentional effort to use different tags is so that both the official and non-official versions of the playback statistics/play counter plugins can coexist without conflicts.

Sorry for the bump, but I have a few newbie questions
First, I would like to know how I can add the %added% tag to all of my songs.
Secondly, I would like to know if there is a way to make this work with single column playlist. I put the code in the columns_ui global variables section, but I don't know how to display the dot.

Thanks in advance,


Clint

First, I would like to know how I can add the %added% tag to all of my songs.

This was done with an old component for 0.8.3.  I don't remember what it was called, but in any case, it's no longer being developed and was cumbersome anyway.  I think you might be able to write a masstagger script using foo_cwb_hooks (http://wiki.bowron.us/index.php/Foobar2000:Hooks), which can give you the system date.

Secondly, I would like to know if there is a way to make this work with single column playlist. I put the code in the columns_ui global variables section, but I don't know how to display the dot.

I recently adopted SCP and encountered this same problem.  foo_cwb_hooks saves the day by providing the necessary functionality.  I intend to post an SCP version soon.

Would be great if your  new version also worked for trackinfo mod, which should be fairly easy b/c they use basicly the same syntax.

Would be great if your  new version also worked for trackinfo mod, which should be fairly easy b/c they use basicly the same syntax.

Absolutely -- forgot to mention that. 

Sorry for the bump, but I have a few newbie questions
First, I would like to know how I can add the %added% tag to all of my songs.
Secondly, I would like to know if there is a way to make this work with single column playlist. I put the code in the columns_ui global variables section, but I don't know how to display the dot.

Thanks in advance,


Clint

The official play counter can write the first_played tag. While not exactly an added tag, it may be close enough for you.

The official play counter can write the first_played tag. While not exactly an added tag, it may be close enough for you.

Actually, I think it is both the official and unofficial (which I use) that give the first_played tag. Just an FYI.

Any recommendations on how to portray hotness in SCPL?  I don't like the idea of just a number, and the SCPL formatting language offers some cool possibilities.  Ideas?

Any recommendations on how to portray hotness in SCPL?  I don't like the idea of just a number, and the SCPL formatting language offers some cool possibilities.  Ideas?

Possibly a colored meter with numerical data also going from black to red?  Could be also cool if it displayed some data on the decay rate in an understandable form (which will obviously very from track to track based on rating, playcount, etc.), such as loosing a ___ number of hotness points per hour for the given track.

Quote from: topdownjimmy on 2006-12-03 01:52:03

Any recommendations on how to portray hotness in SCPL?  I don't like the idea of just a number, and the SCPL formatting language offers some cool possibilities.  Ideas?

Possibly a colored meter with numerical data also going from black to red?  Could be also cool if it displayed some data on the decay rate in an understandable form (which will obviously very from track to track based on rating, playcount, etc.), such as loosing a ___ number of hotness points per hour for the given track.

Forgot to add that I also think you should just have a version that uses an variable assigned a number for those who want to do it the old fashion way or innovate with a new display.

Quote from: topdownjimmy on 2006-12-03 01:52:03

Any recommendations on how to portray hotness in SCPL?  I don't like the idea of just a number, and the SCPL formatting language offers some cool possibilities.  Ideas?

Possibly a colored meter with numerical data also going from black to red?  Could be also cool if it displayed some data on the decay rate in an understandable form (which will obviously very from track to track based on rating, playcount, etc.), such as loosing a ___ number of hotness points per hour for the given track.

Portraying the decay rate is a good idea, to let you know how strong the hotness is.

Quote from: Stuart60611 on 2006-12-03 02:09:13

Quote from: topdownjimmy on 2006-12-03 01:52:03

Any recommendations on how to portray hotness in SCPL?  I don't like the idea of just a number, and the SCPL formatting language offers some cool possibilities.  Ideas?

Possibly a colored meter with numerical data also going from black to red?  Could be also cool if it displayed some data on the decay rate in an understandable form (which will obviously very from track to track based on rating, playcount, etc.), such as loosing a ___ number of hotness points per hour for the given track.

Portraying the decay rate is a good idea, to let you know how strong the hotness is.

Exactly.

Please help me test Hotness 1.5.c.1, updated for compatibility with foo_cwb_hooks (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:0.9_CwBowron's_Title_formating_(foo_cwb_hooks)) and therefore with foo_uie_trackinfo_mod (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:0.9_Track_Info_Panel_Mod_%28foo_uie_trackinfo_mod%29) and foo_uie_single_column_playlist (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:0.9_Single_Column_Playlist_%28foo_uie_single_column_playlist%29).

/////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// v1.5.c.1 (foo_cwb_hooks version)
// Dec 5, 2006 - by topdownjimmy 
/////////////////////////////////////////
//
// configure baselines: define baseline playfrequency and decay period (in days)
//
   $puts(baselinefrequency,28) // decrease if songs stay hot too long
   $puts(baselinedecay,7) // decrease if too many songs are hot
//
// configure default rating for unrated songs
//
   $puts(avgrating,3)
//   
// DO NOT EDIT BELOW THIS LINE //
$puts(baselinefrequency,$mul($get(baselinefrequency),24))
$puts(baselinedecay,$mul($get(baselinedecay),24))
$puts(lp_age,$add($substr(%last_played%,12,13),
 $mul(24,$cwb_datediff(%last_played%,2000-01-01))))
$puts(fp_age,$add($substr(%first_played%,12,13),
 $mul(24,$cwb_datediff(%first_played%,2000-01-01))))
$puts(age,$sub($get(lp_age),$get(fp_age)))
$puts(now_age,$add($substr(%cwb_systemdatetime%,12,13),
 $mul(24,$cwb_datediff(%cwb_systemdate%,2000-01-01))))
$puts(recentness,$sub($get(now_age),$get(lp_age)))
$puts(decay,$div($div($mul($if2(%play_count%,%play_counter%),
 $get(baselinefrequency),$get(baselinedecay),$if2(%rating%,
  $get(avgrating)),100),$mul($max($get(age),$get(baselinefrequency)),
   $get(avgrating))),100))
$puts(hotness,$div($mul($max($sub($get(decay),
 $get(recentness)),0),100),$get(decay)))
// END HOTNESS //

I've done some rough testing and it seems like it preserves the same values that the old algorithm produced (give or take a single point, as this code is actually more precise).

Stick this at the top of a formatting string box (or in the globals tab that terrestrial is planning  ), and call with $get(hotness).  As always, it will give you a number from 0-100.

Please give feedback if this doesn't behave as expected.

Version 1.6.c.1, wherein I introduce a new approach to softening the hotness of recently played songs.  I'm excited about this change, so I urge you to try it out and see how different things look when you play tracks -- no more sharp leaps to 100.

/////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// v1.6.c.1 (foo_cwb_hooks version)
// Dec 6, 2006 - by topdownjimmy 
/////////////////////////////////////////
//
// configure baselines: define baseline playfrequency and decay period (in days)
//
   $puts(baselinefrequency,28) // decrease if songs stay hot too long
   $puts(baselinedecay,7) // decrease if too many songs are hot
//
// configure default rating for unrated songs
//
   $puts(avgrating,3)
//   
// DO NOT EDIT BELOW THIS LINE //
$puts(baselinefrequency,$mul($get(baselinefrequency),24))
$puts(baselinedecay,$mul($get(baselinedecay),24))
$puts(lp_age,$add($substr(%last_played%,12,13),
 $mul(24,$cwb_datediff(%last_played%,2000-01-01))))
$puts(fp_age,$add($substr(%first_played%,12,13),
 $mul(24,$cwb_datediff(%first_played%,2000-01-01))))
$puts(age,$sub($get(lp_age),$get(fp_age)))
$puts(now_age,$add($substr(%cwb_systemdatetime%,12,13),
 $mul(24,$cwb_datediff(%cwb_systemdate%,2000-01-01))))
$puts(recentness,$sub($get(now_age),$get(lp_age)))
$puts(decay,$div($div($mul($if2(%play_count%,%play_counter%),
 $get(baselinefrequency),$get(baselinedecay),$if2(%rating%,
 $get(avgrating)),100),$mul($max($get(age),$get(baselinefrequency)),
 $get(avgrating))),100))
$puts(rawhotness,$div($mul($max($sub($get(decay),
 $get(recentness)),0),100),$get(decay)))
$puts(forecast,$div($mul($max($sub($get(decay),
 $add($div($max(0,$sub($get(baselinedecay),$get(recentness))),2),
 $get(recentness))),0),100),$get(decay)))
$puts(hotness,$div($add($get(rawhotness),$get(forecast)),2))
$set_global(hotness,$get(hotness))
// END HOTNESS //

This still depends on foo_cwb_hooks, but has been made compatible with columns_ui.  Use $get(hotness) for SCPL/trackinfo_mod, and $get_global(hotness) for columns_ui.

I did everything like the steps said and I got a new column via Column UI which I called hotness.
In it I put the %_hotness% tag but when I look at my playlist all of them are 0.
I played the same song 3x (via starting it and then clicking next and then starting it again).
I did not play the song through its full length (dont think that matters, or at least hope it doesnt).

Anyways, all the numbers remain 0.
I have installed the cwb hooks and the playcount dll obviously.

Please help this newb.

Clicking "Next" doesn't count the track as being played -- you need to play it for at least one minute (or for half the song length, if you're using the unofficial component).

Topdownjimmy YOU ARE SMART, BEAUTIFUL and WHEREVER YOU WANNA BE!!!!!!!!!!!!!
I was searching for years for a player that could make an algorithm like this!
THANK YOU!!!!

Question:
I put the algorithm in the Variables field but now I have problems with the style. I do not see correctly, in the Playlist view, the background lines that makes a difference between a song and another.
So, the question is: What code should I put now in the Style?
Sorry for my English!!

You have to create a column for it, and use $get_global(hotness) for the display.  That will give you a number.  To get a colored background, just style  the column background with a $blend

If you wanna see the HOTNESS as a line instead of numbers
The line will look like ::::::::::::::

Use this code in the Column UI Display:

$if(%_hotness%,$repeat(':',$div(%_hotness%,5)),)

That should work.  Have you tried just %_hotness%?  Does that work?  Also make sure the four check boxes in the globals tab are checked.

YES, is working.

That should work.  Have you tried just %_hotness%?  Does that work?  Also make sure the four check boxes in the globals tab are checked.

Have anyone tried inserting hotness in foo_playlist_tree's queries? Is it possible at all?

As far as I know, Playlist Tree can't access globals set by Columns UI, but I've spoken with cwbowron about implementing hotness into his cwb_hooks component, in which case you would be able to do that.  I just need to clean up the code a bit.

You're the man!

Version 1.6.c.1, wherein I introduce a new approach to softening the hotness of recently played songs.  I'm excited about this change, so I urge you to try it out and see how different things look when you play tracks -- no more sharp leaps to 100.

It seems you did this job too well - no matter how hot a song really is(tested with new, just-played track and some thousands plays), it just won't reach 100.

Other than that - I've found this to be one of the most helpfull add-ons for Foobar! Great job!

By the way, where is the cooperation with CWBowron headed? Is it still possible?

Quote from: topdownjimmy on 2006-12-06 23:12:04

Version 1.6.c.1, wherein I introduce a new approach to softening the hotness of recently played songs.  I'm excited about this change, so I urge you to try it out and see how different things look when you play tracks -- no more sharp leaps to 100.

It seems you did this job too well - no matter how hot a song really is(tested with new, just-played track and some thousands plays), it just won't reach 100.

Other than that - I've found this to be one of the most helpfull add-ons for Foobar! Great job!

By the way, where is the cooperation with CWBowron headed? Is it still possible?

Thanks for the positive feedback.  Hopefully this will be implemented into some CWB component, we're still working out some kinks.

In the meantime, now that foo_playback_custom (http://www.hydrogenaudio.org/forums/index.php?showtopic=55746) supports PLAY_STAMP, I can finally begin work on a new Hotness algorithm, one that I think will be much more interesting.

In the meantime, now that foo_playback_custom (http://www.hydrogenaudio.org/forums/index.php?showtopic=55746) supports PLAY_STAMP, I can finally begin work on a new Hotness algorithm, one that I think will be much more interesting.

Looking forward to checking out your new algorithm, as i am a happy user of the current version.

I just put a long-overdue update in the first post.  I recommend "upgrading."  Same approach, better code.

As always please offer feedback.  I'm also curious to see how people are implementing it.  What I've done is multiplied values by 10 to get higher granularity for reference, and also converted to a five-point scale for a quick glimpse of hotness.

Thanks for using this.

I use the Foobar2k 0.9.4.4, along with  coumns_ui 0.2.0 beta 1, and playcount 1.9.2.

I copied and pasted this text into the globals section of columns UI. I then made a new column, called it 'Hotness' and in it I put the string: $get_global(hotness)

Then I got "UNKNOWN" for the column.

Where did I go wrong? What do I do to see circles denoting hotness?

I use the Foobar2k 0.9.4.4, along with  coumns_ui 0.2.0 beta 1, and playcount 1.9.2.

I copied and pasted this text into the globals section of columns UI. I then made a new column, called it 'Hotness' and in it I put the string: $get_global(hotness)

Then I got "UNKNOWN" for the column.

Where did I go wrong? What do I do to see circles denoting hotness?

try %_hotness%  thats what I am using to display the hotness number. 

I got the code for making circles showing the hotness at the start of this thread.

EDIT: I did not realise there was a newer version.  I just updated to the latest version and I cant make hotness work either. The hotness in columns just stays blank

EDITAGAIN:  I worked out what was wrong with mine. In the new version theres the line $puts(pc,[%play_count%])
my mp3s are tagged using %play_counter% so i changed this and its all good.

Someone pls tell me whats now the standard playcount tag.. because I thought the standard was play_counter

Someone pls tell me whats now the standard playcount tag.. because I thought the standard was play_counter

I don't think a standard has been established.  In fact, I think the reason two practices are in place is so that they can be distinguished.  The official playback statistics component (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components_0.9/Playback_Statistics_(foo_playcount)) uses %play_count%, so that's what I use, and what I've put as the default in the Hotness code.

@ezuk: are you still having trouble, or did vader897's advice help?

@ezuk: are you still having trouble, or did vader897's advice help?

Well, shortly after I installed the play_count module (the most recent one) foobar2k started crashing horribly. Every couple songs or so, it would crash and burn with multiple pop-up MFC error dialogs and no detailed information. I started troubleshooting and eventually removed the playcount module. That fixed the problem, but now I'm not sure if I can use the hotness thing. Should I re-configure something, change a variable name? I don't now what the "official" module is.

(I sound like an utter n00b, and I do apologize. I've been using fb2k for 2-3 years now, and have never got really deep into it.)

I don't now what the "official" module is.

http://wiki.hydrogenaudio.org/index.php?ti...(foo_playcount) (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components_0.9/Playback_Statistics_(foo_playcount))

topdownjimmy.

I really like your hotness algorithm and I use it regularly, thanks for coming up with it.
I have recently discovered foo_playlist_tree and would really like to create some dynamic playlists based on hotness, particularly for creating a CD mix of random hot songs.  The big problem is that I cannot access %hotness% outside of columns UI.  However this doesn't mean all is lost because we should be able to port your hotness algorithm into foo_playlist_tree.  This should be either possible using the criteria field in foo_playlist_tree  or by porting your algorithm into scheme code.

I did a uni subject last semester on scheme, so i have some experience with that.  I just may need help understanding your algorithm.  Would you consider porting it or working on porting it with me?

It will be a bit redundant to be calculating hotness in two components, but it seems like the only way i can think of to create query based playlists based on hotness.

Thanks
-vader897

topdownjimmy.

I really like your hotness algorithm and I use it regularly, thanks for coming up with it.
I have recently discovered foo_playlist_tree and would really like to create some dynamic playlists based on hotness, particularly for creating a CD mix of random hot songs.  The big problem is that I cannot access %hotness% outside of columns UI.  However this doesn't mean all is lost because we should be able to port your hotness algorithm into foo_playlist_tree.  This should be either possible using the criteria field in foo_playlist_tree  or by porting your algorithm into scheme code.

I did a uni subject last semester on scheme, so i have some experience with that.  I just may need help understanding your algorithm.  Would you consider porting it or working on porting it with me?

It will be a bit redundant to be calculating hotness in two components, but it seems like the only way i can think of to create query based playlists based on hotness.

Thanks
-vader897

Actually, cwbowron is still considering putting hotness into one of his components, something like $tdj_hotness()

Until then, the hotness code can be reduced to a single line, and used as a reverse sort string for Playlist Tree queries (I just did this myself recently).  Just remove all the line breaks, pad the result with $num(), and reverse sort.

I'll probably post this single-line code shortly to save people the trouble.

[/quote]
Actually, cwbowron is still considering putting hotness into one of his components, something like $tdj_hotness()

Until then, the hotness code can be reduced to a single line, and used as a reverse sort string for Playlist Tree queries (I just did this myself recently).  Just remove all the line breaks, pad the result with $num(), and reverse sort.

I'll probably post this single-line code shortly to save people the trouble.
[/quote]

Does this solution give a playlist of only songs with hotness? or will it give a playlist with hot songs up the top and song without hotness all trailing on the end of the playlist?
It would be very much appreciated if you could post the code.. I will have a crack at it but foo_playlist_tree has caused me a bit of grief as I haven't quite gotten the hang of the syntax yet.  I look forward to hotness being integrated into other components. 
Thanks,
-vader897

Would love to know how to get this to work in either a SCPL/panelsui or how to make a autoplaylist or playlist tree that does this all.

EDIT: Is it possible to use hotness in an autoplaylist? That's what I really want to do. And then to add hotness to a SCPL so I can see it next to the song title.

Is there support for this in the new 0.9.5 default UI? I haven't tried, and I haven't read anything about it.

I'll probably post this single-line code shortly to save people the trouble.

Please!

I can't seem to get it to go.

Quote from: topdownjimmy on 2007-10-01 15:22:27

I'll probably post this single-line code shortly to save people the trouble.

Please!

I can't seem to get it to go.

nudge (anyone out there have a single line code that I could "borrow".)

TIA

great work ! that was very useful!

Just added a single-line version to the first post for easy use with Playlist Tree.

Please let me know if you note any bugs or room for improvement in it or in the standard block code.

Thanks.

Does this code work without columns component?

Does this code work without columns component?

It should work in any interface that allows global definitions.  I think I've seen it successfully implemented in Panels UI, but I don't follow that component's development, so I can't be sure.

I hope its okay

works without cwb_hooks
but activate "Make date info available" option in columns ui

///////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// v1.7.c (foo_cwb_hooks version)
// July 8, 2007 - by topdownjimmy@gmail.com
///////////////////////////////////////////
// v2 (foo_version)
// June 19, 2008 - modded by chiwou
///////////////////////////////////////////
//
// configure baselines: define baseline playfrequency and decay period (in days)
//
$puts(baselinefrequency,90) // decrease if songs stay hot too long, or: high to accentuate success, low to accentuate recentness
$puts(baselinedecay,28) // decrease if too many songs are hot, or: high to accentuate success, low to accentuate recentness
//
// configure playback statistics
//
$puts(lp,[%last_played%])
$puts(fp,[%first_played%])
$puts(pc,[%play_count%])
$puts(rating,[%rating%])
$puts(avgrating,3)
//
$puts(lp_mod,$sub($add($add($mul($year(%last_played%),365),$mul($month(%last_played%),30)),$day_of_month(%last_played%)),730000))
$puts(fp_mod,$sub($add($add($mul($year(%first_played%),365),$mul($month(%first_played%),30)),$day_of_month(%first_played%)),730000))
$puts(date_diff,$sub($add($add($mul(%_system_year%,365),$mul(%_system_month%,30)),%_system_day%),730000))
// DO NOT EDIT BELOW THIS LINE //
$puts(baselinefrequency,$mul($get(baselinefrequency),24))
$puts(baselinedecay,$mul($get(baselinedecay),24))
$puts(lp_age,$add($substr($get(lp),12,13),$mul(24,$get(lp_mod))))
$puts(fp_age,$add($substr($get(fp),12,13),$mul(24,$get(fp_mod))))
$puts(age,$sub($get(lp_age),$get(fp_age)))
$puts(now_age,$add(%_system_hour%,$mul(24,$get(date_diff))))
$puts(recentness,$sub($get(now_age),$get(lp_age)))
$puts(decay,$div($div($mul($get(pc),$get(baselinefrequency),$get(baselinedecay),$if2($get(rating),$get(avgrating)),100),$mul($max($get(age),$get(baselinefrequency)),$get(avgrating))),100))
$puts(rawhotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))
$puts(forecast,$div($mul($max($sub($get(decay),$add($div($max(0,$sub($get(baselinedecay),$get(recentness))),2),$get(recentness))),0),100),$get(decay)))
$puts(hotness,$div($add($get(rawhotness),$get(forecast)),2))

$set_global(hotness,$get(hotness))
// END HOTNESS //

I hope its okay

works without cwb_hooks
but activate "Make date info available" option in columns ui

Code: [Select]

///////////////////////////////////////////
// HOTNESS - an algorithm for meta-rating
// v1.7.c (foo_cwb_hooks version)
// July 8, 2007 - by topdownjimmy@gmail.com
///////////////////////////////////////////
// v2 (foo_version)
// June 19, 2008 - modded by chiwou
///////////////////////////////////////////
//
// configure baselines: define baseline playfrequency and decay period (in days)
//
$puts(baselinefrequency,90) // decrease if songs stay hot too long, or: high to accentuate success, low to accentuate recentness
$puts(baselinedecay,28) // decrease if too many songs are hot, or: high to accentuate success, low to accentuate recentness
//
// configure playback statistics
//
$puts(lp,[%last_played%])
$puts(fp,[%first_played%])
$puts(pc,[%play_count%])
$puts(rating,[%rating%])
$puts(avgrating,3)
//
$puts(lp_mod,$sub($add($add($mul($year(%last_played%),365),$mul($month(%last_played%),30)),$day_of_month(%last_played%)),730000))
$puts(fp_mod,$sub($add($add($mul($year(%first_played%),365),$mul($month(%first_played%),30)),$day_of_month(%first_played%)),730000))
$puts(date_diff,$sub($add($add($mul(%_system_year%,365),$mul(%_system_month%,30)),%_system_day%),730000))
// DO NOT EDIT BELOW THIS LINE //
$puts(baselinefrequency,$mul($get(baselinefrequency),24))
$puts(baselinedecay,$mul($get(baselinedecay),24))
$puts(lp_age,$add($substr($get(lp),12,13),$mul(24,$get(lp_mod))))
$puts(fp_age,$add($substr($get(fp),12,13),$mul(24,$get(fp_mod))))
$puts(age,$sub($get(lp_age),$get(fp_age)))
$puts(now_age,$add(%_system_hour%,$mul(24,$get(date_diff))))
$puts(recentness,$sub($get(now_age),$get(lp_age)))
$puts(decay,$div($div($mul($get(pc),$get(baselinefrequency),$get(baselinedecay),$if2($get(rating),$get(avgrating)),100),$mul($max($get(age),$get(baselinefrequency)),$get(avgrating))),100))
$puts(rawhotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))
$puts(forecast,$div($mul($max($sub($get(decay),$add($div($max(0,$sub($get(baselinedecay),$get(recentness))),2),$get(recentness))),0),100),$get(decay)))
$puts(hotness,$div($add($get(rawhotness),$get(forecast)),2))

$set_global(hotness,$get(hotness))
// END HOTNESS //

Unfortunately, this code produces weird figures like "1964039" for a song recently played for the first time or "982067" for one played yesterday. Any ideas?

Did you remember to tick "Make date info available" (and possibly the others) on Columns UI?

hooks doesn't work anymore with the latest foobar.. perhaps a rewrite is in order..

Yep, I did tick that (and even the other three) option in CUI. And I used chiwou's cwb_hooks-independent version, of course.

Ow, and I've forgotten to mention that I tried using it in ELPlaylist, not NG or the old CUI one. That should be the cause, I think. Anyone having any luck porting this code to ELPlaylist?

You can try assigning another global variable with $set_global(). Could be that ELPlaylist is unable to access Coulmns' values correctly?. Try using Columns Playlist and see if the algorithm works as intended there. The algoritm shouldn't return values above 100 because of $max().

Surprisingly, changing the variable name revealed that those set with %set_global are not readable at tall. So $get(hotness) used the value assigned with $puts(hotness, ...). Nonetheless, it is that value which inexplainably exceeds 100.

Anybody know of a plugin or something similar to hotness as this code doesn't seem to be working?

I've translated that code, with one consideration: You'll need foo_customdb v0.8 or earlier, because newer versions doesn't allow using %now% which is safe in this case I think

[font= "Lucida Console"]$puts(baselinefrequency,90)

$puts(baselinedecay,28)

$puts(lp,[%last_played%])
$puts(fp,[%first_played%])
$puts(pc,[%play_count%])
$puts(rating,[%rating%])
$puts(avgrating,3)

$puts(baselinefrequency,$mul($get(baselinefrequency),24))
$puts(baselinedecay,$mul($get(baselinedecay),24))
$puts(lp_age,$add($substr($get(lp),12,13),$mul(24,$add($mul($sub($year($get(lp)),2000),365),$mul($month($get(lp)),30),$day_of_month($get(lp))))))
$puts(fp_age,$add($substr($get(fp),12,13),$mul(24,$add($mul($sub($year($get(fp)),2000),365),$mul($month($get(fp)),30),$day_of_month($get(fp))))))
$puts(age,$sub($get(lp_age),$get(fp_age)))
$puts(now_age,$add($substr(%now%,12,13),$mul(24,$add($mul($sub($year(%now%),2000),365),$mul($month(%now%),30),$day_of_month(%now%)))))
$puts(recentness,$sub($get(now_age),$get(lp_age)))
$puts(decay,$div($div($mul($get(pc),$get(baselinefrequency),$get(baselinedecay),$if2($get(rating),$get(avgrating)),100),$mul($max($get(age),$get(baselinefrequency)),$get(avgrating))),100))
$puts(rawhotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))
$puts(forecast,$div($mul($max($sub($get(decay),$add($div($max(0,$sub($get(baselinedecay),$get(recentness))),2),$get(recentness))),0),100),$get(decay)))
$puts(hotness,$div($add($get(rawhotness),$get(forecast)),2))
$get(hotness)[/font][/size]

Hi, i'm used this in my foobar and get such large values. For example "1916286". Is it normal?

Moderation: Removed useless full quote of the preceding post.

No, it's not normal, at least by my foobar.
The values I get are from 0 to 100, and if play_count is 0 the value returned is always 0
I'll maybe see the code later but it should work, I don't know why you have problems

Do you have foo_customdb v0.8 or earlier?

I have v0.0.8c ? Need 0.0.8 ?

No you must use earlier version.
0.8a, 0.8b, 0.8c... are of no use

Googling it, it will show, but if you really can not find try extracting the component from r a p i d s h a r e.com/files/219136553/Foobar2000_0.9.6.4_RialtoPack.exe (erase the spaces from r a p i d s h a r e)

[edit] I hope that I will not get banned showing this

Works fine. I get 0.0.8 on the component offcial page. Tnanks for you help!

Thanks 2E7AH, your script is working fine.

Any chance of an official playstats version?

Don't you think this is from offical playback statistics:

[font= "Lucida Console"]$puts(lp,[%last_played%])
$puts(fp,[%first_played%])
$puts(pc,[%play_count%])
$puts(rating,[%rating%])
...[/font]

I've noticed that foo_customdb v0.8 is trashing console with "out of memory" string on start-up, and then I just saw this post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=31287&view=findpost&p=571941) and it works as it should

So, if you are CUI user and interested in using this "hotness" algorithm, better use that code instead of what I posted above

• tics on "make date info available" in Globals tab in CUI playlist view preferences, as the poster said
• paste the code at the end in "Globals > Variables tab"
• use it with $get_global(hotness)

How can i make autoplaylist with all files with "hotness">0? and sort by hotness too

You can't, but of course you can sort by that field in playlist view

Another way by PM

Hi, just tried to get the hotness code work in ELP playlist. So far I used the code from chiwou
(that works without cwb_hooks) in the playlist view ( activated Date option), and simply tried in elp settings to use the $get_global(hotness) command to retrieve info - but I get "unknown function" as a result. Someone got this to work in ELPlist? 

@ El noire
These were the steps i followed
chiwou's code (without cwb) @ globals - variables
setting ''Use Global Variables for Display'' on @ the globals tab.
Make new column with ''$get_global(hotness)'' (without quotes)

And then it should work, works for me anyway.

foo_customdb can be used to implement a global timestamp set by the last playing track. This is how you should set it up:

1. Define a new field (call it "Now" or something sane) with a fieldname "NOW_CD". The custom key should match any track in the media library - To do this, just define a static number (not a variable, as you normally would) - I just used 0.
2. Define an Action pointing to the NOW_CD field and set it to update on "Playback" with the value %now%. You could set the slider to update on 0% Playback percentage, to make it update instantly.

Voila, you have a %now_cd% that contains the timestamp for the last played file. Better than nothing

2E7AH: Will you test if you can make this work with the hotness script?

Yeah, I will
First I need to finish tagging my library, then some sleep, and after that I'll post the script which will work of course, and percentage should be set to more then 1min if using official playback statistics, so that hotness will update correctly

Hi, just wondering if anyone has been able to implement this into elplaylist, i see the question was asked further up and i have the exact same results as El Noire.
Ive followed what hxkclan but i think thats to get it to work using the playlist with CUI. (perhaps not)

Am i right in thinking the problem lies in elplaylist not being able to retrieve globals set by hotness (CUI).
Ive had a goosey around the forums but not been able to find anything relating to this, can anyone shine any light on this? and if not possible a work around (such as implementing this code into elplaylist?)

Thanks, Anomaly.

Maybe I missed it, but how do I actually implement this into foo_customdb ?  Where do I put the code posted by 2E7AH above (with possible mods being required)?

Thanks,

Mike

look here: http://www.hydrogenaudio.org/forums/index....st&p=661680 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=75306&view=findpost&p=661680)
or here: http://www.hydrogenaudio.org/forums/index....st&p=665208 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=73903&view=findpost&p=665208)

Any other components or settings required?  I just get a question mark "?" when I put display the %HOT% tag in a column.

Mike

restart foobar and add hot in square brackets: [%hot%]

Hmm, I'm just getting "0" against certain tracks.  Either nothing is very hot in my collection, or this isn't working.  Ah well.

Hi all, ive managed to find a way to implement this into elplaylist using wsh panel.
It uses the same method falstaff/br3tt uses in most of his configs, in fact, he uses an auto rating system himself, dont think its quite like this one however.

The problem lies in not being able to get the current date. To get around this i have wsh panel store the date in a files name, and then read the name using the $findfile function integrated in elplaylist (and panel stack)

The code for WSH panel can be added to an existing panel or make another just for this.
Btw, if your not to sure on titleformatting or JScript this might be a little hard to follow so ill try and explain the best i can

function set_current_date(){
	var d;
	var s,s1,s2,s3;
	var opt_read;
	d = new Date();
	s1 = d.getFullYear();
	s2 = (d.getMonth() + 1);
	if(s2.length==1) s2 += "0"+s2;
	s3 = d.getDate();
	if(s3.length==1) s3 += "0"+s3;
	s = s1*10000+s2*100+s3;
	opt_read = read_option("current_date", s);
	update_option("current_date", s);
}

function update_option(optname, optvalue) {

	var fso, f1, ts, s;
	var ForReading = 1;
	var ForWriting = 2;
	fso = new ActiveXObject("Scripting.FileSystemObject");

	// Read the contents of the txt file
	ts = fso.OpenTextFile(settings_dir + optname + ".txt", ForReading);
	s = ts.ReadLine();
	ts.Close();
	// renaming the empty file used after in the PSS with the new value
	f1 = fso.MoveFile(settings_dir + optname + "_" + s, settings_dir + optname + "_" + optvalue);
	// updating the txt file with the new value
	ts = fso.OpenTextFile(settings_dir + optname + ".txt", ForWriting);
	ts.WriteLine(optvalue);
	ts.Close();
}

This var also needs to be set at the top above all other code and outside of any brackets.

var settings_dir = fb.ProfilePath+"settings\\";


You then need to navigate to your foobar2000 folder and create a folder called settings. Mine is located at:
C:\Program Files (x86)\foobar2000
So i created a settings folder so now its:
C:\Program Files (x86)\foobar2000\settings

This is where WSH panel will store the date and where elplaylist will retrieve it.

Then bring up elplaylist settings, click on tracklisting and add

// HOTNESS //
$puts(date, $right($findfile('C:\Program Files (x86)\foobar2000\settings\current_date_*'),8))
$puts(year, $left($get(date), 5))
$puts(month, $right($left($get(date),7),2))
$puts(day, $right($get(date),2))
                            
$puts(baselinefrequency,90) // decrease if songs stay hot too long, or: high to accentuate success, low to accentuate recentness
$puts(baselinedecay,28) // decrease if too many songs are hot, or: high to accentuate success, low to accentuate recentness
// configure playback statistics
$puts(lp,[%last_played%])
$puts(fp,[%first_played%])
$puts(pc,[%play_count%])
$puts(rating,[%rating%])
$puts(avgrating,3)

$puts(lp_mod,$sub($add($add($mul($year(%last_played%),365),$mul($month(%last_played%),30)),$day_of_month(%last_played%)),730000))
$puts(fp_mod,$sub($add($add($mul($year(%first_played%),365),$mul($month(%first_played%),30)),$day_of_month(%first_played%)),730000))
$puts(date_diff,$sub($add($add($mul($get(year),365),$mul($get(month),30)),$get(day)),730000))

$puts(baselinefrequency,$mul($get(baselinefrequency),24))
$puts(baselinedecay,$mul($get(baselinedecay),24))
$puts(lp_age,$add($substr($get(lp),12,13),$mul(24,$get(lp_mod))))
$puts(fp_age,$add($substr($get(fp),12,13),$mul(24,$get(fp_mod))))
$puts(age,$sub($get(lp_age),$get(fp_age)))
$puts(now_age,$add(1,$mul(24,$get(date_diff))))
$puts(recentness,$sub($get(now_age),$get(lp_age)))
$puts(decay,$div($div($mul($get(pc),$get(baselinefrequency),$get(baselinedecay),$if2($get(rating),$get(avgrating)),100),$mul($max($get(age),$get(baselinefrequency)),$get(avgrating))),100))
$puts(rawhotness,$div($mul($max($sub($get(decay),$get(recentness)),0),100),$get(decay)))
$puts(forecast,$div($mul($max($sub($get(decay),$add($div($max(0,$sub($get(baselinedecay),$get(recentness))),2),$get(recentness))),0),100),$get(decay)))
$puts(hotness,$div($add($get(rawhotness),$get(forecast)),2))

$drawtextex($get(hotness), 925, 3, 60, %el_height%, 180-180-180, hcenter )
// END HOTNESS //

In this code you need to change the 2nd line "$puts(date, $right($findfile('C:\Program Files (x86)\foobar2000\settings\current_date_*'),8))" to your directory, for example if your running 32-bit windows this will more likely be: "C:\Program Files\foobar2000\settings\current_date_*" Note the missing "(x86)".
Obv also change the $drawtextex as needed.

And if all works, you should get something like this:
(http://img407.imageshack.us/img407/5589/foobaru.png) (http://img407.imageshack.us/i/foobaru.png/)

How do you get final hotness values to be from 0 to 100? It's bizzare longish figures in my case...

How do you get final hotness values to be from 0 to 100? It's bizzare longish figures in my case...

I was having that problem when it wasnt retrieving the date. Maybe somethings going wrong there? If all works out you dont have to add anything to make it between 0-100, the algorithm does that for you.

Quote from: elenhil on 2010-01-31 10:39:36

How do you get final hotness values to be from 0 to 100? It's bizzare longish figures in my case...

I was having that problem when it wasnt retrieving the date. Maybe somethings going wrong there?

Quite possibly. No idea what precisely - I seem to have followed your instructions, at least so far as inserting the function and the variable bits into WSH

If you want man, send me a pm with your code from the wsh panel, and the panel stack splitter and ill have a look for ya. Also make sure that you have got a "settings" folder created in your foobar folder. x