Like Andy mentions, do you not see this ? Pretty much what you described…
Apologies - I did find that button and it is pretty good! However the behaviour is not consistent across the program.
For example - It doesn’t work if you have a queue already playing and click ‘play artist’ on someone else…
I usually queue up a few artists hence why I didn’t see that functionality before.
1 Like
+1non-destructive queue - perfectly reasonable and very common use case, a non-destructive queue, also important/high priority as it effects your roon experience 100% of the time. Based on previous comments a simple toggle switch to enable both a non-destructive and current use case is the way to go. Presumably easy to implement in well designed object code.
5 Likes
I’ve had roon for months and have followed this thread with interest.
As much as I’ve tried to get used to it, the queue behavior is just plain weird to me. I’ve never encountered this behavior in any other players or software, including my Lumin S1 (whose app is wonderful). I’m sure I’m not the only one who listens this way: queue up a bunch of albums to have “in rotation” and then move back and forth from one song/album to another as I choose - without tracks disappearing after one play. All the other features are nice, but the queue is the most important point of interaction and currently just doesn’t behave the way I prefer.
I can’t see myself using roon as my main player if it continues this way.
Doesn’t seem that it would be hard to give users the option of leaving the play queue intact, but for some reason it seems roon has their heels dug in on this…
5 Likes
In the meantime…activate the play queue loop and the albums shouldn’t be removed. Should work for the use case noted above.
Unless you choose “play from here” within that loop, because then again, everything before that song will be gone 
VERY annoying, when the workaround also does not work 
I REALLY hope, roon finally finds a solution to make this optional!!
4 Likes
I will be pleasantly surprised if this is really changed in 1.3, but I am not holding my breath.
Would a history tab properly Roonified not do what everyone wants a static queue to do.
Like what is a queue? And would you join one if you could never leave it?
A queue is a list of items that an action happens to, when the action happens they leave the queue. Imagine always having to go back to the end of the queue in McDonalds after being served!
That’s what I’m hoping for in 1.3 a history tab that I can search similarly to the albums tab etc.and that my queue remains a queue.
.SJB
Exactly and amen.
A queue is a queue. If it gets played, it leaves the queue and goes to history. If a track or two gets “Played Next” then the queue lengthens by that amount. If something is decided to “Play Now” then the queue is replaced. Seems simple enough to me.
What I think is needed is a “sandbox” or “scratchpad” type of list in Roon where a list of items can be built, edited, highlighted, and sent to a queue. It never gets deleted unless the user decides to do so. Roon isn’t far from that now, with the different queues for the different endpoints. Highlighted items can be saved to a playlist, added to the queue, played next, or appended to an existing playlist. A “List-Builder” that isn’t a queue yet isn’t volatile either. Probably will need periodic maintenance and cleanup.
Isn’t that a playlist?
+1 on the original request for a non-destructive queue. Drives me nuts. And the workaround does not work. Lumin gets the queue right. It should be static until I tell the software I am done with it. And then, if I am in love with it, I should be able to save it as a playlist. Because I often don’t realize that I want to save something I listened to until after the fact, or maybe I got interrupted and left the room, but left my system playing, Roon’s temporal queue is a bit frustrating. History helps, but it’s not the same as a live queue that I can navigate internally without destroying it. Analogies to a live queue in meatspace are cute semantics but not helpful.
1 Like
Yes. I’ve always thought so. 
But apparently there’s a workflow used by some that isn’t a “Playlist” and isn’t an “Add To Queue” either. And it really could be a nice feature named, “Songs I Am Thinking of Playing In A Certain Order But I May Get Distracted By Another Song I Want To Hear Right Now.”
Sorry to sound sarcastic and I don’t mean to. I really believe after reading this and other threads on the Queue topic for the last 20 months (and after killing my queue more than a few times) that there’s merit to having a list builder that can be edited and is non-volatile.
With the huge library available to us it is inevitable that the process of building a queue gets interrupted. Roonis interruptis. Maybe during a party where we’re fielding song requests or during a listening session when something we just heard reminds us of something else we need to hear. Right. Now.
And a “Fade Out & Play This” option would be nice too. When I hit Play Now, the song ends so abruptly I want to apologize to the artist and other listeners.
1 Like
VExcellent idea(s), which will catch on with the Roon developers before long. I would suggest that adoption of the generic name “playlists.”
It’s unfortunate that a widely utilised & simple facility (adopted throughout the digital audio & Hifi industry) is missing from what is, otherwise, a truly innovative piece of software. The fact that Roon is different should not be at the expense of globally accepted functionality.v
The hints that something may (or may not) happen in Roon 1.3 doesn’t inspire confidence that anyone in the Roon team is listening. One would think that the amount of frustration expressed in this forum would elicit a considered response from “the team.” We might then be given cause to give up &/or pursue other matters.
3 Likes
There are 47 different posters in this thread in over a year and a half under half of them want any change to what we have currently - this is hardly a stampede that Roon should accommodate as you infer above.
The phrase vocal minority springs to mind.
.sjb
3 Likes
If I remember correctly it did elicit a considered response in another similar topic. I believe the response was that the comments were acknowledged and taken onboard, and would be considered at an appropriate point in the future when resources allowed. I’m guessing that means once they’re happy they’ve achieved their roadmap objectives they’ll start looking over things like this, and see if there are improvements that can be made, and how best to do it.
The fact that this topic has remained live & active for nearly 21 months is an indication of its importance, a vocal minority may support change but their opinions and needs are no less valid.
We, in the UK, are represented by a political party that holds a mere 26% of electoral support, while they are a minority their views are listened to and acted upon very day.
Most readers of this forum, like many eligible voters, will never bother to comment, they may however decide that if the Roon software doesn’t have basic functionality it’s not for them…on the other hand…
Hmm, I think you’re way off the mark. Opnions, eh?
Trust you understand that this feature is not “missing”…the Queue design was a deliberate design decision made on the basis on the Roon designers having years of user feedback from their Sooloos and HP music app, both of which had the static queue requested above??
There’s a big difference between deliberately making a design decision based on feedback from thousands of users…versus “forgetting / being unable to include” a feature in a product
2 Likes
A few points arising from recent discussion:
-
I never used Sooloos, but understand that the Queue function was non-destructive in the way that people are requesting in this thread. There was a user reaction against that impementation and so, when Roon was developed, the Queue was changed to the current implementation and History was adopted as a permanent archive of tracks played. Obviously there is a reluctance on the part of the devs to revert to a solution that was previously specifically changed by user request; which might lead to further user response ad infinitum … (a choice alternative wouldn’t have that issue and is discussed below);
-
The developers are wary about the extent to which unfamiliarity contributes to UI concerns. That includes both as to capability and the functionality used in other software. A concern that “Roon doesn’t do it like ‘App X’ does it” isn’t a strong argument for change. That’s not to say that established conventions of UIs are to be disregarded; after all those conventions contribute to the “intuitive” nature of a UI. The reasons why App X’s implementation are regarded as preferable by you are a much more persuasive point;
-
In the context of the current discussion; I haven’t seen the user case that requires change. I can re-order the Queue and loop it. If I want to make a Playlist of Tracks that have been played I can select them in History and do so. I can edit and reorder the subsequent Playlist. I haven’t read anything in this thread that describes something I can’t easily do in Roon. I don’t make decisions about Roon (thank goodness some of you might say
!) but I have gone into bat where I think Roon could be doing better and at the moment, I don’t feel that about the Queue; -
A number of posters have suggested making the UI a choice and this is a superficially attractive solution. I supported it initially (possibly because I am a superficial person) but I have also supported user choice in other contexts (for example a user definable right click “Play” function). The suggestion to make it a user choice is occasionally coupled with an observation that it would seem easy or simple to implement such a choice, sometimes with an assurance that the poster’s experience in software development means they know that this is so. The thing that everyone who proposes choice in relation to Roon discounts is how amazing it is that Roon operates with a (largely) ubiquitous UI across platforms and operating systems. The only other software I know of that attempts to do that is backed by huge corporations with resources to throw at the exponentially increasing degrees of freedom for bugs that such an environment necessarily entails (as Richard Feynman put it - Hilbert space is so damn big). So I accept the developers assurances that implementing graphics UI choices is not easy or simple, but is likely to displace a lot of alternative development. There is a real opportunity cost to development resources and a significant impact on Support as the inevitable bugs and edge cases get sorted out;
-
There are extensive changes to Tracks, History and Playlists in 1.3 which we will all see revealed in the near future. It may be that some of those changes ameliorate the dissatisfaction that some users have expressed with the current UI. Let’s find out.
3 Likes