I get to see how to use the filter function. But I am afraid it is not just a method question. But as you can read above, the fix mentioned in the last paragraph is still necessary in order to let the newly created genres function consistently with the existing Roon genres. This is because we can only assign a new genre to a group of albums with a specific tag, but not to a group of artists. Unless the latter part is handled automatically, it leads to the problem that the number counts of Artists (as well as the actual list of artists) in the new genres show incorrect.
Ok…am just trying to help here not argue with you.
What I posted answers your first para. With exactly the example you wrote.
I disagree with your second because you can see conditional filters working in the example I posted.
I don’t understand if the third is related or not.
Over to @brian …
I appreciate your effort to help. I’m just trying to explain what I see an inconsistency in the setting, which needs to be resolved. Either Roon absolutely does not allow a creation of a new genre, or there must be a way to assign a new genre to a group of artists in addition to a group of albums.
Cheers,
Roon genres and file genres deliberately behave inconsistently.
Roon has separate editorial decisions driving artist->genre links and album->genre links.
File tags only express track->X associations. So track->genre is what we are getting there. After a ton of discussion with users about this, we determined that it’s a baseline expectation of virtually everyone that genres extracted from file tags must inherit to album and artist in order to work right.
Our method is more powerful: we’re capable of expressing the idea that an artist’s Christmas album is “Christmas” without forcing them to be “Christmas” as well. Aside from holidays, “Children’s” and one-off international collaborations are common sources of inheritance pollution in other apps.
So, we’ve made some product decisions in this space. You may agree with them, or not, but in a world where genres are totally managed within Roon, they are either attached to albums or artists, and no inheritance applies.
There’s also a world of people with files that have carefully groomed track->genre assignments, and expect inheritance to work, because that’s what they’re used to. This is a legacy problem–we must support these people, and meet enough of their expectations to make Roon usable.
You’ll notice that by default, genres from files are hidden from the user experience–this is because of the impedance mismatch between our vision of how genres work, and the haphazard conventions that people working in a world of file tags have come up with over the years.
So, genres coming from file tags are inherited from track->album and album->artist. This is a legacy support requirement: if we simply imported track->genre mappings from files at the track level, they would live in a strange ghetto and not be as useful, and for people who choose to display file genres and hide Roon genres, the genre browsing experience would be ruined.
Genres coming from Roon and from manual edits do not inherit because our metadata model is capable of attaching them separately, and this makes it possible to handle many real-world situations with more nuance: we are able to separately associate genres with artists and albums, and we don’t want to take that power away from our users simply because the legacy solution wasn’t as evolved.
@brian, thanks for your detailed explanations, which I honestly cannot fully understand. I still wonder - when you allow users to create a new genre and link it to albums, why don’t you do the same to artists? That is exactly my last point. I want to be able to associate a new genre to a group of artists in addition to a group of albums, filtered by a specific tag.
The simple answer: because sometimes it’s the wrong thing to do.
Just because John Coltrane recorded “Greensleeves” doesn’t mean he should be assigned the genre “Christmas”.
If album-level genre assignments propagated to artists automatically, we would lose the expressive power that allows an artist to have one “Christmas” album without being considered a “Christmas” artist.
If you think that a genre assignment should apply to both an album and the album’s artist, you can edit the album and artist separately to include it.
@brian. Fine with that. Just allow me to edit the artist part. I don’t know how to do it. I don’t want to manually find all artists belonging to my new genre and edit one by one.
We don’t have batch editing for artists yet 
It’s in the roadmap.
Good. Make sure it is included in the next version release. I will hold my breath for it…
@brian, sorry I can’t seem to have enough on this subject, but seriously, the fact that Roon handles the genre->artists and genre->albums links independently allows an opportunity for better. For example, when I first click Genres and select Rock, then the list of artists and albums are shown. When I then click Metheny, then only his rock albums are displayed. If I started with Artists and click Metheny, all his albums show up. To avoid confusion, on the top corner of the screen it can indicated that I am at the Genres -> Artists hierarchy in the browsing.
Note that this can be done at the browsing level (hence local to each client), and the inheritance does not have to be hard-wired in the metadata of each track.
I always thought that Albums can never be at the same level of browse hierarchy as Artists, as the former is much larger in number than the latter. I hardly ever start my search with Albums. It’s usually either Artists or Genres to downselect the next level of the search hierarchy.
Usually for the rock/jazz, it is like Genres -> Artists -> Albums, or directly to Artists -> Albums. Roon can simply allow to distinguish the two processes by conditioning the search and displaying this properly.
Likewise, for classical music the usual mode is Genres -> Composers -> Performers -> Albums, Composers -> Performers -> Albums, or just directly Performers -> Albums. Or sometimes Performers -> Genres -> Albums. A great advantage of the Roon metadata system is that any of the above search can be tailored easily (by making the search conditional under the above level of hierarchy.
Does it make sense? I think this will be cool and will make a lot of users with a large collection very happy.
It makes sense, but I want to encourage you to think a little bit bigger. These problems are problems of philosophy, not product 
You’ve named some navigation patterns that are common in the world–you described them clearly, and I get it. It’s how a lot of software approaches the problem. Rigid hierarchies like those are easy to build, and come with a set of limitations. Software like this is what motivated us to do better, and sometimes better means different.
Roon’s navigation model is not hierarchical, because the real world is not hierarchical. Roon’s goal is to model music in real life, filtered through the lens of content that you have access to.
Navigating in Roon is explicitly designed not to be hierarchical. Instead, it’s graph-based. This is like the difference between navigating a library using the dewey decimal system and navigating the internet.
(When I use the term graph, I’m using it in the mathematical sense–nodes connected by edges)
So we have a bunch of nodes–these can be albums, artists, tracks, works, performances, places, countries, forms, instrumentations, labels, genres, forms, roles, tags, or periods, and the nodes have relationships to each other.
When you’re viewing a screen in Roon, you are presented with navigation that takes you to each adjacent node in the graph. There is more than one way to get to a place, and more than one way to leave–this is fundamentally different than “drilling down” from genre->artist->album. The navigation is lateral and relationship-based.
So, there is no “up” nor “down”. Albums are not “below” artists–they are related to them via album-level credits. And on the artist screen, you’re not looking at a list of albums owned by an artist–you’re looking at a list of album->artist credits in reverse. A lot of hierarchical use cases are well accommodated by this model, but that’s a side effect, not the end goal.
Likewise, genres are linked to albums and artists independently for a good reason. Genres have hierarchical relationships to each other, but not to albums or artists–genres are related to those albums/artists instead. This means: a genre is just as much a way to describe and album as it is to categorize it. Neither node in the relationship is considered primary or secondary, or below the other.
The hierarchies in your examples are sane, but reductive–they are a small subset of what’s possible in the real world of music, which is the world we are attempting to model. In the real world, you can release a “Christmas” album without being known as a “Christmas” artist–if Roon were built around a genre->artist->album hierarchy, we would be unable to represent that situation–we’d be giving up expressive power.
This is a different way of thinking than you are probably used to. I think for most people, it eventually begins to feel liberating. In any case, I’m happy to discuss these topics.
You might also look at some of the things @AndersVinberg has posted regarding relationship-based navigation–I think he has explained it better, and in fewer words, than I have.
@brian, thanks again. The discussion has gone long enough. I will just say one more time and shut up.
I just want you to know that I am in line with you in your design principles. I am NOT suggesting rigid hierarchies. On the contrary, all I am asking is the user-customized browsing hierarchies along with conditional-filtering based on the hierarchies (for the lack of knowledge of proper terminologies). For example, going under Genres, I can see both lists of Artists and Albums. I can click Artists to see the filtered list of Artists belonging to the specific genre. Or I can click the Albums to see the filtered list of Albums belonging to the specific genre. Better yet, the user can design what categories appear under Genres browsing level. This way, what I see by clicking Genres -> Rock can look different from what I see by clicking Genres -> Classical.
As you said, no other software products with the conventional design can achieve this goal easily. Only Roon can offer such versatile capabilities, thanks to the independent category assignments. Since this does not interfere with any metadata in the core, as all it does is conditional/hierarchical filtering, this can be entirely local to each client accessing the same core library. This has been my dream while using iTunes, which is known to be poor in classical music browsing, and I saw the opportunity in Roon. I just hope that you will make it a reality.
Cheers,