Orders of tracks in Queue Skewed - Follow up

Feedback Feature Suggestions
1

Hi,
I read this post which solved my immediate issue: Orders of tracks in Queue Skewed

I now understand that when I have shuffle ticked in the ‘playing now’ window that when I add an album to the queue, the album gets shuffled upon adding to the queue.

I now need to check whether there is an inconsistency or more probably I’m doing something stupid…

When I add an album ‘next’ (as opposed to adding it to the queue) the album isn’t shuffled regardless of what my shuffle setting is on the now playing screen. For me this is a little annoying and it would be great to get this inconsistency (if there is one) sorted out in a future version.

Can I make a further suggestion that the queue behaviour be improved regarding shuflling an album. When I want my queue shuffled, I want the whole queue shuffled, not just the track order within an album altered after I’ve added it. So I’d prefer that the album be added with the tracks scattered across the ‘upcoming tracks’ and then some confirmation message appear, telling me that the tracks have been shuffled into the upcoming list. Whadyathink @brian?

2

The “Play Next” behavior is deliberate, thought through, not likely to change. It’s been probably 18 months since we made the decisions last, but thinking through them again, I think that the current behavior is the best possible satisfaction of the design constraints/goals for that feature.

I don’t understand the second point. I would expect “Add to queue” on an album to mix the album into the rest of the queue, but that sounds like what you are expecting too.

1 Like
3
1 Like
4

Add next - takes the album you have selected with the tracks in their original order and inserts it intact to play next in the queue
Queue- takes the album and inserts it shuffled with tracks inserted randomly into the play queue

Subtle but different…

5

…I don’t think it breaks up compositions.

6

No, it doesn’t break up compositions (nor should it).

7

Apologies, I have managed to confuse myself regarding the second point - please ignore.

Re your reply, ok, fair enough, if that decision has been taken then we are where we are. I was over the moon when you added the ability to customise the play actions in the settings menu and it’s improved my experience of Roon ever since. If it is not possible to make the play button actions consistent then how about flagging the setting to the user at the point of impact (there is a small shuffle icon in the bottom bar but it’s quite a connection to make). The play icons are quite large on the tablet/desktop version and there would be plenty of space to add a small indicator of the current shuffle setting to the ‘add to queue’ button and a ‘play it straight’ icon to the ‘add next’ buttons. Small change but maybe helpful.

image
image.png736×240 11.6 KB

8

The way we designed shuffle, it should be non-destructive, so you should be able to safely un-shuffle after adding to queue by mistake in shuffle mode + end up with the same queue (minus anything that started playing, of course).

This non-destructive approach is not 100% conventional, but it was supposed to (in part) stop people from having to reason about shuffle constantly.

9

“having to reason about shuffle”? Sorry, don’t understand what you are trying to say.

Roon found a way to “normally” keep a composition together. Really good work; good aesthetically, good practically for many types of compositions: symphonies, concerti, etc. And good for linking common metadata.

But not all compositions are meant to be listened together. They are more like collections of individual pieces that are loosely related to each other. In many cases, the composer had nothing to do with their aggregation.

Until you provide a means to optionally ungroup compositions in playlists and radios, Roon is imposing on its users only one way of listening to compositions. All you need to know this is inappropriate is to put 24 preludes of Rachmaninov in a playlist. Scattered, they are beautiful. Together, in order, always, they become a chore to listen to.

Can you at least admit that not all compositions are intended to be listened to in one sitting?

I still think having a toggle for any playlist (or a radio) to “Ungroup on play” gives users the best of both worlds.

10

It’s common to think through the user’s metal model for a product when building it. The non-destructive design for shuffle was in part motivated by reducing the amount of reasoning/thinking required to use the feature. Because order of operations doesn’t matter, you do not need feedback constantly about the shuffle state cluttering up the play popup.

Yes, I know. These cases exist, even if they are far from the majority of compositions, even the majority of multi-part compositions. Getting the symphonies + sonatas to do the right thing trumps nailing every last edge case.

Offering choices in a product is expensive. Not talking about development cost–talking about the complexity + mental model burden that they place on all future users, amortized over the whole future of the product.

This cost is something that armchair product designers and product design beginners like to totally ignore. Offering choices that only a few % of people will even ever understand, like this one, is just not a smart thing to do. I’m not saying that the problem is not valid–I’m saying that jumping to “offer me a setting” at the start of the conversation is begging for a “no”. Settings/expanding options are last resorts, not starting points.

In this case, the problem is primarily to do with how the performances are defined, because Roon’s queue groups by performance, not by composition. Our upstream metadata providers decide whether or not an appearance of a composition on an album counts as one performance or many.

11

Thanks for the thoughtful reply. I really, really do understand the costs involved. I can recall a client asking for “one small change” to a database I had built for him, and we almost came to blows over the estimate of the cost to add that “one small change”: a complete redesign of the DB structure, among other things.

It took effort to cement a performance together (I still think of it as a composition) so that it doesn’t come apart during presentation, linking, and playback. For those purposes, that is the best approach. We agree on that.

I will take issue on your characterization of this as an edge case, though. I can mention seven or eight classical forms that beg to be separated during presentation. That group may constitute 40% of my tracks. (guesstimate, I admit). True multi-part compositions are the minority.

Also, I believe the vast majority of classical listeners do not sit through an entire composition, whatever the form. That was something their parents did. Today’s listeners don’t have that much contiguous time to take in an opera, all of Rach’s 24 Preludes, or a Mahler symphony. Their technology allows them to sample, skip around, get highlights, and easily bypass tracks that aren’t working for them at the moment, or move to another composer at a different time.

I happen to like some ancient rock bands, just not the same band for 24 songs in a row. It’s no different for classical listeners.

You spoke of mental models. When I think “shuffle”, my mental image is…Shuffle! The first thing playing is Rach’s Prelude #2, and then shuffle. Do I expect Rach’s 3 next? Rach’s anything next? Odds are, with 500 tracks or so, the next track would be…you know…different. Not trying to be difficult or argumentative, but my mental picture of shuffling is different than the one you are describing…

All I really want is to create a playlist a large quantity of short classical tracks – portions of compositions – and have them play back randomly. Is there any way to do that short of ungrouping a large portion of my library? Must I add each track individually to sever the grouping?

I thought a simple solution was, at playlist creation, to accept/reject the option to “keep composition grouping” for this particular playlist. But, I haven’t been under the hood, and I do get your aversion to add-ons.

Thanks again for your thoughts, and please share any solution paths.

12

I totally disagree on this one. I listen each composition till it’s finished. Don’t think young serious classical lovers won’t listen to entire compositions. I also read complete books, not just some paragraphs.

13

We’ll agree to disagree. And who said anything about serious?

I admire anyone who sits through Rach’s 24 Preludes in one sittings, or Alkan’s Etudes. That takes stamina.

Your reference to books is way off base. Not comparable.

2 Likes
14

Is it really?

15

Yes, really.

1 Like
16

I think the problem with both of these is that they shouldn’t be treated as a single performance, even if they are part of the same composition. I have a similar issue with Chopin’s preludes. You’re right that they don’t belong together.

I would prefer a solution where we are smart enough to keep the tightly-coupled multi-movement works together, and separate the looser collections. This works without adding manual queue management labor + improves things for people who aren’t ever going to put in the time to manage their queue so tightly.

Whatever the editorial standards were for this data, it wasn’t consistently optimized for playback use cases. It has plenty of errors in both directions–both mega-performances that contain many loosely related works, and albums where you really want to listen to them together, but some pedant decided that because each movement was recorded on a different day in the studio, it should be considered a separate performance. There is plenty of grey in the middle (Barber’s Excursions, for example. These were published as a set…but it’s common to perform just one).

Part of the problem goes back to the music historians who invented these catalogs. They were poor data practitioners, and each catalog works towards a different set of goals, often mutually inconsistent. This sort of sets up the downstream people working at our metadata providers for failure…

There is a lot of artificial grouping in the composer catalogs even at smaller scale. It’s silly to keep Chopin’s Op.64 (a 2-part “work” consisting of the Db Major and C# Minor Waltzes) together. They are clearly standalone compositions, almost always performed separately.

I really think it’s sensible to keep standard multi-part forms like symphonies and sonatas grouped. These were composed as discrete works of art + intended to be listened to in sequence.

We’re talking past each other re: the shuffle mental model. I was speaking specifically to the non-destructive approach when I brought that up (i.e. the way that we keep a parallel shuffled and un-shuffled queue at all times so that flipping back + forth is non-destructive, and order of operations is less important than with the more common shuffle implementation that just mixes up the queue destructively + loses information at many more operation-points), and you steered the conversation towards picking apart how classical work/part structure works. That’s fine to discuss, but not what I was addressing when I brought that idea into the conversation.

1 Like
17

Do you think that using your Forms variable might be a way to bifurcate the population into separable versus non-separable? Symphonies, Concerti in one pile; Etudes, Preludes in the other?

(Note how effortlessly I side-stepped the muddy middle cases. But making a semi-arbitrary call of which stack a Form belongs is not without precedent.)

18

It might be. I think it would be one of several heuristics. We could do global analysis, like “does this work usually appear in full and contiguous on albums”–which could be an interesting clue as to how it’s normally performed.

I agree that maybe this behavior needs to be less rigid (otoh, that has to do with much more than playback. We shouldn’t display something un-grouped on the album screen then group it in the queue or vice versa). So then this becomes more of a problem of how to optimally re-write performance assignments at the track level.

The biggest problem I have with classical is developing a solid unifying vision for how to re-approach the topic. There are hundreds of complaints, but fixing them one by one in isolation won’t work. I’m sure the experience feels like death-by-1000-cuts to you guys, and the experience of building the product feels very different to us. It’s a difficult gap to bridge.

2 Likes
19

From a statistical perspective, one could work “backwards” to determine a track’s separability. A large sample (1000+) of classical tracks from multi-part works are first “eyeballed” and flagged as separable or inseparable. Then track characteristics are gathered such as Form, length of track, length of related composition, instrumentation, period (?), etc. Do a factor analysis to see which factors load on separability. Then regress separability against the factors and get an equation that essentially gives you a score of a track’s separability. The error rate will tell you how reliable the score is. Decide the size and type of error you want to live with. Shuffle playback hits track, calculates score, decides to separate or not.

Add 50000 new users. Founders buy Lamborghinis, worker bees new Camrys. Champagne all around.

Just spitballin at 5am, listening to The Planets, wondering if I should listen to one movement without the others. I think not… (but what about Pluto?)

20

You probably missed that both are compositions.