foo_playlist_attributes

Topic: foo_playlist_attributes (Read 100030 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

foo_playlist_attributes

Reply #75 – 2009-10-11 19:00:58

I thought it could be considered related since this component is dealing with playlists.
I'll try to clarify.
In the media library, pressing enter key or double clicking (could be dependent on setting in preferences) will send the selected files or songs if you wish, to the currently active playlist. Pressing shift + enter will add the selection to the currently active playlist.
What I'm looking for is an option to have the above operations be applied to a predefined playlist.

foo_playlist_attributes

Reply #76 – 2009-10-11 19:30:44

Quote from: trashcan on 2009-10-11 19:00:58

What I'm looking for is an option to have the above operations be applied to a predefined playlist.

I assume with "media library" you mean the album list media library viewer (there are other media library viewers, too, which may operate differently). To get what you want, it has to be implemented by the album list. It can't be done by my component, because it has no idea what the user is currently doing with the album list. This what I meant, when I mentioned, that there is no relation to my component.

foo_playlist_attributes

Reply #77 – 2009-10-12 07:45:56

Quote from: fbuser on 2009-10-11 13:06:34

Because during playing the current track, you start another track. Skip doesn't necessary mean skip to the next or the previous track.

hm, when I press skip (and I mean "next track"), I want to skip that track, but when I double click some other track (usually different album/artist/playlist) I didn't meant to intentionality "skip" that track. Now I would have to press stop and than double-click so that the track isn't counted as skipped - it just doesn't seems right to me

The reason I'm using "send skipped tracks to playlist" is that they'll get something like skip_count (manually unfortunately) so when it accumulates enough they'll get low rating and be automatically skipped in the future.

Quote from: fbuser on 2009-10-11 13:06:34

Personally, I don't like the way, how play count is handled by the official playback statistics component. So I never intended to be consistent to it. It's rather consistent to the behaviour of the "Remove played tracks" option, which was earlier implemented.

Well OK, I guess that just another user preference

foo_playlist_attributes

Reply #78 – 2009-10-12 12:10:23

Would it be possible to assing option "Reset >stop affter current<" on per playlist basis?

foo_playlist_attributes

Reply #79 – 2009-10-12 19:08:49

Quote from: 2E7AH on 2009-10-12 07:45:56

Quote from: fbuser on 2009-10-11 13:06:34
Because during playing the current track, you start another track. Skip doesn't necessary mean skip to the next or the previous track.

hm, when I press skip (and I mean "next track"), I want to skip that track, but when I double click some other track (usually different album/artist/playlist) I didn't meant to intentionality "skip" that track. Now I would have to press stop and than double-click so that the track isn't counted as skipped - it just doesn't seems right to me

I think you have a different understanding of skip than me. But there is no need to discuss it here, because I get no information from the SDK, when the user press "next track". I get only the information, when a track was stopped, because another track is started.

Quote from: lwiczek on 2009-10-12 12:10:23

Would it be possible to assing option "Reset >stop affter current<" on per playlist basis?

I have no access to this setting with the SDK, so it is not possible.

foo_playlist_attributes

Reply #80 – 2009-10-13 06:17:58

Quote from: fbuser on 2009-10-12 19:08:49

I think you have a different understanding of skip than me. But there is no need to discuss it here, because I get no information from the SDK, when the user press "next track". I get only the information, when a track was stopped, because another track is started.

Do you think it's good idea (or possible) to introduce some kind of timing setting (like we discussed about custom_db ) for this played and skipped tracks?
i.e. If we set the timing to 1min, than the track will be sent to played tracks playlist when this timing is reach, or sent to skipped playlist if we skipped the track before this timing limit (so if I "skip" the track after 1min period it won't be sent to skipped playlist, and it will be already in played tracks playlist of course)?

foo_playlist_attributes

Reply #81 – 2009-10-13 17:37:47

Basically, this is possible, as the SDK offers the possibility to get informed, when a track is considered as played consistent to the playback statistic component. Of course, it would be possible, too, it there were no such information. But I don't see any real use for it. Could you explain it more detailed, what you want to achieve with this behaviour?

foo_playlist_attributes

Reply #82 – 2009-10-14 10:35:53

If set to 1 min - played tracks will correspond to with play_count (like %last_played% playlist) and for skipped tracks, skip_count will be usable for me - my main point, as I said before how I meant to use it.
If set to 100% the behavior will be like it is now.
There will be other usage possibilities open

foo_playlist_attributes

Reply #83 – 2009-10-20 07:54:08

I'm using the latest version and I have an odd issue when setting to "Repeat Track" or "Repeat Playlist", the playback gets stuck in the last two seconds. Removing the component fixes the issue.

foo_playlist_attributes

Reply #84 – 2009-10-20 17:59:59

I can confirm this behaviour, when using a "Repeat track" together with "Bookmark last playback position". I will look into it. In the meantime don't use this options together.

foo_playlist_attributes

Reply #85 – 2009-10-20 18:47:53

For me enabling the global option "Playback on active playlist" (under playback menu) has no effect - the correspondending opton under edit menu works fine.

foo_playlist_attributes

Reply #86 – 2009-10-20 19:48:24

Strange, even after a short glance on the source code it should work, and of course it worked, but now it doesn't. Anyway, I will fix it with the next release.

foo_playlist_attributes

Reply #87 – 2009-10-20 22:12:53

Both issues should be fixed now. See the first post for the new version.

foo_playlist_attributes

Reply #88 – 2009-11-16 19:51:38

New version. See first post for download and details.

foo_playlist_attributes

Reply #89 – 2009-11-26 14:42:08

Request to add DSP preset to playlist attributes

foo_playlist_attributes

Reply #90 – 2009-11-26 19:34:13

Do you mean different saved presets for the presets choice on per playlist base? This is not possible and I don't think that it is useful enough to implement it.

foo_playlist_attributes

Reply #91 – 2009-11-27 08:17:13

Yes! It's possible with 1.0! And it's indeed useful (at least more than several other features you've implemented imho!)

Edit: It's possible to assign a keyboard shortcut to the presets, however, I couldn't see the presets when I tried to assign them to CUI buttons.

foo_playlist_attributes

Reply #92 – 2009-11-27 20:08:42

Quote from: odyssey on 2009-11-27 08:17:13

Yes! It's possible with 1.0!

That doesn't necessary mean, that it implementable by a 3rd party component. With the current SDK it is not possible. If it will be possible with the next SDK, I don't know.

Quote from: odyssey on 2009-11-27 08:17:13

And it's indeed useful (at least more than several other features you've implemented imho!)

We were obviously talking about two different things, because I didn't know that it is possible to address one preset directly with fb2k 1.0. Actually, in this way it is useful (also for me, and that is a must to implement a functionality).

foo_playlist_attributes

Reply #93 – 2009-12-10 08:36:36

I just downloaded (upgraded to) the latest version. Seems that you've already implemented the ability to choose different DSP settings. However, I can't make it work (but then again, I didn't think it was possible due to SDK anyway).

foo_playlist_attributes

Reply #94 – 2009-12-10 19:21:02

Quote from: odyssey on 2009-12-10 08:36:36

I just downloaded (upgraded to) the latest version. Seems that you've already implemented the ability to choose different DSP settings. However, I can't make it work (but then again, I didn't think it was possible due to SDK anyway).

Can you describe it in a more detailed way, what excatly doesn't work for you?

foo_playlist_attributes

Reply #95 – 2009-12-10 20:46:44

Well, when I change DSP settings (e.g. remove Continuator DSP for certain playlists), it's not effective at all.

foo_playlist_attributes

Reply #96 – 2009-12-10 21:31:41

I can't confirm this. For me removing Continuator DSP works as desired here.

foo_playlist_attributes

Reply #97 – 2009-12-11 14:31:03

You are right, it works fine - I must have overlooked something when I tried it

foo_playlist_attributes

Reply #98 – 2010-01-11 08:54:30

At the moment I am using foo_playlist_attributes 0.2.2 [Nov 16 2009 - 20:33:31] with fb2k 0.9.6.9 on Windows XP Professional. Might I ask two questions:

1.
Are all plugin settings saved entirely in foobar's config file so that for example all playlist restrictions set by foo_playlist_attributes are removed from them when I delete the plugin and I tell foobar when it runs next time that the settings shall not be kept?

2.
Is it an intended behaviour that foo_playlist_attributes bookmarks even files which have been played completely? Steps to reproduce what I am meaning:

I am saving first-time foo_playlist_attributes in foobar's components folder.
I run foobar, go to menu Playback, Playlist attributes -> Bookmark last playback position.
I am playing an arbitrary audio track entirely. foobar's playback settings are: "Stop after current" and "Repeat (track)".
Restarting the playback of the same file by pressing enter or the corresponding button foobar jumps nearly until the track's end and plays only approximately its last second.

If I should have misunderstood how this option is functioning I beg your pardon.

foo_playlist_attributes

Reply #99 – 2010-01-11 11:05:52

Quote from: Robertina on 2010-01-11 08:54:30

Are all plugin settings saved entirely in foobar's config file so that for example all playlist restrictions set by foo_playlist_attributes are removed from them when I delete the plugin and I tell foobar when it runs next time that the settings shall not be kept?

I would think this component rather uses the "playlist properties" API, because it's very handy to store per-playlist settings. Then the attributes would be stored in the individual playlist files, but I might be wrong here.