Author Topic: Tag Hierarchy Explorer Panel - Wishlist/Ideas  (Read 349 times)

alec.tron

  • Hero Member
  • *****
  • Posts: 663
Hello hai,
now that we have a new Tag Hierarchy Explorer Panel in MB, might be good to detach it from the large thread where this started:
https://getmusicbee.com/forum/index.php?topic=8987.msg178058

And collect bits that relate to this new panel in its' own thread.

The few bits I would love to see at some point in the future still:
- configuration options
    - option to only show branches and/or groups that have files inside them, or associated children (with content/files)
    - option to show how many files sit in each branch/group [i.e. maybe just a number in  brackets like - in hierachy panel mock up view:
Code
Genres (123456)
    Blues (987)
        Delta Blues (654)
     maybe even trigger'able on the branch level so I on can decide on a per branch facet if/where this is important info...]


Also, @psychoadept and others active in the MB Wiki - would there be a space that would lend itself to storing and maintaining various mappings/txt files for others to use ?
I pasted a fair few in the above thread already, but forum is a tad limited for that, and would be nice if there was an agreed upon resource to store, collaborate on, and version these Tag Hierarchy Explorer Panel txt files.

Churs.
c.

alec.tron

  • Hero Member
  • *****
  • Posts: 663
Here's a set of 4 basic files (slight overkill to use github, but was readily available, and give me versioning easily if need be, plus collaboration options, if others have github accounts...):

Overview (if you are familiar with github)
https://github.com/alectron/MusicBee_TagHierarchies


Or, links to the currently existing 4 Variants, as raw txt contents (that you could paste into the panel directly), below:

--------------------------------------------------

Genres:
Discogs_Genres_Styles.txt
https://raw.githubusercontent.com/alectron/MusicBee_TagHierarchies/master/Genres/Discogs_Genres_Styles.txt

MusicBee_2Layer.txt
https://raw.githubusercontent.com/alectron/MusicBee_TagHierarchies/master/Genres/MusicBee_2Layer.txt

MusicBee_3Layer.txt
https://raw.githubusercontent.com/alectron/MusicBee_TagHierarchies/master/Genres/MusicBee_3Layer.txt

--------------------------------------------------

Instruments:
Instruments_Monash.txt
https://raw.githubusercontent.com/alectron/MusicBee_TagHierarchies/master/Instruments/Instruments_Monash.txt

--------------------------------------------------

c.


ps. also a tip - if you want to dive into this and merge/edit/re-construct these for your library/tags - as the MB Panel is all based on proper White-Space & Line-Indent formatting, I'd recommend to get a good text editor that is suited for this (i.e. my recommendations would be: NotePad++, Sublime, etc)
Last Edit: July 25, 2020, 03:24:18 PM by alec.tron

The Incredible Boom Boom

  • Full Member
  • ***
  • Posts: 165
Tagging genres would be a cinch if the hierarchy could tag recursively.

Code
Pop::Genre Category
    Pop::Genre
        Japanese Pop::Genre
            歌謡曲::SubGenre
            City Pop::SubGenre

Asia
    East Asia
        Japanese::Genre Category
            Japanese Pop::Genre
                歌謡曲::SubGenre
                City Pop::SubGenre

If you tagged <SubGenre> as "City Pop," MB would fill in <Genre> with Pop; Japanese Pop.

alec.tron

  • Hero Member
  • *****
  • Posts: 663
Tagging genres would be a cinch if the hierarchy could tag recursively.

If you tagged <SubGenre> as "City Pop," MB would fill in <Genre> with Pop; Japanese Pop.
Yes and no (imo).
This could probably be fairly easily done by script, if the Tag Hierarchy context were retrievable via api. But give it a bit of time, and it might come - this feature after all is only a few days old.

Also - some food for thought - what would you need redundant/recursive tag writing for ?
The one thing I had use for it would be to later consume the recursive context injected back into the file in auto playlists...
But, what IF Auto Playlists themselves could have rules written against the TagHierarchy context/relations ? Then you'd only need the the 'City Pop' tag, to get all the other tags & their handling for free...

So IF Auto Playlists were the need, then with the above, there'd no need to re-inject the tagHierarchy context back into tag metadata fields anymore...
Just a thought, and, might be you had something else in mind ?

Churs.
c.