Re: Genre category now less convenient to use
Posted: Wed Jun 12, 2019 3:53 pm
Totally supporting Peke's idea!
The Music Manager for Serious Collectors
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.Barry4679 wrote: ↑Wed Jun 12, 2019 12:44 amWhat 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.
With examples I hope that now I have made things more clear, unless I made things more complicated/confusing
Thank you, but I am afraid that I just added more complexity for us to develop I never liked Statistical science
Queen is Artist from Album "A kind of Magic" For Compilation albums It would show all artist collaborating on that 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).
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?
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
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.
[Update] I wrote the above before I noticed this, in your latest post.Peke wrote: ↑Thu Jun 13, 2019 5:46 pmit 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.
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.
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.Peke wrote: ↑Thu Jun 13, 2019 5:51 pmHi,
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
Yes, Queen is the Artist. And in his sample Collection, he has:Queen is Artist from Album "A kind of Magic" For Compilation albums It would show all artist collaborating on that album.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.
So my understanding was that this should result in:[x] Years -> [Albums]
[x] Albums -> [Artist]
[x] Artist -> [Years]
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?)?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 depth1) 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
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"dmcritchie wrote: ↑Fri Jun 14, 2019 1:47 pmSo 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.
Yes, I agree with that bit of your post
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.
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]
OK, good. That's what I thought.dmcritchie -> Infinitive Subnodes are problematic
My preference would be for MM5 to silently stop adding subnodes to the tree if the subnode to be added would create a loop.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
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.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 ????
Firstly this, makes it look more complex than it needs to be, doesn't it?
Hopefully it would not look like that in the UI.
The user should be able to specify were to stop .. ie. the user specifies:
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.Peke wrote: ↑Sat Jun 15, 2019 4:23 pmEDIT: 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)
Yes, but we can work together to find and fix those ... but design limitations may persist for another 10 years until MM6