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.