Really? That's interesting. My last-played stuff doesn't seem to work at all, nor does %cwb_activelist_count%.
QUOTE(DocBeard @ May 11 2008, 11:01) 
Really? That's interesting. My last-played stuff doesn't seem to work at all, nor does %cwb_activelist_count%.
CODE
$puts(dayssince,$cwb_datediff(%cwb_systemdate%,%last_played%))$puts(dayssince,$sub($get(dayssince),$if($and($greater(7,$substr(%cwb_systemdatetime%,12,13)),$greater($substr(%last_played%,12,13),6)),1,0)))$if($and($greater($substr(%cwb_systemdatetime%,12,13),6),$greater(7,$substr(%last_played%,12,13))),$puts(dayssince,$add($get(dayssince),1)),)$puts(calcdayofweek,$add(1,$mod($add($substr(%last_played%,3,4),$div($substr(%last_played%,3,4),4),$select($substr(%last_played%,6,7),6,2,2,5,0,3,5,1,4,6,2,4),$substr(%last_played%,9,10)),7)))$puts(calcdayofweek,$sub($get(calcdayofweek),$ifgreater(7,$substr(%last_played%,12,13),1,0)))$if($strcmp($get(calcdayofweek),0),$puts(calcdayofweek,7),)$puts(dayperiod,$select($add(1,$substr(%last_played% ,12,13)),Night,Night,Night,Night,Night,Night,Night,Morning,Morning,Morning,Morning,Morning,Afternoon
,Afternoon,Afternoon,Afternoon,Afternoon,Evening,Evening,Evening,Evening,Night,Night,Night))$if(%last_played%,$puts(rel_timestamp,$ifgreater($get(dayssince),0,$ifgreater($get(dayssince),1,$ifgreater($get(dayssince),6,$if($and($greater($get(dayssince),21),$not($strcmp($left(%cwb_systemdate%,7),$left(%last_played%,7)))),$if($not($strcmp($left(%cwb_systemdate%,4),$substr(%last_played%,1,4))),$select($substr(%last_played%,6,7),January,February,March,April,May,June,July,August,September,October,November,December)' '$ifgreater($get(dayssince),334,$substr(%last_played%,1,4),),$ifgreater(2,$sub($substr(%cwb_systemdate%,6,7),$substr(%last_played%,6,7)),'Last Month',$select($substr(%last_played%,6,7),January,February,March,April,May,June,July,August,September,October,November,December))),$ifgreater($div($add($get(dayssince),4),7),1,$div($add($get(dayssince),4),7)' Weeks Ago',Last Week)),$select($get(calcdayofweek),Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday)' '$get(dayperiod)),$if($strcmp($get(dayperiod),Night),Last,Yesterday)' '$get(dayperiod)),$if($strcmp($get(dayperiod),Night),Tonight,This $get(dayperiod)))),$puts(rel_timestamp,Never))$get(rel_timestamp)
,Afternoon,Afternoon,Afternoon,Afternoon,Evening,Evening,Evening,Evening,Night,Night,Night))$if(%last_played%,$puts(rel_timestamp,$ifgreater($get(dayssince),0,$ifgreater($get(dayssince),1,$ifgreater($get(dayssince),6,$if($and($greater($get(dayssince),21),$not($strcmp($left(%cwb_systemdate%,7),$left(%last_played%,7)))),$if($not($strcmp($left(%cwb_systemdate%,4),$substr(%last_played%,1,4))),$select($substr(%last_played%,6,7),January,February,March,April,May,June,July,August,September,October,November,December)' '$ifgreater($get(dayssince),334,$substr(%last_played%,1,4),),$ifgreater(2,$sub($substr(%cwb_systemdate%,6,7),$substr(%last_played%,6,7)),'Last Month',$select($substr(%last_played%,6,7),January,February,March,April,May,June,July,August,September,October,November,December))),$ifgreater($div($add($get(dayssince),4),7),1,$div($add($get(dayssince),4),7)' Weeks Ago',Last Week)),$select($get(calcdayofweek),Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday)' '$get(dayperiod)),$if($strcmp($get(dayperiod),Night),Last,Yesterday)' '$get(dayperiod)),$if($strcmp($get(dayperiod),Night),Tonight,This $get(dayperiod)))),$puts(rel_timestamp,Never))$get(rel_timestamp)
I'm using this I got off some forum (I forgot where, but definitely not HA).
QUOTE(n0obie4life @ May 10 2008, 21:07)
I'm using this I got off some forum (I forgot where, but definitely not HA).
My formula:
CODE
$puts(diff,$cwb_datediff(%last_played%,%cwb_systemdate%))
$puts(dayinfo,$if([%last_played%],Played $ifgreater(1,$get(diff),Today,$ifgreater(2,$get(diff),Yesterday,$ifgreater(7,$get(diff),Within The Last Week,$get(diff) Days Ago))),))
$get(dayinfo)
$puts(dayinfo,$if([%last_played%],Played $ifgreater(1,$get(diff),Today,$ifgreater(2,$get(diff),Yesterday,$ifgreater(7,$get(diff),Within The Last Week,$get(diff) Days Ago))),))
$get(dayinfo)
It always returns that the song was played 'Today'. In 9.5.2. it worked properly. Further testing shows that neither %cwb_systemdate% nor $cwb_datediff() seem to work properly. (I tested both in the Track Info display and in the NG Playlist of columns UI, just in case it was Panels that was the culprit or something.
Edit: And just so's my posts don't come across as all negative here, the new time-related query/titleformatting stuff is *indeed* cool. Enough to make me *almost* regret my decision to probably stick with 9.5.2 for the foreseeable future. (Almost.)
@DocBeard, Does the one I posted work? Because it seems to for me (for some weird reason).
QUOTE(n0obie4life @ May 10 2008, 21:46)
@DocBeard, Does the one I posted work? Because it seems to for me (for some weird reason).
My cursory examination of this suggests that it's not really working (on my system, at least), but that the results it gives are deceptive enough to suggest that it is, if that makes any sense. It's basically insisting that every song was played sometime today (or not played at all), but the results are varied enough so that some of them return 'This Morning' and some return 'This Afternoon' or Evening.
My own formula doesn't differentiate between times of day, and so it just returns 'Played Today' for everything.
QUOTE(DocBeard @ May 11 2008, 11:55)
QUOTE(n0obie4life @ May 10 2008, 21:46)
@DocBeard, Does the one I posted work? Because it seems to for me (for some weird reason).
My cursory examination of this suggests that it's not really working (on my system, at least), but that the results it gives are deceptive enough to suggest that it is, if that makes any sense. It's basically insisting that every song was played sometime today (or not played at all), but the results are varied enough so that some of them return 'This Morning' and some return 'This Afternoon' or Evening.
My own formula doesn't differentiate between times of day, and so it just returns 'Played Today' for everything.
Ah yes, I got it. I didn't notice it. Everything is "today" for me too
. My bad 
PanelsUI is no more supported? 
QUOTE(Sphix @ May 10 2008, 23:17)
PanelsUI is no more supported?
The metadb_display_hook APIs are no longer supported. This change was announced weeks ago and has been discussed at length elsewhere.
From what I've seen (with the usual disclaimer that I have not exactly tested things extensively before rolling back to 9.5.2), PanelsUI does still seem to work to a degree (though the new notification at startup will list it among components that won't function).
Doubtless there are functions that use the metab_display_hook API within Panels that don't work any more, though I couldn't tell you off the top of my head what those are; is there anyone who can?
Out of curiousity, does the startup notification work off a static list of components, or does it check dynamically for components that try to call this old API?
Doubtless there are functions that use the metab_display_hook API within Panels that don't work any more, though I couldn't tell you off the top of my head what those are; is there anyone who can?
Out of curiousity, does the startup notification work off a static list of components, or does it check dynamically for components that try to call this old API?
QUOTE(DocBeard @ May 11 2008, 10:00)
Doubtless there are functions that use the metab_display_hook API within Panels that don't work any more, though I couldn't tell you off the top of my head what those are; is there anyone who can?
$setpvar and $getpvar as far as I know.QUOTE(DocBeard @ May 11 2008, 10:00)
Out of curiousity, does the startup notification work off a static list of components, or does it check dynamically for components that try to call this old API?
It checks for components that implement the old API.
it's a shame this metadb_display_hook "fix" was introduced. i guess i'll be sticking with 9.5.2 until something better comes along, hopefully in a *nix flavor.
Is it really needed to have that warning massage popup every time when I start foobar?
Yeah, I agree. I only use and have a need for one component that has trouble currently foo_uie_lyrics_art. The only thing that doesn't work is a function that it provided that I have never used and likely won't.
Ability to disable and enable this kind of warning is welcome.
Ability to disable and enable this kind of warning is welcome.
I agree, it'd be nice if this warning could be disabled; maybe displayed only the first time an incompatible component were detected. (I am not exactly holding my breath, though.)
Eh, the situation isn't exactly the disaster I was fearing. It's still an intentional degradation of function, though as far as I know, the only thing my own config is doing right now that wouldn't be possible any more is displaying last-played information relative to the system date. (Yes, I have read Peter's posts about why having the system date available through titleformatting is thought to be problematic. I personally have not run into any problems of this nature, which is, of course, not the same as saying that they don't exist.)
I think I'm still going to stick with 9.5.2 for the time being, though; it does everything I want or need, and the new functions introduced in 9.5.3, nice as some of them are, aren't really anything I need enough to put up with the hassle of adapting everything else and/or doing without.
And I do find the philosophical underpinnings of this change as they have been presented to be unfortunate, but I guess I'm not the one making a really good music player available for free, so whatever.
Eh, the situation isn't exactly the disaster I was fearing. It's still an intentional degradation of function, though as far as I know, the only thing my own config is doing right now that wouldn't be possible any more is displaying last-played information relative to the system date. (Yes, I have read Peter's posts about why having the system date available through titleformatting is thought to be problematic. I personally have not run into any problems of this nature, which is, of course, not the same as saying that they don't exist.)
I think I'm still going to stick with 9.5.2 for the time being, though; it does everything I want or need, and the new functions introduced in 9.5.3, nice as some of them are, aren't really anything I need enough to put up with the hassle of adapting everything else and/or doing without.
And I do find the philosophical underpinnings of this change as they have been presented to be unfortunate, but I guess I'm not the one making a really good music player available for free, so whatever.
Well, I actually agree with this decision to remove this API if it is used in cases that were not original intended and would lead to troubles. No progress is without sacrifice.
But I don't use many components anyway so I'm not really affected much by this.
But I don't use many components anyway so I'm not really affected much by this.
I go back to version 0.9.5.2 beta1...
The following components doesn't work:
- foo_custominfo.dll
- foo_cwb_hooks.dll
- foo_dsp_crossfader.dll
- foo_playlist_tree.dll
- foo_ui_panels.dll
- foo_uie_bookmarks.dll
- foo_uie_powerpanels.dll
!!!
All components, specially panelsUI and Powepanels, are essentiell for my own-skinned foobar and it is not acceptable, that they don't work anymore...
The following components doesn't work:
- foo_custominfo.dll
- foo_cwb_hooks.dll
- foo_dsp_crossfader.dll
- foo_playlist_tree.dll
- foo_ui_panels.dll
- foo_uie_bookmarks.dll
- foo_uie_powerpanels.dll
!!!
All components, specially panelsUI and Powepanels, are essentiell for my own-skinned foobar and it is not acceptable, that they don't work anymore...
Is there a way to duplicate $cwb_fileexists with the new foobar beta?
i.e.
i.e.
CODE
//$draw_image(12,12,200,200,$if($cwb_fileexists($replace(%path%,%filename_ext%,)cover.jpg),$replace(%path%,%filename_ext%,)cover.jpg,$if($cwb_fileexists($replace(%path%,%filename_ext%,)folder.jpg),$replace(%path%,%filename_ext%,)folder.jpg,F:\foobar2000beta\rhythmboxmissingartworkit3.png))))
@nightfishing:
No.
No.
Implementing a "does a file exist" titleformatting function would violate the constraint that a titleformatting function should not rely on external factors, such as time, PRNGs, file system contents and phase of the moon.
I would have thought that being an optional component it wouldn't matter if people wanted to use cwb_hooks or not. Or am I missing something here?
EDIT
Just read the thread. I see.
EDIT
Just read the thread. I see.
QUOTE(foosion @ May 11 2008, 03:28)
$setpvar and $getpvar as far as I know.
Is there an acceptable alternative to this among the 3rd party components?
No, this is the same problem as with the system time and global options in title formatting. There is no way to implement variables that are accessible from different scripts/components using only the programming interfaces in the foobar2000 SDK.
QUOTE(Canar @ May 11 2008, 01:11)
QUOTE(Sphix @ May 10 2008, 23:17)
PanelsUI is no more supported?
The metadb_display_hook APIs are no longer supported. This change was announced weeks ago and has been discussed at length elsewhere.
So there are will be no more 'skins' for foobar2k or there will be a substitute for panelsUI?
My only concern is: how can I create a timestamp für my %date added% tag then without cwb_hooks? Any suggestions? 
QUOTE(McMusic @ May 20 2008, 16:56)
My only concern is: how can I create a timestamp für my %date added% tag then without cwb_hooks? Any suggestions?
the official playback statistics component can add that information.
QUOTE(kanak @ May 20 2008, 21:58)
the official playback statistics component can add that information.
Ah, good to know. Thanks!
QUOTE(foosion @ May 18 2008, 03:15)
No, this is the same problem as with the system time and global options in title formatting. There is no way to implement variables that are accessible from different scripts/components using only the programming interfaces in the foobar2000 SDK.
This seems to imply that is not possible for anyone to ever develop a way of communicating between components in Foobar 2000 - is that correct?
No, if you hear your music playing, it means that components are communicating between each other quite nicely. Within the ways allowed by foobar2000 design, that is.
That quote rather deals with other means of "communication", for which the API was not designed. There are plenty of other standard, sane, reliable and efficient ways of both intra- and inter-process communication in C++/Windows, so there is no need to abuse a simple text formatting language for that.
That quote rather deals with other means of "communication", for which the API was not designed. There are plenty of other standard, sane, reliable and efficient ways of both intra- and inter-process communication in C++/Windows, so there is no need to abuse a simple text formatting language for that.
QUOTE
So there are will be no more 'skins' for foobar2k or there will be a substitute for panelsUI?
Aside from the $setpvar() and $getpvar() functions, Panels UI still worked as of 9.5.3 beta 1. (I haven't tested anything with beta 2 yet, and I dunno that I'll bother.) Panels UI is definitely unsupported, but that's not a new state of affairs; the official devs have never supported 3rd party components, and the developer of Panels UI has been absent from these forums for something like a year now, and development has effectively ceased.
As for whether there'll ever be somethng that replaces or supercedes Panels UI, I suppose that all depends on whether someone else is willing or able to develop one.
I wonder how such a component would be developed that didn't use title formatting for storing variables, etc.
Walterrrr, there are plenty of mature scripting languages around.
I will readily admit that I am no expert on writing Panels UI configurations, but from what I have seen $getpvar and $setpvar are used for the following tasks:
Note that all of these things can be solved on a higher level than exchanging strings between components. They are even easier to solve without title formatting, because title formatting by design has several restrictions (more on that can be found elsewhere).
- local persistent state
- shared (persistent) state
- shared configuration
Note that all of these things can be solved on a higher level than exchanging strings between components. They are even easier to solve without title formatting, because title formatting by design has several restrictions (more on that can be found elsewhere).
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.