Skip to main content
Topic: Show tracks with same title as the currently playing (Read 9602 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Show tracks with same title as the currently playing

Hi there,

As an introduction, I always name my tracks using several tag fields :
- %artist% : e.g. "Barclay James Harvest"
- %original artist% : %artist% if empty, otherwise contains the original artist of the song
- %title% : e.g. "Medicine Man"
- %version% : e.g. "Live"
- %subversion% : e.g. "BBC 1972"
Then I reunite the information when displaying them : "Medicine Man  [Live, BBC 1972]"

The purpose of all this is to really separate the track's title from any additional information. This way I can easily see for any given song how many different versions I've got, and quickly compare them. This can be easily done with Facets and a single multicolumn facet (columns : Original Artist, Title, and Statistics>Tracks). e.g. I've got 8 different versions of BJH's "Medicine Man".

Now instead of making a search every time I'm playing a song (especially in shuffle mode), it would be very nice if foobar could automatically show all other songs with the same %title% (and optionally the same %original artist%). These songs could be shown in an autoplaylist called "Other Versions Available" or something like that. Unfortunately, I don't know a way to create such an autoplaylist (I don't think it's possible for the average user).

So maybe a dev could think about this functionality, that could be :
- Either integrated into foobar's core,
- Or developed as a 3rd party component (for example a DUI element, a bit like a Facet that would be able to modify its contents according to the currently playing song).

E.g. I'm playing the above song, and I automatically see in a DUI element :
"Other Versions Available :
DATE.....ORIGINAL ARTIST..............TITLE.................VERSION...SUBVERSION
1974.....Barclay James Harvest.....Medicine Man.....Live..........BBC 1974 In Concert
1972.....Barclay James Harvest.....Medicine Man.....Original.....Single Version
Etc.
(and of course a double click would launch the playing of another version)

Well, what do you think ? Thanks.

Show tracks with same title as the currently playing

Reply #1
title HAS CURRENT


...would be make for some nice queries and autoplaylists.
elevatorladylevitateme

Show tracks with same title as the currently playing

Reply #2
Hi shakey snake,

Forgive me but I don't know if you're suggesting me to use something that already exists or not. For example, in a Library Search, "%title% HAS CURRENT" doesn't work. Am I doing something wrong ?

Besides, wouldn't it be more 'usable' if the info was directly displayable in a DUI element, instead of being available inside a playlist ? Just asking.

The ideal for me could be something like a "Conditional Facet" : I mean a Facet that would display its contents ONLY if a given condition is valid (e.g. if "%title% HAS CURRENT" gives more than 1 result). And the Facet itself would display all versions of the playing track, EXCEPT the one that's already playing of course.

Maybe all this can already be done, but I can't figure out how. Any help appreciated.

Just my two cents...

Show tracks with same title as the currently playing

Reply #3
Having a component which automatically finds tracks related to the current playing track isn't a bad idea and it's been suggested before, but your example seems too marginal considering how rarely multiple versions appear in "most" (e.g., non-classical music) users' libraries. I think more users would use such a component to show tracks by the same artist, album, or perhaps genre before they consider title.

Show tracks with same title as the currently playing

Reply #4
Hi shakey snake,

Forgive me but I don't know if you're suggesting me to use something that already exists or not.

No, CURRENT does not exist, yet. But I'm trying to take your idea and realize it in what I think would be a more usable way, and maybe more feasible to implement.

If you add CURRENT to the query language, you could create any number of queries or autoplaylists that would do something similar to what you are suggesting.

For example, a query artist HAS CURRENT would show all the tracks of the currently playing artist.

genre HAS CURRENT AND year GREATER THAN 2000 would make another interesting playlist.


However, a problem would be that the playlist would need to be refreshed with every track change, which could be quite resource hungry.
Of course, same goes with  %last_played% DURING LAST 1 MINUTE and your idea as well.
elevatorladylevitateme

Show tracks with same title as the currently playing

Reply #5
I think Playlist Tree Mod allows you to run queries based off the now-playing song, and it can be set to auto-refresh every time the song changes. I couldn't begin to tell you exactly how to do this, though.

As an ad hoc thing, if you use the Quicksearch Toolbar, it adds 'Quicksearch for same Title/Artist/Album and a few others to the context menu. (I actually have Quicksearch for same title mapped to a toolbar button most of the time, as it's very useful when on an autoplaylist where the currently-playing song has been removed.)

I agree that adding CURRENT or something similar to the query syntax, as shakey_snake suggests, would be a brilliant idea, though.

Show tracks with same title as the currently playing

Reply #6
Having a component which automatically finds tracks related to the current playing track isn't a bad idea and it's been suggested before, but your example seems too marginal

I agree my example might seem marginal, and if a component should arise of all this, it's true that it could do lots of other things (provided it does this one  ).

considering how rarely multiple versions appear in "most" (e.g., non-classical music) users' libraries

In my own library, multiple version songs (number of versions = 2 or greater) account for 5660 out of 25936. That's 21.8% and is far from being marginal.

If we take out the classical music, we still have 21966 tracks left (as you can see I'm like "most" users  ). From these 21966 tracks, we still have 5541 multiple version songs. That's 25.2%, even less marginal.

But like I said, I've tagged all my songs carefully (unlike "most" users I would say) in order to be able to find quite easily different versions and other stuff. An extensive & complete tagging can be extremely helpful for any music enthusiast IMO. But of course it takes some time.

If you add CURRENT to the query language, you could create any number of queries or autoplaylists that would do something similar to what you are suggesting.

I agree, that would be a great yet simple idea. If it becomes reality one day, then it will be up to everyone to use it 'reasonably' because of the 'resource hungry' thing. But I think it shouldn't be a problem with any modern hardware. And users wouldn't be compelled to use it so...

Show tracks with same title as the currently playing

Reply #7
If you add CURRENT to the query language, you could create any number of queries or autoplaylists that would do something similar to what you are suggesting.

...

However, a problem would be that the playlist would need to be refreshed with every track change, which could be quite resource hungry.


I don't know why autoplaylist are so favoured when it comes to realize some functionality. 

Since some weeks i wanted to post a request for a component but didn't find the time so far. My idea was closer to foorius suggestions to show the desired content in facets: a new "selection information" viewer that would exactly do that and would leave other library viewer do their job. That selection viewer wouldn't work greatly different than the "search same" functionality of foosions database search which already can perform such searches if you invoke the commands from context menu of the status bar. But as an UIElement it would provide the advantages to show all defined queries in one window as nodes in a specific view.

I mean following:

I add a query to that Ui Element and just have to define three parts

(Example)

Name: Other albums of '%artist%'
Query: artist IS %artist% and NOT album IS %album%
View: %album%|%tracknumber%. %title%

(@shakey snake: How should CURRENT work? It is not defined)


I see many advantages providing that UiElement instead of using autoplaylists:

- as a selection viewer that UiElement could offer the opportunity to choose the source (now playing or selected track)
- you can create a layout where that UiElement is always in your view
- you can browse the results in a defined tree view so that each query is presented with the most suitable view
- you can apply a context menu command on each node

But what would be really incredible is that as a selection viewer it could also handle multiple selections and that would mean a totally new way of browsing your library

Even if you have a multiple selection you can have a clear query as long as the expression after the operator has just one value in the multiple selection. Take the example from above: if both %artist% and %album% just have one value the query could be displayed in the Uielement - and if not it could be blanked out.

That feature would allow to browse the library in a totally different way. Lets say i have a facet that shows me the artists of my library and you select whatever artist: the query in the selection information viewer would then f.e. show me similar artists and their albums. I hope you can recognize what i mean with totally different.

(Sorry for my english, i am not really in mood today to write english and i hope you understood my post)

Show tracks with same title as the currently playing

Reply #8
I totally agree with q-stankovic. I think we share the same vision of a future (D)UI Element with all the related advantages.

He's been even clearer than me, because yes, I also think an UI Element would allow a whole new way of browsing our libraries and maybe digging out some not-so-well-known treasures.

Show tracks with same title as the currently playing

Reply #9
[quote author=q-stankovic link=msg=602897 date=1228418756]I don't know why autoplaylist are so favoured when it comes to realize some functionality. [/quote]Because I'm trying to make a suggestion that wouldn't require Peter to do a bunch of tedious, labor intensive GUI work.

[quote author=q-stankovic link=msg=602897 date=1228418756]Since some weeks i wanted to post a
(Example)

Name: Other albums of '%artist%'
Query: artist IS %artist% and NOT album IS %album%
View: %album%|%tracknumber%. %title%

(@shakey snake: How should CURRENT work? It is not defined)[/quote]
Your equivalent query would be:
artist IS CURRENT AND NOT album IS CURRENT


[quote author=q-stankovic link=msg=602897 date=1228418756]I see many advantages providing that UiElement instead of using autoplaylists:

- as a selection viewer that UiElement could offer the opportunity to choose the source (now playing or selected track)
- you can create a layout where that UiElement is always in your view
- you can browse the results in a defined tree view so that each query is presented with the most suitable view
- you can apply a context menu command on each node

But what would be really incredible is that as a selection viewer it could also handle multiple selections and that would mean a totally new way of browsing your library

Even if you have a multiple selection you can have a clear query as long as the expression after the operator has just one value in the multiple selection. Take the example from above: if both %artist% and %album% just have one value the query could be displayed in the Uielement - and if not it could be blanked out.

That feature would allow to browse the library in a totally different way. Lets say i have a facet that shows me the artists of my library and you select whatever artist: the query in the selection information viewer would then f.e. show me similar artists and their albums. I hope you can recognize what i mean with totally different.[/quote]As you might know, Songbird 1.0 was just recently released and I checked it out.

There is this addon for it that does a remarkable similar as to what you've described. It queries last.fm data to produce "similar artists" which if you have them in your library you can then play.

I thought that was a remarkably cool feature, although the important parts of songbird (so says a foobar200 user) is a little, erm, lacking, but it has lots of these sorts of cool things like that.

It's not that foobar2000 couldn't become a program that does all the essentials right (speed, playback engine, DSPs, file management & tagging, file conversions,etc) and does the cool, nifty things right, but that's a tall order for a program that is basically a one man show.

CURRENT, in my mind, is just more pragmatic/reasonable.
(Especially, with the UI Elements SDK still not in the wild, yet)
elevatorladylevitateme

Show tracks with same title as the currently playing

Reply #10
My only request? If something like this is implemented, however it's implemented? Don't make it tied to one UI or the other. (Which is another point in favor of the autoplaylist solution  )

Show tracks with same title as the currently playing

Reply #11
[quote author=q-stankovic link=msg=602897 date=1228418756]Since some weeks i wanted to post a
(Example)

Name: Other albums of '%artist%'
Query: artist IS %artist% and NOT album IS %album%
View: %album%|%tracknumber%. %title%

(@shakey snake: How should CURRENT work? It is not defined)
Your equivalent query would be:
artist IS CURRENT AND NOT album IS CURRENT
[/quote]

But where is it defined that in this case CURRENT means %artist%? How f.e. would you translate following Query: artist IS %featuring artist%? What could work: artist IS CURRENT <%featuring%> AND ...

As i already said i don't consider an autoplaylist to be a good place for such searches/queries. Not only that a selection viewer would have some advantages i described above but autoplaylists with such queries would behave in an unexpected and confusing way when you start playing such an autoplaylists: It could even happen that the track you started disappears from the autoplaylist - not very elegant.

As you might know, Songbird 1.0 was just recently released and I checked it out.

There is this addon for it that does a remarkable similar as to what you've described. It queries last.fm data to produce "similar artists" which if you have them in your library you can then play.

I know such features from Helium Music Manager  Amarok - what i don't like about it is that it queries data from the internet and doesn't gives me the possibility to create my own queries based on my library

EDIT:

@Doc Beard

There is already an ui-independet way to do that - you can perform such searches with foosions database search when you select the query mode in its preferences. Additionally to that you can apply the "create album list view" command to the result list in database search if you likes to browse the search result. Not very convenient but it works.

Show tracks with same title as the currently playing

Reply #12
.... if you use the Quicksearch Toolbar, it adds 'Quicksearch for same Title/Artist/Album and a few others to the context menu.

Search for same %title% can also be mapped to a function key, even when using DUI.

Show tracks with same title as the currently playing

Reply #13
[quote author=q-stankovic link=msg=603014 date=1228480478]I know such features from Helium Music Manager  Amarok - what i don't like about it is that it queries data from the internet and doesn't gives me the possibility to create my own queries based on my library[/quote]
Exactly. I think q-stankovic and I are talking about our own libraries, not about some internet-based plugin.

It's not that foobar2000 couldn't become a program that does all the essentials right (speed, playback engine, DSPs, file management & tagging, file conversions,etc) and does the cool, nifty things right, but that's a tall order for a program that is basically a one man show.
Well, that's why we may be talking about a 3rd-party component. That wouldn't make much work for Peter, would it ?

Especially, with the UI Elements SDK still not in the wild, yet)
Any info about an estimated availibility date ? It's really a pity such SDK is still unavailable a year or so after 0.9.5...  I understand Peter might be all alone sometimes, but when he released 0.9.5 he really created a need for such SDK, and I guess all this might be a bit frustrating for 3rd-party developers, to say the least.

My only request? If something like this is implemented, however it's implemented? Don't make it tied to one UI or the other. (Which is another point in favor of the autoplaylist solution  )
DocBeard, forgive me but I rather think that for any given feature request (e.g. the title of this topic), the developer's choice between several ways of implementing it should be based primarily on what will give the best final user experience

And I think it's quite obvious here that an UI element (be it DUI or CUI) would give a much better user experience than any Autoplaylist-based solution : one can easily imagine the advantages (q-stankovic has already mentioned some of them).

Besides, if a 3rd-party developer is interested in such a project, then it will be up to him to decide if he makes it available for DUI, CUI, or both. And I don't think any 'Don't make it tied to one UI or the other' comments will change his global vision of such a component. Thank you.

Show tracks with same title as the currently playing

Reply #14
Besides, if a 3rd-party developer is interested in such a project, then it will be up to him to decide if he makes it available for DUI, CUI, or both.


I believe that such a functionality would fit really good into the databasesearch plugin    as it already offers such searches.

Show tracks with same title as the currently playing

Reply #15
I guess it seems like you guys think that I'm somehow attacking this specific idea you have for a component. Really, that couldn't be farther from the truth.
As I've stated before, I'm just trying to be pragmatic.

In my three years of lurking/two years posting here I've never seen someone with a specific, grand vision for a component have a developer pick up their suggestion and vicariously implement as "the hoards" have delineated, with the exception being Terrestrial, who isn't around any longer and, according to "those in the know" couldn't develop anything in the proper manner, anyways. (As a somewhat philosophical aside, I think it's entirely possible to say that if Terrestrial's work was sloppy, this could be a result of a lack of a specific vision)

Of course, I've assumed this attitude before on smaller features and have been recently proven wrong.

[quote author=q-stankovic link=msg=603014 date=1228480478]But where is it defined that in this case CURRENT means %artist%? How f.e. would you translate following Query: artist IS %featuring artist%? What could work: artist IS CURRENT <%featuring%> AND ...[/quote]
You wouldn't be able to query other fields as I've envisioned CURRENT. It's role would be terminal, more like MISSING and PRESENT than anything.
Although, I think you could begin to argue the necessity of a %feat artist% tag, anyways.

[quote author=q-stankovic link=msg=603014 date=1228480478]As i already said i don't consider an autoplaylist to be a good place for such searches/queries. Not only that a selection viewer would have some advantages i described above but autoplaylists with such queries would behave in an unexpected and confusing way when you start playing such an autoplaylists: It could even happen that the track you started disappears from the autoplaylist - not very elegant.[/quote] A query doesn't have to be made into an autoplaylist. It can, and I agree that would be very messy, but it doesn't have to.


[quote author=q-stankovic link=msg=603014 date=1228480478]
As you might know, Songbird 1.0 was just recently released and I checked it out.

There is this addon for it that does a remarkable similar as to what you've described. It queries last.fm data to produce "similar artists" which if you have them in your library you can then play.

I know such features from Helium Music Manager  Amarok - what i don't like about it is that it queries data from the internet and doesn't gives me the possibility to create my own queries based on my library
[/quote]Sure, it isn't implement in songbird exactly how you guys are requesting, but considering exactly what you guys are requesting, it seems to be redundant, considering the already available Media library search.

Lets be honest, what you are really suggesting is a  "treed" ML search element with some additions made to the Query language. Or, to be even more feature-overlap-thinking, you want foo_playlist_tree for the DUI (Hi, DocBeard).

Am I off here?
elevatorladylevitateme

Show tracks with same title as the currently playing

Reply #16
I guess it seems like you guys think that I'm somehow attacking this specific idea you have for a component. Really, that couldn't be farther from the truth.


I really never thought that.

Sure, it isn't implement in songbird exactly how you guys are requesting, but considering exactly what you guys are requesting, it seems to be redundant, considering the already available Media library search.


How can the media library search help me do such searches? I mentioned the database search plugin in combination with the album lists custom view wich i use for such searches and was talking about more convenience that a UiElement could offer. But beside of that my main point
was the handling of multiple selections that would make possible a new way of navigation through the library - a way of browsing i didn't see so far in any program. (Edit: Beside of the artist relations node in Helium Music Manager)

In my three years of lurking/two years posting here I've never seen someone with a specific, grand vision for a component have a developer pick up their suggestion and vicariously implement as "the hoards" have delineated ...


I know that i am writing my posts soetimes in a way wich could force the misunderstanding i am writing them as instructions - but due to my poor english it is just easier for me to speak about concrete details. I never expect that an author would implement a feature in exact the same way i described. Just want to demonstrate what i mean.

Or, to be even more feature-overlap-thinking, you want foo_playlist_tree for the DUI


Yes and No

No because i don't want to see/use never ever such an component again
Yes because PT contained some good features and they should'nt be offered by one component but could be reallocated among already existing or new components. I think many requests i made for album list, facets, library search or database search are inspired by PT's functionality

Show tracks with same title as the currently playing

Reply #17
DocBeard, forgive me but I rather think that for any given feature request (e.g. the title of this topic), the developer's choice between several ways of implementing it should be based primarily on what will give the best final user experience


I agree. And something that locks out half the users of the program is hardly going to give the best final user experience to those users, now is it?  Surely the ideal is to give the best experience to the largest number of people.

Quote
And I think it's quite obvious here that an UI element (be it DUI or CUI) would give a much better user experience than any Autoplaylist-based solution : one can easily imagine the advantages (q-stankovic has already mentioned some of them).

Besides, if a 3rd-party developer is interested in such a project, then it will be up to him to decide if he makes it available for DUI, CUI, or both. And I don't think any 'Don't make it tied to one UI or the other' comments will change his global vision of such a component. Thank you.


Well, that would all be why it's a request and not a demand. 

I actually do agree that integrating this functionality into some existing component would make a lot of sense. (I'm not familiar with the database search component that's been referenced; is it UI-independent?) Adding something to the query syntax (which I, mistakenly, referred to as the Autoplaylist Solution, though it's obviously wider-ranging than that) would be a good place to start that process; that way it could be accessible through the built-in library search and anything else that uses that syntax (which includes both Columns UI panels and default UI elements, as well as some things which are UI-independent).

Obviously any developer (third-party or otherwise) is free to disregard my thoughts on this matter, but that's surely no reason for me to avoid sharing them.

Show tracks with same title as the currently playing

Reply #18
Sorry if it has already been mentioned in the thread, but I have exactly this functionality using columnsUI and playlist tree mod with a query like:

%title% HAS @format<$playing('%title%')> AND NOT %directory% IS @format<$playing('%directory%')>

It works perfectly.
I don't know if you can use playlist tree mod in DUI though..

Show tracks with same title as the currently playing

Reply #19
I actually do agree that integrating this functionality into some existing component would make a lot of sense. (I'm not familiar with the database search component that's been referenced; is it UI-independent?) Adding something to the query syntax (which I, mistakenly, referred to as the Autoplaylist Solution, though it's obviously wider-ranging than that) would be a good place to start that process; that way it could be accessible through the built-in library search and anything else that uses that syntax (which includes both Columns UI panels and default UI elements, as well as some things which are UI-independent).


Even if something to the query syntax would be added database search already don't just give already more more but uses the full capacity of title formatting and the query syntax. In its preferences you store a format as preset - this preset is written as title formatting and gets evaluated. This evaluated pattern then is used as query syntax. Example: if you use as format "mood IS $meta_sep(mood, mood IS )" then the query syntax will become to something like "mood IS bla AND mood IS blabla ...". (that is the way Playlist Tree worked too). So compare already existing possibilities to an operator like CURRENT and ask yourself: what is the real benefit of it? Typing a query in the library search? So why not using the database search then that offers much more then it comes to such searches. Instead of typing anything you can apply complex searches by context menu or button.

It is time to get familiar with database search! 
Yes it is ui_independent as it doesn't offer an Ui_element or a panel.

Show tracks with same title as the currently playing

Reply #20
I guess it seems like you guys think that I'm somehow attacking this specific idea you have for a component. Really, that couldn't be farther from the truth. As I've stated before, I'm just trying to be pragmatic.

shakey, I couldn't even think that of you. Really, it's not your style. I respect very much your opinions since you probably know more about foobar than most users here. So don't worry, we are just discussing. 

I've never seen someone with a specific, grand vision for a component have a developer pick up their suggestion and vicariously implement as "the hoards" have delineated

Yes. What a pity don't you think ? 

Lets be honest, what you are really suggesting is a  "treed" ML search element with some additions made to the Query language. Or, to be even more feature-overlap-thinking, you want foo_playlist_tree for the DUI (Hi, DocBeard).

To be honest, I've never thought of a "treed" approach, and I've never seen foo_playlist_tree since I don't use CUI. Like I've said, I'm thinking of a Facets-like UI element. An element made of several configurable columns (just like Facets), that would display results in real-time according to the currently playing song. One could previously configure that UI element with a tag-based multi-criteria query in order to display (some examples) :
- Tracks with the same [%artist% / %album artist% / %original artist%] AND with the same %title%
- Tracks with the same [%artist% / %album artist% / %original artist%]
- Albums with the same [%artist% / %album artist% / %original artist%]
- Tracks with the same [%artist% / %album artist% / %original artist%] AND with the same [%album%]
- Tracks with the same [%genre% / %subgenre%]
- Albums with the same [%genre% / %subgenre%]
- Etc.

Besides, if that UI element was an evolution of Facets (a sub-component of Facets, or a component made to function with Facets), there would be another advantage : the results could be displayed not only according to the currently playing song, but also according to the result of any facets search. Imagine I type the name of an artist and the name of a song. Facets finds me the song I'm looking for... but in another facet, it also shows me all versions of the same song by other artists. And I suppose there are lots of other possibilities.

something that locks out half the users of the program is hardly going to give the best final user experience to those users, now is it?

Please don't mix up user experience and user base for they are different things and we all know that. Anyway, the fact is that IF an UI element arises of this discussion, its developer will decide on what's best, period.

You know, an UI element like Facets, available for DUI only, "locks out half the users of the program" according to your own words. And... so what ? Would you dare say that Facets doesn't give users the "best final user experience" ? Well, that wouldn't be fair considering Frank Bicking's totally excellent work on such a plugin. 

We could go on and on, because for example even foobar, available for Windows only, locks out all OS X users. The truth is that you can't make everyone happy. And the developer's point of view will probably be to make the best possible piece of software rather than trying to make everyone happy.

For a developer, the choice of an UI (DUI, CUI) is a bit like the choice of a programming language. I bet you wouldn't tell any developer "please don't use C++ : use Java instead since it's platform-independent", would you ? 

Show tracks with same title as the currently playing

Reply #21
@foorious

If you would be satisfied with simple same searches: this could be realized in a simple way way in Facets by distinguish in each Facet that values that are present in the now playing song. As i remember Frank Bicking even thought about that but the feature to "Highlight all items containing the currently playing track, to show a path to it" was dropped as using the highlight colour of the DUI was too inconsistent. May be there could be another way to do that highlighting (icons?).

Show tracks with same title as the currently playing

Reply #22
Thanks q-stankovic. However, as you can imagine, the most interesting searches are the multiple ones.

The most obvious here is :
Tracks with the same [%original artist%] AND with the same [%title%]
Which will give all other versions of the currently playing song.

(of course %original artist% = something like $if2(%original artist%,%artist%))

Show tracks with same title as the currently playing

Reply #23
I guess it seems like you guys think that I'm somehow attacking this specific idea you have for a component. Really, that couldn't be farther from the truth. As I've stated before, I'm just trying to be pragmatic.

shakey, I couldn't even think that of you. Really, it's not your style. I respect very much your opinions since you probably know more about foobar than most users here. So don't worry, we are just discussing. 
You're being much too kind. I just post more than most people.

Besides, if that UI element was an evolution of Facets (a sub-component of Facets, or a component made to function with Facets), there would be another advantage : the results could be displayed not only according to the currently playing song, but also according to the result of any facets search. Imagine I type the name of an artist and the name of a song. Facets finds me the song I'm looking for... but in another facet, it also shows me all versions of the same song by other artists. And I suppose there are lots of other possibilities.

I think that'd probably be kind of confusing for most people, but yeah, I could see how that would be useful.[quote author=q-stankovic link=msg=603033 date=1228496951]But beside of that my main point
was the handling of multiple selections that would make possible a new way of navigation through the library - a way of browsing i didn't see so far in any program. (Edit: Beside of the artist relations node in Helium Music Manager)[/quote]I still don't understand this.

[quote author=q-stankovic link=msg=603033 date=1228496951]

Or, to be even more feature-overlap-thinking, you want foo_playlist_tree for the DUI

Yes and No.

No because i don't want to see/use never ever such an component again
Yes because PT contained some good features and they should'nt be offered by one component but could be reallocated among already existing or new components. I think many requests i made for album list, facets, library search or database search are inspired by PT's functionality
[/quote]Why not use the component that provides what you want?

I see this sort of attitude arounf here from time to time and I never understand it. 
elevatorladylevitateme

Show tracks with same title as the currently playing

Reply #24
[quote author=q-stankovic link=msg=603033 date=1228496951]

Or, to be even more feature-overlap-thinking, you want foo_playlist_tree for the DUI

Yes and No.

No because i don't want to see/use never ever such an component again
Yes because PT contained some good features and they should'nt be offered by one component but could be reallocated among already existing or new components. I think many requests i made for album list, facets, library search or database search are inspired by PT's functionality
Why not use the component that provides what you want?

I see this sort of attitude around here from time to time and I never understand it. 
[/quote]


I use what i use and for same searches i use database search. What i meant in the quote is following: There are 3 things that i loved in Playlist Tree:

1. Opportunity to combine a query/subset of library with the most suitable view.
2. Organisation of static and smart playlists
3. Showing subsets of your library linked to now playing track (what we are talking about here)

And yes, i would love to see that in Album list (1.), Facets (1.), Library search (a part of 2.) and Database search (3.). Concerning the attitude you mentioned: Beside of the fact that i am using the DUI i stopped using PT long before the new DUI was introduced because the author of that plugin wasn't able or willing to improve usabilty of its function monster and to remove its bugs. Instead of that he implemented as workaround the usage of an programming language. I hope you understand what i mean with "i never want to see such a component". What i did in last 1-2 years was to request more functions for the already existing components.


"But beside of that my main point
was the handling of multiple selections that would make possible a new way of navigation through the library - a way of browsing i didn't see so far in any program. (Edit: Beside of the artist relations node in Helium Music Manager)"


I still don't understand this.



Try to imagine a tree wich starts in the first level with the display of artists and you opens a node -  the subitems are displaying similar artists or followers. (you can take a look in HMM) Do you see the difference?
The subitems doesn't show subsets of the parent node but are linking to other parts of your library.

 
SimplePortal 1.0.0 RC1 © 2008-2020