MediaMonkey forum

Posted: **Wed Jun 12, 2019 3:53 pm**

Totally supporting Peke's idea!

Posted: **Wed Jun 12, 2019 6:55 pm**

Hi,

Barry4679 wrote: ↑Wed Jun 12, 2019 12:44 am What does the function of the + control that you added to your proposal?

it allows the definition of an n-deep index? ... eg. Genre>AlbumArtist>Album, or Composer>Genre>Artist>Album

or it allows the creation of additional subnodes? ... eg. create Genre_2 which is Genre>AlbumArtist>Album, additional to Genre_1 which is just Genre>Album

I think that both would be desirable.

I was referring regarding that Berry proposal to add [+] column for the purpose of adding additional sub nodes to tree. Which I personally think would complicate things.

I changed initial mockup so that User can add additional Root Tree nodes and its subnodes per collection view (Similar to way how new columns are added to track/list view) instead of having list of all fields available to be seen as root nodes (current UI behavior).

The main reason for that is to make tree views more customized per collections (eg. Types as predefined collections) and make them much understandable as novice users.
Example:
Music Collection tree nodes -> All Tracks, Artist (and/or Album Artist if selected), Albums, Genres, Years, Rating, Classification, ...
Classical Music Collection tree nodes -> All Tracks, Artist eg. Performers, Composers, Conductor, Albums, Genres, Years, Rating, Classification, ...
TV Collection tree nodes -> All Series, Series, Season #, Genres, Years, Actors, Producers, Rating, Classification, ...

Why I removed Berry [+] is that it can be handled differently in the way that defined Root nodes Even if they are not shown (eg. enabled) would define how sub nodes are formatted and if they would allow more subnodes.

Example based on Music Collection, which have these root tree nodes:
[x] All Tracks
[x] Artist
[ ] Album Artist
[x] Albums
[x] Genres
[x] Years
[x] Rating
[x] Classification

For each root tree node you would be able to select additional sub node from defined Root nodes List (eg. NONE + List of Root nodes enable or not).
This is How I would set my Music Collection Tree nodes:
[x] All Tracks -> [None]
[x] Artist -> [Years]
[x] Album Artist -> [Albums]
[x] Albums -> [Artist]
[x] Genres -> [Album Artist]
[x] Years -> [Albums]
[x] Rating -> [None]
[x] Classification -> [Artist]

That setting in multiple Subnodes showing and my tree node browsing more Dynamic.
Album Artist Root Tree node used as starting point:
Queen -> A Kind Of Magic -> Queen -> 1986
Same result Using Years as starting point:
1980s -> 1986-> A kind of Magic - Queen -> Queen (In case that on that album Queen had collaborations with other artists like John Stuart or Feargal Sharkey then they would also be listed and I would be able to right click to FIND MORE FROM SAME ARTIST to expand my knowledge of that collaborating artist)

Adding Double Node definition like you said Genre 1 and Genre 2 with different subnodes would most likely confuse regular users even I see it can be useful, but I (personally) doubt that most users would constantly use same thing in two different ways all the time and you would end in duplicate tree nodes cluttering UI (personal opinion).

dmcritchie wrote: ↑Tue Jun 11, 2019 3:03 pm This seems to be contradicting how the Composer->Genre->Artist example works.

Can you clarify?

With examples I hope that now I have made things more clear, unless I made things more complicated/confusing

Graves wrote: ↑Wed Jun 12, 2019 3:53 pm Totally supporting Peke's idea!

Thank you, but I am afraid that I just added more complexity for us to develop

I never liked Statistical science

Posted: **Thu Jun 13, 2019 12:23 pm**

Hi Pavle,

I think I get the idea from your examples, but with the tree nodes set as you have them, I don't see how you got:
1980s -> 1986-> A kind of Magic - Queen -> Queen
I don't see how you got the last "Queen" in that list.

But that aside, I can see a couple of potential problems with this approach.
1) These tree node links will often be circular, so you would get something like:
Queen -> A Kind Of Magic -> Queen -> 1986 -> A Kind Of Magic -> Queen -> 1986 -> etc...
So depending on how and when you populate the nodes and subnodes, you would need to prevent MM from getting into an infinite loop. Assuming that's not a problem, there is still the fact that in this example every subnode will be expandable (i.e., be prefixed by a "+"). So there would be no "last" node, which is a bit inelegant.

One solution to this would be to add a depth column to this dialog box (similar to what Barry calls Show in Media Tree), which would indicate the number of subnode levels you would want to see. So for example, you would set the node row "Album Artist" depth=2, and then only get:
Queen -> A Kind Of Magic
If depth were set to 4, then you would get:
Queen -> A Kind Of Magic -> Queen -> 1986

2) The other issue I see is that if I wanted (Barry's example):
Composer -> Genre -> Artist -> Album
But also wanted:
Genre -> Album Artist -> Album
I would be unable to have both since I would have had to pick one subnode for Genre (either Artist or Album Artist).
This could be remedied if the new "+" option to add an additional tree node allowed an existing tree node to be added a 2nd time. The one entry could have Artist as its subnode, and the other could have Album Artist as the subnode.
Then the way to prevent confusion when chaining together the nodes for:
Composer -> Genre -> Artist -> Album
would be for Genre -> Artist to be deselected for that tree node.
I.e., there could only be at most two instances of the same tree node type, and one would have to be selected and the other deselected.
This would still be somewhat limiting since someone could want to use a type in more than two ways: e.g., Artist -> Years, Artist -> Album, Artist -> Genre. But more flexible than what exists today, though perhaps not very intuitive.

Dennis

Posted: **Thu Jun 13, 2019 5:46 pm**

dmcritchie wrote: ↑Thu Jun 13, 2019 12:23 pm I think I get the idea from your examples, but with the tree nodes set as you have them, I don't see how you got:
1980s -> 1986-> A kind of Magic - Queen -> Queen
I don't see how you got the last "Queen" in that list.

Queen is Artist from Album "A kind of Magic" For Compilation albums It would show all artist collaborating on that album.

1) Like in above There would be no need for depth as If You double click on Artist Queen to list all queen tracks it should Auto Switch to Artist -> Queen tree node cutting it back to 2 depth

2) I agree, but it complicate things and you can easy be lost what is what and what you want and at one point you can think that it is bug where it is not, also it posses potential higher risk of bugs and regressions and it is harder to maintain code. Such cases and customization is better left to addons like Magic Nodes where more advanced Tree nodes can be directly inserted into collection. Only Possible way I can think is to allow Adding multiple Root Definitions with ability to set Title for each root node (Forcing unique name for each root tree node in order to not confuse them in Dropdown list). But again it could possibly make more problems that it would fix (eg. like in DLNA browsing, Synchonizations, ...). Not even to talk about speed implications.

2a) I guess that

dmcritchie wrote: ↑Thu Jun 13, 2019 12:23 pm Composer -> Genre -> Artist -> Album
But also wanted:
Genre -> Album Artist -> Album

was meant for different collections and you can set that for each collection. Also based on many user feedback and personal experience Album artist is neglected a lot and often wrong or unusable (I have 2k+ Albums that are compilations and Album Artist is Various).

dmcritchie wrote: ↑Thu Jun 13, 2019 12:23 pmThis would still be somewhat limiting since someone could want to use a type in more than two ways: e.g., Artist -> Years, Artist -> Album, Artist -> Genre. But more flexible than what exists today, though perhaps not very intuitive.

If you agree 1 has higher priority than 2 which largely depends on user preference and few more clicks, but it is undoubtedly still very useful and add additional level of freedom?

Posted: **Thu Jun 13, 2019 5:51 pm**

Hi,
I just noticed that MM5 Albums Tree node do not Have Album Artist in parentheses like in MM4 added as https://www.ventismedia.com/mantis/view.php?id=15744 allowing me to detect and correct Compilation Albums

Posted: **Fri Jun 14, 2019 4:26 am**

Peke wrote: ↑Wed Jun 12, 2019 6:55 pm Adding Double Node definition like you said Genre 1 and Genre 2 with different subnodes ...

I was suggesting a facility to add sub-nodes, not nodes ... and I wouldn't name them genre 1&2, as I did in my mock-up ... something meaningful like this

- MyCustomerNode (or any predefined nod, Music etc)
...... + Genre by Album Artist
.......... + Rock
................ + Roxy Music
.......................+ Stranded
...................... + Country Life
................ + Ry Cooder
......................+ Boomer's Story
...... + Genre by Album
.......... + Country Life
.......... + Boomer's Story
.......... + Stranded

Peke wrote: ↑Wed Jun 12, 2019 6:55 pm would most likely confuse regular users even I see it can be useful, but I (personally) doubt that most users would constantly use same thing in two different ways all the time and you would end in duplicate tree nodes cluttering UI (personal opinion).

I don't think that it would confuse "regular" people, because the sub-nodes would only exist if you had the Gold version, and then only where|if you explicitly created the new sub-nodes because you wanted them.

Not too much clutter as the user would only enable these extra sub-nodes in the collections where they would be useful ... ie, just like in your example in an earlier post.

In my case it makes sense to me in the Classical node ... ie. I have 200 albums containing tracks by Beethoven, sub-divided into 5 different genres ... but other composers need less assistance to navigate ... eg. Chopin; although he has around 50 albums, they are nearly all in just one genre. ... I would create my own Composer>Genre>Artist>Album sun-node, as well as Composer>Artist>Album, and also Composer>Album ... ie. one for each Use Case.

I think that your limited suggestion would make a meaningful addition to the Gold edition, by allowing us to customise our own navigate-by-click paths for default sub-nodes ... And it would be even better if we could add our own sub-nodes.

Peke wrote: ↑Thu Jun 13, 2019 5:46 pm it complicate things [snip] also it posses potential higher risk of bugs and regressions and it is harder to maintain code. Such cases and customization is better left to addons like Magic Nodes where more advanced Tree nodes can be directly inserted into collection.

[Update] I wrote the above before I noticed this, in your latest post.

It may not cause these problems ... I would think that the MM4 experience of adding the new nodes for video media, like Producer, Director etc, would have taught them to generalise the sub-node selection logic.

And there will be no Magic Nodes for MM5 ... correct?

Peke wrote: ↑Thu Jun 13, 2019 5:46 pm Not even to talk about speed implications.

It depends how it is implemented. If you followed my suggestion of implementing via the Column Browser, there would be zero speed or resource implications, because a hand built Column Browser is already doing exactly this.

ie. using my worst case, this Composer>Genre>Artist>Album path, if the Media Tree node is restricted to open just 1 level (Composer). then that multi-level index is just this https://www.dropbox.com/s/ecyyrtbvff6h6 ... d.png?dl=0 ... ie. it already goes, and speed is great

The difference would be:

where a customised sub-node has been defined with a multi-level index, you would put a Column Browser panel into the top of the sub-node's Grid view ... so the Media Tree would handle the top level index, and the inbuilt Column Browser would handle the rest

The user would set it up, just once, using the Edit Collection facility as a wizard

They can do it without knowing how to drive the Column Browser or Contextual Search ... ie. your casual or notice user

and the user has it ready to go whenever they open that customised sub-node

What is there not to like about it? ... you would have a powerful and user configurable navigation-by-clicks facility, which MM5 is lacking in my view ... ps. and I would like a response to the feedback in that post

Peke, I would like to thank you for opening up, and participating in, this wish-list dialogue.

Peke wrote: ↑Thu Jun 13, 2019 5:51 pm Hi,
I just noticed that MM5 Albums Tree node do not Have Album Artist in parentheses like in MM4 added as https://www.ventismedia.com/mantis/view.php?id=15744 allowing me to detect and correct Compilation Albums

How do you use this Media Tree info to detect this compilation album issue? ... I am imagining something fair laborious .. shouldn't they be a FilesToEdit sub-node for whatever you are trying to do? ... but adding the (Album Artist) tag back into the Albums node is a good idea.

Posted: **Fri Jun 14, 2019 10:01 am**

Still with Peke.

OK, there MIGHT be one or even two occasions, where it'd be neat to have another sub-node for i.e. [Year]s in one node than in all the others…
But with Peke's tool you could still realize it by adding another Collection.

I also think, non-IT-engineers might get lost easily in your suggested system. Especially with looping enabled!
And I'm also very sure it'd be much more costy - to have Collections with 1 - n nodes EACH, again having 1 - n child nodes EACH, without any recursion??
Plus I just couldn't be bothered to do all the configuration needed in your system to eventually have the ONE LITTLE CHANGE I'M AFTER:

I want to see [Album Artist]s list in Grid View when expanding a [Genre], and [Album]s shall be listed under an Artist.
That's it!
And I'm certain, most People wouldn't want to Change quite much more than that.

So:
Your way: takes ages, confusing, hardly reusable, costy, and not L8-save at all IMO

Peke's way: easy, probably much faster, globally applicable, in one word: elegant =)

GO FOR IT PEKE!

Posted: **Fri Jun 14, 2019 1:47 pm**

Well, my problem - based on @peke's and @graves' feedback - is that I apparently don't quite understand how Pavle's proposal works. I thought Pavle's rules were:

1) Only selected tree nodes are shown as level 1 nodes in a collection.
2) Selected tree nodes link to the associated subnode (if not None).
3) The associated subnode links to the corresponding tree node (whether selected or not).
4) The corresponding tree node links to its associated subnode (as in 2).
5) Repeat steps 3 and 4 until you encounter a subnode set to "None".

I'm guessing that something in the above description is not what Pavle intended, because:
1) @peke wrote in response to my question:

I don't see how you got:
1980s -> 1986-> A kind of Magic - Queen -> Queen
I don't see how you got the last "Queen" in that list.
Queen is Artist from Album "A kind of Magic" For Compilation albums It would show all artist collaborating on that album.

Yes, Queen is the Artist. And in his sample Collection, he has:

[x] Years -> [Albums]
[x] Albums -> [Artist]
[x] Artist -> [Years]

So my understanding was that this should result in:
1980s -> 1986-> A kind of Magic - Queen -> 1986

So I apparently am misunderstanding how the proposed Collection design works.

2) @peke wrote also in response to my comment:

1) These tree node links will often be circular, so you would get something like:
Queen -> A Kind Of Magic -> Queen -> 1986 -> A Kind Of Magic -> Queen -> 1986 -> etc...
... in this example every subnode will be expandable (i.e., be prefixed by a "+"). So there would be no "last" node, which is a bit inelegant.
One solution to this would be to add a depth column to this dialog box
1) Like in above There would be no need for depth as If You double click on Artist Queen to list all queen tracks it should Auto Switch to Artist -> Queen tree node cutting it back to 2 depth

I don't understand this either, since in the sample Collection definition, Artist is linked to subnode Years; So how does it "auto-switch" and cut back to a depth of 2 (meaning Artist and Years?)?

So where I'm picturing an ever expanding tree of potentially infinite depth, @peke and @graves see something else. So I'm unable to comment further on the proposal at this point since I seem to have a fundamental misunderstanding of it.

Maybe I'm the only one that doesn't "get" it, but I could use some additional clarification. This is probably a case where a picture (or video) would be worth a thousand words.

Dennis

P.S. As far as my suggestion to allow 2 definitions of the same tree node, I was not implying that this would make for a good interface. Rather, I was trying to remedy what I saw as a shortcoming of Pavle's proposal (i.e., that a node type could only link to one subnode type within a Collection) without significantly altering the interface he was proposing. I would not recommend doing this way, but I think it is important not to 2nd guess and thereby limit how users are going to want to structure their tree. While it is no doubt a minority of users, there are surely many users of Magic Nodes who will be disappointed with MM5 if they can't get most of what they were able to define in MM4.

Posted: **Sat Jun 15, 2019 6:15 am**

dmcritchie wrote: ↑Fri Jun 14, 2019 1:47 pm So where I'm picturing an ever expanding tree of potentially infinite depth, @peke and @graves see something else. So I'm unable to comment further on the proposal at this point since I seem to have a fundamental misunderstanding of it.

Maybe I'm the only one that doesn't "get" it, but I could use some additional clarification. This is probably a case where a picture (or video) would be worth a thousand words.

I can't clarify everything, but I don't think he was implying recursion, by his example of "Queen -> A Kind Of Magic -> Queen -> 1986"

I think that just refers to [AlbumArtist]->[Album]->[Artist]->[Year]

He lost me with the ->[Year] part, but I don't think that he was implying anything recursive by the "Queen->A Kind Of Magic->Queen" part.

A better example may have been something like "VariousArtists->Forest Gump OST->Elvis Presley" ... ie. that soundtrack album has an Elvis track

Graves wrote: ↑Fri Jun 14, 2019 10:01 am GO FOR IT PEKE!

Yes, I agree with that bit of your post

The key request being made is to be able to create a multi-level index for the sub-nodes ... eg. Composer>Genre>Artist>Album instead of just Composer>Album.

I cherry picked a few phrases from your post:

looping ... recursion

I just couldn't be bothered to do all the configuration needed in your system

costy

globally applicable, in one word: elegant

I don't think that anybody is suggesting recursion ... I think that is a misunderstanding, see above

IMO the configuration is a simplification when compared to case-by-case navigation ... I am happy with Peke's mock up btw ... I think that my suggestion was clearer (ie. exactly where the extra index level was to be inserted) ... but his is OK too

Depending upon how it is implemented it could have zero resource cost ... ie. my suggestion was to leave the Media Tree as a single level index, and use the already existing Column Browser facility for the lower levels ... see this example for the Genre>AlbumArtist>Album example you mentioned ... the same thing could also handle nodes with a deeper index .. https://www.dropbox.com/s/53dlgebhmtbon ... 4.png?dl=0 ... I was suggesting that if the sub-node index was 2 deep, that a Column Browser panel be built into the sub-node's Grid view

I can't see why the suggestion isn't globally applicable ... btw. as you probably noticed, my illustration above was from MM4 ... that is because MM5 is currently a little deficient in the "globally applicable" and "elegant" areas ... ie. you can do that in MM4 ... and you can do it in MM5, in most sub-nodes, but not the Genre sub-node ... see half way down this post here; http://www.mediamonkey.com/forum/viewto ... 33#p459333

Graves wrote: ↑Fri Jun 14, 2019 10:01 am OK, there MIGHT be one or even two occasions, where it'd be neat to have another sub-node for i.e. [Year]s in one node than in all the others…

I am the same ... I just have a couple of situations where this would be useful ... and I can workaround with the Column Browser anyway, so I wouldn't be heart-broken if it wasn't delivered.

But don't you think that it is kind of lame that in a once in a decade, complete rewrite of MM, we can't create User sub-nodes. ... I think that it is worth asking for, just to handle each of our "one or even two" situations.

But like you, I think that the main thing is being able to configure the existing nodes.

Posted: **Sat Jun 15, 2019 6:23 am**

Well, from that POV, I agree.
Maybe a 2-level configuration dialogue (basic/advanced) might make sense

Posted: **Sat Jun 15, 2019 4:23 pm**

Hi,
If need is arised I could try to make Video file of a mockup showing the behavior, but to add additional confusion you all three are correct.
eg:
dmcritchie -> Infinitive Subnodes are problematic and I try to find a way to prevent that, but on other side to allow users more control
Graves -> ATM point is to open that part of MM5 to future improvements and updates. For MediaMonkey 2-4 (eg 15 years) it was not in design at all, but scripts filled the gap
Barry4679 -> You put a better example and you are correct let me try to quickly Visualize:

Code: Select all

[x] Years -> [Albums]
[x] Albums -> [Artist]
[x] Artist -> [Years]
[x] Album Artist -> [Albums]

So = [Years]->[Album]->[Artist] /x/ [Years] There is no point to open new sub views as it will introduce loop and/or no tracks listed but It could be made that Some action like double click on that node or expanding it would Directly Move Tree focus to other tree Root -> [Artist] -> [Years] (????) where you can actually continue browsing using tree nodes ????

Another example I wanted to present with same result  [Artist]->[Years]->[Album]->[Artist] /x/ [Year]

And Finally Berry example [Album Artist]->[Album]->[Artist] /x/ [Year]

1990s
- 1994
  - Forrest Gump: The Soundtrack
    - Elvis Presley
    - Duane Eddy
    - Wilson Pickett
    - Aretha Franklin
  - The Collected Recordings (Sixties To Nineties)
    - Tina Turner

Tina Turner
- 1994
  - The Collected Recordings (Sixties To Nineties)
    - Bryan Adams
    - Eric Clapton
    - Ike Turner
    - Rod Stewart
  - The Best Singles

Various Artists
- Forrest Gump: The Soundtrack
  - Elvis Presley
  - Duane Eddy
  - Wilson Pickett
  - Aretha Franklin

Finally after all that all the bugs we made would be coming

All that is basically what I thought about adding Subnode selection. Only thing I am not clear where to stop/limit or simply do not show subnodes if only one value is available?

Suggestions?

EDIT: To simplify things Browsing thru tree nodes it would be more like if you use only Track View in MM4 and navigate using only by Right Click -> Find More from same -> ... so now I am wondering if actually Find More from Same should be actually list of subnodes

instead of defining custom subnodes as it would , limit subnodes to 3 but would allow further browsing to available metadata and most likely simplify development (I think)

Posted: **Sun Jun 16, 2019 8:41 pm**

dmcritchie -> Infinitive Subnodes are problematic

OK, good. That's what I thought.

and I try to find a way to prevent that
So = [Years]->[Album]->[Artist] /x/ [Years]
There is no point to open new sub views as it will introduce loop and/or no tracks listed
Only thing I am not clear where to stop/limit
Suggestions?

My preference would be for MM5 to silently stop adding subnodes to the tree if the subnode to be added would create a loop.
E.g., user defines a Collection as follows:

[x] Years -> [Albums]
[x] Albums -> [Artist]
[x] Artist -> [Years]

1) MM5 internally starts creating a tree with Years -> Albums.
2) Checks to see if there is a node called Albums. If not, then tree is complete.
3) If so, checks if it's subnode (Artist) is already present in this tree. If it is, then tree is complete.
4) If it is not, adds it to the tree, and repeats step 2 for a node called Artist.
5) Repeats step 3 for subnode Years. In this case, it is present, and tree is complete.

Given the above Collection definition, in addition to the Years tree, MM5 would also create an Albums tree and an Artist tree.

Since MM5 is building these trees dynamically, developers could choose a linked list to represent them. In that case, and given the short length of most lists (2-4 nodes), it would be quite efficient for MM5 to quickly check each node in the list being currently built to see if adding the new entry would create a duplicate entry.

If done this way, the last node of any tree would not be assigned a "+" or arrowhead next to it, since it would not be expandable.

but It could be made that Some action like double click on that node or expanding it would Directly Move Tree focus to other tree Root -> [Artist] -> [Years] (????) where you can actually continue browsing using tree nodes ????

I think I would find this suggestion confusing to use. I would be working my way down the tree by expanding or double-clicking, and then find myself somewhere else. If it is implemented, I think I would like the option to disable it.

Overall, I like the design as it would allow me to create trees as I like them. The main limitation, as I mentioned in an earlier post, is that you can't use the same type (say Genre) with two different subtypes in the same collection. But since you can create multiple collections, then this may be sufficient for those with specialized needs such as Magic Nodes users.

Dennis

Posted: **Mon Jun 17, 2019 1:12 am**

Peke wrote: ↑Sat Jun 15, 2019 4:23 pm Suggestions?

Firstly this, makes it look more complex than it needs to be, doesn't it?

Peke wrote: ↑Sat Jun 15, 2019 4:23 pm
Code: Select all
[x] Years -> [Albums]
[x] Albums -> [Artist]
[x] Artist -> [Years]
[x] Album Artist -> [Albums]

Hopefully it would not look like that in the UI.

See the red box in my original amendment to your mock up ... it shows a multi-level navigation access path for the Composer sub-node; ie. Composer>Genre>Artist ... hopefully it will look like simple like that.

Peke wrote: ↑Sat Jun 15, 2019 4:23 pm Only thing I am not clear where to stop/limit or simply do not show sub-nodes if only one value is available?

The user should be able to specify were to stop .. ie. the user specifies:

whether a specific sub-node has any lower sub-nodes

and if yes, then how many nested levels there are

and there should be a sensible default values (as at present)

I have never installed the MM5 script to repopulate the Media tree nodes, so I need to refer to MM4 for this illustration:

In MM4:

the Album sub-nodes are 1 deep ... >Album

the AlbumArtist sub-nodes are 2 deep ... >AlbumArtist>Album

the Genre sub-nodes is 3 deep (for AlbumArtists)... >Genre>AlbumArtist>Album

In my suggestion, the user could specify the number of levels using my (badly named) "Show in Media Tree" column that I had on the above diagram. Examples:

Genre sub-node, the user specifies Genre>Artist>Album, with "show in Media Tree" = 0 ... result, for the Genre sub-node, would have no sub-nodes in The Media Tree (ie. like MM5 vanilla now) .... and its Grid view would have a Column Browser panel embedded at the top of the screen, with column1=Genre, and column 2=AlbumArtist, and column 3=Album

Composer sub-node, the user specifies Composer>Genre>Artist>Album, with "show in Media Tree" = 1 ... result, Composer sub-node, would have 1 (Composer) subnode in the Media Tree .... and its Grid view would have a Column Browser panel with column1=Genre, and column 2=Artist, and column 3=Album

ie. the MM5 "Edit Collection.." config dbox is acting like a config wizard ... eg. the user defines a 3 deep path for a node ... MM5 defaults the Show in Media Tree" depth to 0 ... and MM5 by default, is going to deliver the navigation-by-clicks levels via the inbuilt Column Browser panel, because that is the most efficient (ie. like MM5 vanilla now) .... the user can then decide whether to show sub-nodes in the Media Tree (like in MM4 at the moment) ... and the user can also decide where to set the balance between these two approaches.

Peke wrote: ↑Sat Jun 15, 2019 4:23 pm EDIT: To simplify things Browsing thru tree nodes it would be more like if you use only Track View in MM4 and navigate using only by Right Click -> Find More from same -> ... so now I am wondering if actually Find More from Same should be actually list of subnodes instead of defining custom subnodes as it would , limit subnodes to 3 but would allow further browsing to available metadata and most likely simplify development (I think)

I was not attracted by your double click mechanism to switch navigation routes ... I think that what you were suggesting. ... anyway "Find More From Same" is a better way of handling that requirement.

This also raises an interesting point ... I had forgotten about "Find More From Same" ... I don't ever use it .... but I should.

I use MM all day, every day ... it is the 1st thing I open when I boot my PC in the morning.

Yes, "Find More From Same" is available via right click, if I know|remember that it is there ... I think that will be great if an effective navigate-by-clicks mechanism is also added to MM5 as we are all suggesting in this thread ... to be effective in all cases it needs to user configurable ... ATM the moment the MM5 designers have tried to predict my requirements out-of-the box, and this is not working (for me at least)

Peke wrote: ↑Sat Jun 15, 2019 4:23 pm Finally after all that all the bugs we made would be coming

Yes, but we can work together to find and fix those ... but design limitations may persist for another 10 years until MM6

MediaMonkey forum

Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use

Re: Genre category now less convenient to use