titleformat notification callback

2007-02-28 07:07:38

Ever since I started using foobar2000 I have tried to come up with an easy, intuitive way to abstract the playing playlist from the browsing playlist. This is the one thing I find foobar is not designed for. I have tried to use the queue but it has too many limitation and quirks that don't make sense to me. So, I use a dedicated "playing" playlist.

Basically I would like to view my playing playlist with all the eye candy of scpl, which also allows me to easily move the tracks. But I would also like to see the tracks currently selected to play and the currently playing track in the browser playlist, which is where I spend most of my time.

I wrote a couple simple extensions to titleformatting which
1) finds the tracks in the currently playing playlist
2) finds the currently playing song in the playing playlist.

Here is a screen shot which shows a simple display of the browser playlist with tracks in the browser, (highlighted) tracks in the currently playing playlist, (highlighted) current track playing in the playing playlist and a (highlighted) selection that spans both.



Now, the problem I have is that these extensions are essentially useless because the active playlist being displayed is not updated when there are changes to playing playlist's state.

I was wondering, is it possible for the active playist to be notified of changes in the playing playlist so that it can update it's display?

Thanks.

PS: I debated where to ask this, here, 3rd party plugins, columns ui thread, panels ui thread, etc. I decided to ask it here to first get an idea if this is possible, if so, can I implement it in my own component, if not, is it worth requesting it of the ui implementer, or requesting it of foobar2000.

titleformat notification callback

Reply #1 – 2007-02-28 08:55:16

If some playlist view - or more generally an information viewer - wants to aggregate information from multiple places, it should listen to update notifications for all the relevant places. If the component in question is configurable, it should expose appropriate methods to the user to select the data source for a given piece of information.

The foobar2000 core will not be changed to spam notifications about unrelated events all over the place to make it easier for components to abuse the titleformat mechanism for things that go way beyond what it was designed for.

titleformat notification callback

Reply #2 – 2007-03-01 03:47:48

[edited for clarity (I hope)]

Absolutely, spamming notifications would be pretty stupid. Still, I don't think the concept of notifying another panel of state changes to a shared item in another panel is abusive to titleformatting.

Thanks foosion, for redirecting my line of thought and understanding of the problem.

As I understand it, the "media library", instantiates all the "items" used in foobar, panels (or playlist viewers) obtain handles to these objects held by the media library, thus they share these items. There are certain state variables that are held by a playlist and not "shared" because these are playlist specific variables, for instance, is the item in the playlist, what is it's position in the playlist and is it playing. All of these state variables are available to implementations of titleformatting %xxx% variables.

One possible solution for a cross panel notification system is that each panel expose both a notification service and a listener implementation. Through the panel's config UI a user could register that one panel wants to listen to item state changes on another panel. State changes include:
1) Item is added
2) Item is removed
3) Item is playing
4) Item stopped playing
4) Item changes position

The listener implementation I'm not clear on, because I'm not familiar with panel implementations or with how the titleformatting backend is implemented. I do know that if the item that has changed is currently in view, if the implementation simulated a mouse click on the item, that would work. Of course, that is not a solution.

I do agree that this is not for the faint of heart, if you have hundreds of tracks in the playlist you are listening to, and then clear them, the process might be lengthy. But if I wanted to listen to hundreds of tracks I would put them in their own playlist and play them from their, I wouldn't use this mechanism.

I also agree that it's usefulness is really only geared to perhaps a small percentage of how people use their media player. Personally, I tend to chose a relatively small number of tracks at a time to play and I like to mix and move move them easily. Thus, the separation of browser from playing list and desire to see the state of the playing list in my browser.

Anyways, it's really not that big a deal.