Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_cwb_hooks (Read 297432 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foo_cwb_hooks

Reply #75
I tried following things without succes:
In PT i created a query with source "@playlist<%cwb_playinglist%>" or "@playlist<%cwb_activelist%>".

Is it an issue with PT or with this component?


Its an issue that Playlist Tree doesnt support tagz in the query source designator.
There used to be a link to my website here.

foo_cwb_hooks

Reply #76
Request.  cwb_followcursor.

foo_cwb_hooks

Reply #77
Thanks for the plugin.
I have 3 requests:
1 cwb_stop_after_current
2 cwb_is_playing
3 cwb_is_paused

The last 2 should work like in foobar 8. I mean with all the instances of the file even if the playlist is broken (for foo browser)

Thanks again!
Excuse my English

foo_cwb_hooks

Reply #78
Would it be possible to add a function that can indicate which column is currently selected for sorting the columnsUI playlist? That way, we could have conditional formatting based on whether the playlist is being sorted by album, artist, etc.
Here's what it might look like:
$ifequal(cwb_sort_column,2,$rgb(239,235,231),$rgb(133,87,204))

foo_cwb_hooks

Reply #79
Would it be possible to add a function that can indicate which column is currently selected for sorting the columnsUI playlist? That way, we could have conditional formatting based on whether the playlist is being sorted by album, artist, etc.


not possible.
There used to be a link to my website here.

foo_cwb_hooks

Reply #80
Would it be possible if it were implemented in columnsUI directly?
This just gave me a really good idea, though. How about implimenting some sort of user definable global variables whose values can be changed using events (i.e. toolbar buttons, menu, keyboard shortcuts, etc.). These variables could then be retrieved in formatting strings to change formatting based on the value of that variable. This would allow us, for example, to hit a toolbar button which could instantly change the formatting of the playlist.
Here's what it might look like:
$ifequal(cwb_globalvar_A,1,$rgb(239,235,231),$rgb(133,87,204))

foo_cwb_hooks

Reply #81
Are all the variables added by cwb_hooks working in the various trackinfo panels and outside Foobar? (I'm using a Samurize screensaver that is a sort of a trackinfo panel too, to show the now playing info).

Thanks.

foo_cwb_hooks

Reply #82
Are all the variables added by cwb_hooks working in the various trackinfo panels and outside Foobar? (I'm using a Samurize screensaver that is a sort of a trackinfo panel too, to show the now playing info).


It should work any place where title formatting can happen.
There used to be a link to my website here.

foo_cwb_hooks

Reply #83
Release 1.0.8
    *  %cwb_stopaftercurrent%
    * %cwb_followcursor%
    * if follow cursor mode is enabled, cwb_next_artist and cwb_next_title will now be correct
There used to be a link to my website here.

foo_cwb_hooks

Reply #84
Mods: With all the amazing functions this plugin provided, shouldn't the thread's title be changed?

foo_cwb_hooks

Reply #85
I really like this plugin, especially the playback queue fonctions
Thanks a lot

foo_cwb_hooks

Reply #86
Thanks for creating this wonderful component and adding cwb_followcursor!  Several other suggestions:

First, I think cwb_queuecount should be added so that it is consistent with the other fields for providing both the length and item count for the queue as is the case with active and playing playlists.

Second,  which is already listed on requested features,, fields for the length of the active and playing playlist should be added so that one can display the item count and length of the active and playing playlist.

Third, the only real problem with the component is its inability to refresh in displays for cwb_playlinglist and cwb_activelist.  Once this bug is ironed out, one can create a complete display showing the active playlist count, length, and the same for the queue and playing playlist.


Again, thanks for creating this great component, and I look forward to the above issues being resolved.

Best regards.

foo_cwb_hooks

Reply #87
First, I think cwb_queuecount should be added so that it is consistent with the other fields for providing both the length and item count for the queue as is the case with active and playing playlists.


%cwb_queuelength% is already available.  The naming is a little different (length vs count) but its the same functionality.  Perhaps I will rename it at some point to avoid confusion with a length in seconds vs an item count.

Quote
Third, the only real problem with the component is its inability to refresh in displays for cwb_playlinglist and cwb_activelist.  Once this bug is ironed out, one can create a complete display showing the active playlist count, length, and the same for the queue and playing playlist.


That's not really a bug, its more of a limitation of the title formatting in foobar2000.  It is possible to tell components when the info relating to a file has changed, but since the playinglist and activelist do not correspond to a file, there's no good way to tell other components that that information has changed.  My best guess at a good way to do it, might be to post a message that the information for the currently playing song has changed because I would think that most of the displays that would include %cwb_playinglist% and %cwb_activelist% would relate to information about the current song (trackinfo panel, statsusbar, etc)
There used to be a link to my website here.

foo_cwb_hooks

Reply #88
Have you ever tried doing a hardcore full-db refresh?
If this does not crash the player and locks it for anything below one second I think that's an option.
But that would need you to add a config panel. But I don't believe you can avoid that a lot longer after all ;)
I think a selection for "information not belonging to any track / general information" to refresh either nothing, just the playing song or the whole DB would be a good solution.

foo_cwb_hooks

Reply #89
I think a selection for "information not belonging to any track / general information" to refresh either nothing, just the playing song or the whole DB would be a good solution.
That's not a good solution, that's an inane workaround. Suppose the user has 100000 tracks in the library, and the currently displayed track is neither playing nor in the library.

The available events used in conjunction with titleformatting only cover track and playback related changes; they are not suitable to handle unrelated state changes (including the time of day and various configuration options). If you still want to be able to access these in formatting scripts, it might be time to collaborate with the relevant parties to set up a framework for just that - instead of doing something that might only get the component on the list of known potential troublemakers.

foo_cwb_hooks

Reply #90
As far as i've seen it, updating the whole Db will only notify the components displaying those tracks to update. Someone with 100000 (who will get quite some performance Problems with foobar and most components ;) won't have all those 100000 tracks "in use" - so sending an update for the whole db will actually refresh about 1000 tracks - in any case not more than is done at startup after all.
I said it has to be tested and if it's gives acceptable results should be added as an _option_.
(If this "brute force" method works, one could als refresh the playing and the active playlist to the refresh - this should for sure refresh every track the user is able to see)

Quote
If you still want to be able to access these in formatting scripts, it might be time to collaborate with the relevant parties to set up a framework for just that.

Well, I haven't jet seen Peter beeing very interested in user requests (if this is good or not is another topic).

Every component affects the performance and stability of foobar - it's allways up to the user to decide if he wants to trade preformance/stability for this specific feature.
It don't think this is sollution is very hackish after all (but I won't argue about that - I'm sure you're more experienced with the foobar SDk ;)

foo_cwb_hooks

Reply #91
It don't think this is sollution is very hackish after all
This "not very hackish after all" solution doesn't even guarantee that relevant track gets refreshed.
Microsoft Windows: We can't script here, this is bat country.

foo_cwb_hooks

Reply #92
I don't want to get into pointless arguments here, but the metadb_display_hook API was meant to show info that directly describes the item being queried (and not global data), and affected items should be refreshed properly.
I see that for some users and even developers, reliability of their software is secondary priority. I won't bother trying to convince you to stop this.
Most of these features are not provided by default for efficiency reasons (would require massive refresh dispatch on any configuration / playback state / etc change), and no hack that you can come up with will both work reliably and avoid efficiency issues (*). If anything, these variables should be directly provided by the UI part that people try to use them with (playlist view, now playing track display, whatever) that can refresh itself when relevant variable changes.

[edit]
(*) In fact, there is no way to get all tracks that are possibly displayed somewhere at all, so you run into reliability issues no matter what you do. No, refreshing entire Media Library does not guarantee refreshing every possible displayed track, because user may be eg. working with newly acquired content that hasn't been moved to the Media Library folders yet.
Microsoft Windows: We can't script here, this is bat country.

foo_cwb_hooks

Reply #93
As far as i've seen it, updating the whole Db will only notify the components displaying those tracks to update. Someone with 100000 (who will get quite some performance Problems with foobar and most components  won't have all those 100000 tracks "in use" - so sending an update for the whole db will actually refresh about 1000 tracks - in any case not more than is done at startup after all.
I said it has to be tested and if it's gives acceptable results should be added as an _option_.
(If this "brute force" method works, one could als refresh the playing and the active playlist to the refresh - this should for sure refresh every track the user is able to see)
Amount of false verifiable info in just the above quote offends me.
People have successfully used foobar2000 with close to 100000 tracks. The performance is not what I'd call "perfectly smooth", but it's by several magnitudes better than most of other software. I'll leave flaming you for that statement to TrNSZ when he shows up. I have to credit him for making me invent the metadb_handle system in first place, when the old approach underperformed with his old library of about 20000 tracks.
Updating whole media library with each playback state, playback queue state, system time etc change will:
- Cause full rebuild of all autoplaylists etc - which means running some query on all items in the library, possibly repeatedly if multiple autoplaylists exist.
- Totally kill performance of any other realtime ML viewers (autoplaylist is the only one I'm currently aware of, but we plan to add autorefresh to Album List sooner or later).
Microsoft Windows: We can't script here, this is bat country.

 

foo_cwb_hooks

Reply #94
Well, every user has his own POV regarding reliability (at least 20% of the private computer systems i'm seeing start up with some kind of fatal error/virus message which is then clicked away and explained to be "normal").
I for sure know that this will allways be connected with effiency and reliability  issues, and I for sure wouldn't use such a feature myself.
But I haven't yet seen a component that shows infos about songs neither in the db nor in the currently playing nor in the active playlist.

So you'd say that we should provide a interface for other components to use these new title formating vars and hope for them to implement it?

Quote
People have successfully used foobar2000 with close to 100000 tracks. The performance is not what I'd call "perfectly smooth", but it's by several magnitudes better than most of other software.

I never said anything else. But while the job is very well done on your side, many component authors did not think about such big databases resulting in performance issues. I'm sure foobar will handle those 100000 tracks quite perfectly in default setup on a halfway modern machine unless you do something very stupid (like adding the whole DB 100 times to a playlist :D).

Btw. I have to gratulate you on very thought-throught API you are providing for foobar - as seen in it's full grace in the implementation of the queue variables ;).

Quote
Updating whole media library with each playback state, playback queue state, system time etc change will:
- Cause full rebuild of all autoplaylists etc - which means running some query on all items in the library, possibly repeatedly if multiple autoplaylists exist.
- Totally kill performance of any other realtime ML viewers (autoplaylist is the only one I'm currently aware of, but we plan to add autorefresh to Album List sooner or later).

quote me:
Quote
I said it has to be tested and if it's gives acceptable results should be added as an _option_.

So you're saying as long as you are not using autoplaylist or a realtime ML viewer (which are horrible idea after all - I don't want to wait for this damn thing to reload my 20000 tracks just to listen to that one new song oO) we are safe to send a update for the whole library? :P (Just kiddin ;)

foo_cwb_hooks

Reply #95
So you'd say that we should provide a interface for other components to use these new title formating vars and hope for them to implement it?
That's exactly what I was getting at. In the old days people weren't afraid to create and publish their own services. Asking the right people to support it can be a big help in getting such communication between components to work.  As far as I can see this functionality is mostly desired for use in the track info panel, so that you should probably talk with terrestrial about a solution.

foo_cwb_hooks

Reply #96
That's exactly what I was getting at. In the old days people weren't afraid to create and publish their own services. Asking the right people to support it can be a big help in getting such communication between components to work.  As far as I can see this functionality is mostly desired for use in the track info panel, so that you should probably talk with terrestrial about a solution.


In the next version of cwb_hooks I will make a callback service that plugins interested in getting notifications of the change in a variable can implement.  I'm thinking the best way to do it is to pass the name of the relevant variable to the callback function so that plugin writers can do a quick strstr() or equivalent function to test whether that variable appears in a formatting string.
There used to be a link to my website here.

foo_cwb_hooks

Reply #97
If there's one feature in this, I'm going to start using it. That feature is:

information about the current dB (or similar level) of the track, maybe average track dB etc. - This would allow for some VERY interesting effects.

hope it could be included, that would be killer :-)
err... i'm not using windows any more ;)

foo_cwb_hooks

Reply #98
I'd just like to restate my suggestion for some kind of global variable system to store values that can be used by formatting strings and changed by buttons, menus, etc.

foo_cwb_hooks

Reply #99
Please, add %cwb_next_directoryname%. It would be great
Thinking Outside The Box