Yes it does stuff like this within the current radio session.
Wow, I didn’t know that. Is that documented somewhere?
But it would only work if you thumb up or thumb down a song before it plays.
Why not allow a thumb up/ thumb down button before, during, and after the track plays? I don’t sit at the computer terminal indefinitely, sometimes I’m away from the computer for a few minutes doing something else while listening to the music (wow, I know, amazing right?).
Nope. That’s not what documentation is for.
It’s not a very good idea for anyone but the developers/product people working on Radio to develop deep intuition about what it’s doing under the hood. It’s an area of active development/change, and will continue to be indefinitely. If you build precise expectations about it, they will be broken, probably soon.
That is a reason why we are not going into deep explanations here about the underlying implementation, and also why we are not going to “bare the guts” of the algorithm to a bunch of sliders and make it tweak-able. The actual knobs on the inside would not make a good product or user interface, and they change too often to be a stable target for that anyways.
Another thing that’s super important to understand about “Radio 1.4” is that it represents only about 15-20% of our actual Radio project. Internally, I actually call what you guys are using now “offline mode radio”, since that’s how it fits into the bigger picture. I call it that because what you’re using right now is the algorithm that–in the future–Roon will use to do radio within the library when no internet connection is available.
“Radio 2.0”–the whole thing, not just this small piece of it–is intended to be a proper modern radio feature–radio that utilizes information about all of the content on Earth, not just your library, a la Spotify, Pandora, etc.
At this point in time, it’s not possible to do radio properly without relying on large data sets in the cloud. Yes, I know some people back in 2008 did cool stuff within a local library (Mirage, MusicIP, …), but we would be fools to place a big bet on such a narrow-minded approach in 2018. The world has moved on to larger scale implementations for this, and we must too.
These radio systems are complex and multi-faceted. To work right, they must combine aspects of metadata similarity, auditory similarity, mood/style analysis, usage-based relationships, while leveraging explicit and implicit feedback. More than one of these areas involve machine learning and working with data at scale. Different people in this thread have identified some of these aspects, but they are all just ingredients. Work on the larger-scale project is underway, of course.
This period we are in today, where we are relying on “offline mode radio” for everything, is an opportunity to work out the kinks for offline mode and make it as good as possible within the design constraints, so we welcome your feedback, and will continue to iterate on it.
As for the current radio feature–there has already been one iteration on this feature released to the public in January, and second iteration is entering alpha testing soon. These ideas are being applied to the larger-scale system as it’s worked on as well, so hopefully we won’t see these same issues reappearing down the road when we turn on the bigger feature.
Hi Brian. Thanks for the insights. This may be one of the most exciting posts I’ve seen on the forum, and it’s also a little disconcerting. More the former than the latter but I think it’s fair to provide feedback on both points.
This is the exciting part. Seeing a very powerful algorithm reach beyond what is in a single library and beyond what Roon displays as metadata will be a very nice listening mode indeed. Who knows, maybe this is how SkyNet started, or this is how the aliens take over without firing a shot. But in the interim, I’d love to see what you can put together and how it does in serving up tunes.
This is a little disconcerting. I like Radio 1.3 but I’m not so attached to it that I cannot possibly conceive of living with changes.
That said, I do think people should, if they want to, have the right to understand how their actions affect the software’s response to playback. I mean, you get this feedback because people CARE, a LOT, about what music is served to them. That manifests itself in feedback not only because they want to be helpful in the development process but also because they want a modicum of control over how it’s done – how their listening session will go, and to gain that control, one needs to understand how one’s actions create responses within the software.
I’m not saying I object to what it does. But I’m not sure I agree with your statement that is not what documentation is for. If it’s to help us enjoy your product, it should help us understand how to use it and how what we do creates responses.
And in terms of continually changing it, I think that affects how people feel they can control it as well. I really don’t see an issue with a couple of settings that allow people to use the version they’ve enjoyed the most. It feels a little like you are saying that users have signed up to be taken for a ride of sorts. In a way, yes, I am enjoying the software’s evolution. But in matters of what I want my shuffle or radio algorithm to do, I think many users will desire more control than this implies.
You’re entitled to your opinion, and it’s your product. I suspect you’ll get some push-back on this point, as above. If there are no settings on your ultimate radio product, users will not be able to vary what they want based on their mood or desire to explore versus stay close to home. Maybe that will work out fine, and I assume there will still be seeds of some sort. But as above, people work really hard on their collections to gain a feeling of usability over it, and one manifestation of that, one way to provide that sense of control, is to be able to change parameters on a shuffle or radio.
So this news affects me two ways: (1) it creates a real sense of anticipation to see how SkyNet Roon Radio will be a revelation in AI DJ-ing, and (2) I am going to need to build in my own methods of creating listening modes in case Skynet starts sending terminators back through time.
We’re not averse to a simple control or two, so long as they are kept broad and goal oriented–but nothing like what you proposed above where knobs control the internal mechanisms directly.
We tried to build a slider into the current radio feature that controlled the tightness of the picks, and it was a real struggle to make it work well, so it was pulled from the release. The slider in our prototype ranged from 0.0 to 1.0, with 0.0 as “tighter” and 1.0 as “looser”.
One problem is, depending on the seed and the diversity of quality picks available in your library, the useful range of the slider varied a lot from session to session. In a huge library where you’re radio-ing in a part of your collection that has a lot of depth, most of the slider is useful, though below about 0.2 or so it starts to feel repetitive from session to session even though it wasn’t actually repeating tracks. If you’re in an area of your library with a poverty of picks, though, anything above 0.5 starts to feel so random it’s useless, and everything less then 0.3 or so is virtually the same…but if your library has a good depth of picks (say 2-3000 valid picks available), the slider was useful all the way up to 0.8 or so. In the cases where the useful range is narrow, moving the slider didn’t have a meaningful effect, because there just wasn’t enough content to create clear subgroups of “very related” “somewhat related” “loosely related”.
Another problem–even when it does the right thing, it sometimes feels broken. The slider was controlling a statistical probability of picking certain kinds of stuff, but it doesn’t guarantee anything about specific picks. Sometimes you’d move the slider to “tighter” and the “up next” track would go to something that–to your mind–felt looser. Sometimes it was, and sometimes it wasn’t. Sometimes our personal concept of what is tighter/looser contradicts what the data supports…and the slider, as implemented, made those situations apparent in an unpleasant way.
So the slider wasn’t that good, and it didn’t make it to production. To be clear–we are not in principle against the idea…it just didn’t work well enough to make the cut. I think it will be easier to make something like that work once we are incorporating TIDAL content–since there will be a lot less variations in radio behavior caused by differences in personal library makeup at that point. But we could also fail on the second attempt, too, so no promises
I don’t think documentation is about baring the internals for all to see. It’s about helping people use the product effectively when we can’t make it self-explanatory. We like products that don’t require documentation. When docs are required, it means that we have failed to make sufficiently intuitive product.
We can do a lot better job helping people who want to understand in discussions like this one.
I’m generally not shy about sharing internals, but I think that there’s a high likelihood that if I explained exactly how this stuff worked, this conversation would devolve even further into specification-lawyering and backseat-driving and we’d stop getting useful experience feedback. I’m not about to put more fuel on that fire–there are already too many supposed silver bullets in this discussion.
Plus, I already know that once we have this stuff truly done, the explanations will be totally different, so I don’t want to prematurely build a bunch of public intuition about how this stuff works yet. It will actually be fun to talk about the machine learning stuff. It is probably the most interesting project I have been involved in so far, and it has implications that reach far beyond radio.
Yes, we are all on a ride together. In 1990, if you bought a piece of software, it stayed the same until you bought the next version. This is not that world anymore. Roon is a service, not software–and that is not just a technicality, it’s how we approach the whole thing.
Part of that service is the client software updates. Part of it is the cloud services, which evolve more or less independently. Part of it is the business relationships we maintain. Part of it is the choices we make to cultivate a useful ecosystem around Roon, and part of it is that Roon changes over time.
Not everyone is going to agree with every change, but keeping every possible permutation alive isn’t possible, and–if you think about it holistically–it isn’t good either. It’s really confusing for new users to deal with all of the unnecessary choices, and it consumes a lot of resources to maintain a bunch of nearly-dead versions of things for the people who are reluctant to adapt. Those are resources that don’t go into addressing other problems, or building new stuff.
Thanks Brian for the thoughtful response - it is fascinating to see inside the development process and what did and didn’t work for a pending release.
Interesting point. I wonder if you could calculate the pool of songs from which a shuffle or radio would draw, and then present slider settings that match. E;g; if there are 3000 tracks, 5 incremental settings available, if 1500, then 3 increments, and below 500, you pop a message that the pool of tracks is too small for meaningful adjustments. But of course this would mean setting it every time you shuffle, which would not work for “set it and forget it” folks.
A “why this track?” capability might help with this. Amazon does that when they pop certain products.
I don’t disagree with the way you phrase this. My concern related specifically to the thumbs up and thumbs down functions and your response which I inferred to mean that documentation isn’t for telling us what those functions are. I think there are many users who would want to understand what this does (other than the obvious of creating the queue), at least on an approximate basis. The exact algorithm, no, I wouldn’t even understand that. But if I am affecting more than the decision on what song goes into the queue, I’d want to know that.
Hey, it’s hard for a leopard to change its spots.
Sure, however you want to characterize it. I don’t disagree which is why I’ve stated concerns about putting all my object-by-object metadata into the Roon database alone as opposed to reading it from file embedded metadata. That said, I do hope that if there are radical shifts in how Shuffle and Radio work, that users have a way to use versions they liked better. Maybe that’s impractical, and I am not change averse, but there is something to be said for letting people have the version they felt worked the best for them.
Anyway, I am looking forward to seeing the SkyNet version of Radio!
Maybe I have misunderstood but is there no way to “user-hide” categories from radio in roon? I can imagine wanting to hide at every scale. That is, doing everything (and more) you can do on “focus” but just for radio.
- Tags - e.g. spoken word, dialogue, recitative, applause.
- Genres - e.g. Xmas, Christmas, Holiday, Experimental, AvanteGarde, Traditional Folk, Rap
- Tracks - e.g. (real) radio station playlists you get in the car that have been played to death. Also, some tracks are titled “dialogue” or “intro” that you would like to hide. e.g. rambling intros on live disks. But some dialogue you would like to keep, e.g. on Soundtracks (Tarantino).
- Album - e.g. Vinyl you have ripped on a side by side, rather than a track by track basis.
- Artist - e.g. Your wife love’s “Sting” but you don’t.
- Sample Rate - e.g. Everything below redbook.
From comments I have seen from @mike there are some existing rules that roon does in the background. Perhaps roon can give some guidance. Is it possible that all these sorts of “radio rules” are transparently machine learnable so no user intervention is required? Surely the simplest thing is to extend the “hide” functionality in library so this can be tailored to user preferences?
Been an interested follower of this thread. Appreciate the thoughtful input and suggestions by the contributors and the followup responses by the Roon team. Certainly, share some of your concerns and am encouraged by the efforts being made by the staff to address them.
Hopefully, this is the right place to post some issues I am encountering with Radio 1.4 that I have not seen addressed by others to this point. Am aware of the fact that radio will not start if it is a Tidal track. However, from time to time, the radio will not begin after the last track of an album I own is played.
As you can see from the image provided, it queues up a similar track. But it never plays. The play button is greyed out. So I have to manually click on the next button or thumbs-up-or-down button in order to activate the play button. Once activated, I have to click on the play button to start the radio function.
The only explanation I can provide is that I have noticed radio starts okay when it queues up before the conclusion of the last track playing. Radio usually fails otherwise.
The other issue I have encountered is when the radio starts after playing an album, rather than being initiated from a single track. Although Radio 1.4 is doing a much better job of not being repetitive, it frequently has, at some point, queued up a song or two from the same album just played. Wish there was a way for the radio function to avoid this issue by programming it to play similar tracks from the album selected vs. the last track played.
Please let me know if I can provide any further info to help address these issues. Thanks.
This is what bans are for–you can ban tracks/albums from radio by clicking the favorite heart twice if there is really stuff you would truly never like to hear except when chosen directly. As with favorites, bans are tracked per-profile, so you and your spouse can have different preferences.
There are existing rules related to many of the genres you mentioned. We are testing a set of refinements to those rules right now based on feedback in this thread, so it’s not really useful to argue based on the current behavior until that rolls out.
This is a known issue. There is a fix for this in alpha testing at the moment.
This sounds like something for @support to investigate and turn into a reproducible bug report that our developers can act on.
Hi @brian, maybe I am doing something wrong or I have misunderstood something but banning doesn’t behave the way you describe which is why I haven’t been using it. The example below is a Johnny Cash compilation where there are several lengthy dialogues:
If I ban those tracks, then the dialogues are skipped when playing the album through normally as well as the radio. I just want to be able to ban spoken word from radio. There are many other examples, applause, lengthy intros on live albums, recitative in opera, narration on some classical works, dialogue on soundtrack albums.
All of these spoken word items I would like to ban only from radio. When playing the album through normally I don’t want them skipped. Is there a setting I have missed?
No, you aren’t missing anything. Banning is for all “automatic” play situations (i.e. where you haven’t picked that specific thing). That includes album play, artist shuffle, radio, etc. There is no “just ban this for radio”, and I’m not sure there should be.
As I mentioned above, Roon automatically removes a lot of tracks like this from Radio. I don’t think it would auto-exclude those “Dialogue” cases, however. Maybe that is something for us to expand (@mike–this is for you. Also consider “applause”, which is not in the current list)
It is difficult to generalise a pattern from the track titles. Dialogue by Johnny Cash was just an example. It is rather common in Classical libraries so other variations I commonly see are “spoken”, “narrated”, or just “voice” and then there will be localised equivalents in French, German and Italian. For example parlé in French. One pattern I have noticed is that the publishers will tag composer and/or genre as “Spoken Word”. Is that a rule that roon could standardize on? Here is an example:
And here is an example where “voice” (very ambiguous, is that singing voice or spoken voice?) has been used to title a lengthy narrated introduction to Saint-Saëns Carnival of the Animals:
A big challenge is Opera. Maybe there are those that would like the recitative on radio but shuffling what is essentially sung dialogue from different Operas doesn’t make a lot of sense to me. I do not have access to my main library at the moment but I have a recollection that tracks are sometimes titled “recitative” or similar but it is not a universal practice. For example below, is Mozart’s Marriage of Figaro from Deutsche Grammophon. There is a lot of recitative in that Opera which makes sense when listening through the whole piece but lengthy recitative on the radio queue is not something you would expect to hear on a regular radio station for example. The problem is there is no indication that the marked items are recitative:
If roon had a rule that it excluded “Spoken Word” marked and/or in a genre or composer tag then there would be some control over this. Technically I am not even sure that Mozart is the composer of the recitative as traditionally it was improvised by the singers.
That said, I love that radio works within the confines of my library. Will this remain an option?
Going out of library would be more like a “permiscuous mode” for when I’m feeling adventurous
With non-Classical seeds, I am getting Classical creeping into the radio queue on a regular basis, especially when I seed with Easy listening / Bossa Nova artists. This is probably the reason why:
Crossover albums are common, especially with the most famous Classical artists:
Another pattern I see is that Folk, Folk/Rock seeds especially those associated with acapella voice will often provoke large scale choral works. So here the seed was the Folk/Rock crossover Eddi Reader, associated with the very intimate “art” songs of Robert Burns. The result was a large scale Arvo Pärt choral work on the radio queue which is jarring in every way imaginable.
Is there any strategy for avoiding this? Other than the nuclear one of removing all pop tags from Classical artists. Would that even work? I am noticing these effects happening even where the offending Classical artists do not have any obvious pop tags but I assume roon is finding a relation with Classical artists that do.
We have some changes coming that re-calibrate our treatment of artist-level genre data. It should reduce the probability that artist level genres cause radio to “cross over” via artists with overly broad genre data.
I look forward to that. Getting radio right will make metadata issues look like nit-picking to many of us. Me any way.
I’ll believe it when I see it
ha ha! 78910