I tag artists I want to keep with “Keep (Artist)” and albums I want to keep with “Keep (Album)”. I’ve got a few bookmarks that operate on those, to help me identify artists and albums I want to check out in more detail.
There’s one bookmark I can’t make work though: and that’s an artist query “Keep (Artist)” + “Keep (Album)”.
Those ones are particularly of interest to me because I have identified the artist as one I want to keep around, and one of their albums as one I want to keep around, so there’s a good chance I want to check out their other albums in more depth.
I don’t know Roon’s thinking, but in other contexts it has been well known that approximately 769 million people in the U.S. and Europe don’t understand Boolean well enough to benefit from it, just enough to get in trouble and complain.
Anders, the links are available when on local machine to the music and you open track details; thus my point was that a link to the folder would/should have been easy to implement, no? It’s never been the case that the links have been provided when using a remote device.
This ship has sailed. I don’t think Roon will implement this in any case, so squabbling about it now is not going to make a jot of difference
James_I
(The truth is out there but not necessarily here)
47
There needs to be a Roon forum hall of fame. This would be my first nominee!
James_I
(The truth is out there but not necessarily here)
48
Perhaps roughly the same number of people that don’t care enough about music to implement a tool like Roon
Seriously, there are ways to use the logic without it feeling like writing an equation or formula. Foobar displays them as filters and it works very, very well. The ability for a true AND focus using 2 or more Roon Tags would be very powerful and useful.
I have a group of artists in a playlist but don’t want to hear the Christmas albums of all these people. Is the a way to filter OUT The word Christmas?
The point of a UI is to translate a natural language query into an IT query: i.e. “find all bands from France and Italy” will be executed as (using SQL here for facility)
select bands from library_tbl where (country = France) or (country = Italy);
Simple and not an unreasonable request, especially since a this is a kind of query most people use countless times in real life.
But what people want in this thread is to also have the option of specifying that “chamber and jazz” (AND) would translate differently from “opera and choral” (OR). That’s what I fear is difficult. Let alone “choral and voices but not Christmas” (does “not Christmas” apply to choral as well as voices?).
Not patronizing you — you could accuse me of patronizing the other guys. My point is to try to convince you guys that you are exceptions, much smarter and well-educated (in this specific area) than most people. Obviously without the slightest success.
Is that really AND? Are there edge cases? What if they don’t have fries?
Reminds me of my favorite Boolean joke for frazzling 10-year-olds:
“I’d like a hamburger without pickles.” “We’re out of pickles, but you can have one without bacon.”
I can see your philosophy on this @AndersVinberg. I worked in research for 30 years, and there is a recurring dilemma “The data here are too complicated to figure out, so don’t collect the data.” The concern was two-fold: 1) the area IS too complicated so collecting data you can’t use IS a waste of time , 2) people will make bad decisions because they don’t know how to use the data.
My philosophy was, collect the data (when easy to do) and then it’s our responsibility to ensure people know how to use it. I wanted every chance I could to make the best decision possible.
As you clearly state, this could trip up a lot of people. It seems to me you need to be actively thinking about how to use Roon to get the most out of it. But you can still use it pretty effectively even if you don’t care about details.
In this case, some extra education on how to use the tool with well-chosen examples could get most people where they need to be.
Probably off the thread here, but it does seem that where people run into issues with Roon is where they try to do something ‘on the fly’ without the right information. And they either get frustrated or make a bad decision that has to be undone.
So much of Roon’s information is separated from the use context. There is the KB that people may not know about or aren’t reading, then there is a TON of uncurated information buried in the Forum that you might be able to find if you search.
Maybe for the trickier cases one could employ the context sensitive help bubble to aid in use.
Maybe I’m just a visual guy, but what if you could present the selections (tags) as a Venn diagram? Then, the user clicks on the areas (intersections) they want? So if you have Choral music, Lute music and Christmas music tags, you could just click on the single section with Choral Lute Christmas music?
No ambiguity there, but the software would figure it out and do the search. If you wanted only Choral Christmas Music but doesn’t have Lute music alone you could click several areas to get that selection (as many as six sections) or just unselect the section that is Lute alone. You don’t have to understand Boolean for it. It’s careful coding.
I’m not smoking anything, and yes I’ll stop now…
Select burger from burger_type_table where (ingredient_1 =patty) and (ingredient_2 = bun) and (condiment_1= mustard) etc…
Which is why your joke is a misapplication of Boolean logic.
A well-designed UI will catch these kind of exceptions (i.e. ther are no fries) and will return only steak with an explanation.
A lot of Roon users wish for implementation of Boolean logic in parts of the software where Boolean logic should have been implemented from the start, be it with tags, genres or the - still appallingly bad - search function. I don’t think anyone wants to input a boolean query. They just want to tell the software that it should perform a Boolean query with the given parameters. It is up to the developers to design an interface that allows this. This is not an unreasonable request and it certainly isn’t the software equivalent of rocket science.
Most cataloguing software - of whatever kind - lets users specify search boundaries (or filters if you like) before the search is executed. Good software that wants to present a simple search (filter, focus, call it what you like) as a first interface option, includes an “extended” expansion to the interface where Boolean operators are still hidden from the user and are replaced by extension like “include this”, “exclude that”, “specifically this order of words” and so on. It really isn’t that difficult and it would greatly improve the efficacy of the retrieval process (this is true for SQL and NOSQL queries alike).
NONE one of the points I have raised have made any impact on anybody.
So I’m a fool, and the programmers at Amazon and Google and Microsoft Bing and New York Times and Tidal and Spotify and Economist and…
No you’re not. I understand your point more as I thought about it @AndersVinberg .
Point 1. The fraction of users needing this is small compared to the overall user base.
Point 2. Modern search algorithms done with the tools you cite yield a better user experience and equivalent results.
At least that was my take. And I find this compelling. Your point this is a business decision is something Roon needs to make. Certainly I’d rather have what I’ve got with Roon UI than what I had with JRiver.
So count me as malleable. Hope it was worth at least one pixel.
