Great post @Jeffrey_Moore. You make make an excellent point on how the inclusion of RAAT/other network devices has brought about use cases for Roon that are apart normal PC or tablet use and how interacting with these devices can impact social dynamics.
I too would love to have such a device and wonder if what you want could be accomplished via a raspberry pi + other parts. I think i recall one of the roon gents saying that RAAT would transmit the now playing info but i can’t see to find a post confirming it. If that is the case then it seems that a raspberry pi + a nice case with LED would do the trick. not an off the self solution but one that would certainly seem to be a drop in replacement solution for squeezeboxes and affordable.
Ideally i would love to add an LED screen to my Raspberry Pi running roon bridge that had displayed the top part of the queue screen.
Well… as we know, Squeezeboxes were a successful product under the original team who developed them; later, the line lost its way under Logitech, a commodity-hardware vendor. There may well have been a mismatch between company philosophy and audience after the line was gobbled up.
A number of people in this Roon community, though, come from the Meridian world where commodity pricing isn’t an absolute requirement.
I know nothing about estimating development, manufacturing and other associated costs.
I also don’t really know what others might pay.
I’d happily pay $200 each for well-executed devices as I describe; I’d less-happily pay $300 or more.
But also, as @AgDev01 suggests above, some of us might be able to bang together something which suits some part of the purpose from a little hobbyist computer like a Pi… which is why, while I was describing the device I’d love to have, I made it clear that my most immediate question was whether this functionality (particularly a separate device following the activity of a particular other audio endpoint - a single endpoint, regardless of its varying synchronization group affiliations) is possible given the current Roon protocol definitions. Because if it is, then it would make sense to try to get sample code from Roon and prototype something.
JSE linked an interesting Raspberry Pi case and display here. I can imagine grouping such a display with whatever RAAT zone you wanted it to display. I don’t think the transport style remote would work though, still have to use a Roon control point to control the playback.
digging through the youtube video in the post you linking the final product is pretty slick looking and cost seems to be about 25 USD for the case and LED. I guess the question I have is playback control part of Roon Bridge or could it be in not currently? If so i don’t see any reason the remote couldn’t eventually work.
When we build an API, all of this will be possible (DIY or otherwise…no intent to lock this down).
This is a relatively near-term objective for us–it enables tons of good user experience on a wide range of existing hardware, and also allows us to expand in markets that require home automation without necessarily taking personal ownership for integrating with each individual system one by one.
We’re thinking that API consumers will talk to the core via a network protocol. So a display could come up to the server and say “tell me what’s playing on zone X and subscribe me to updates so I can know when that changes”.
Obviously we want to do much more than just now-playing displays. Integrating with external volume controls, source selection, standby controls, and physical buttons in the listening area are important, and we’ll probably do some list-based browsing/searching too.
Excellent! As usual, you seem to be approaching things in just the right way. Knowing that this is your stated direction, I’ll do my best not to pester.
Just one nit to pick here (and my apologies for repeating myself so): everybody keeps talking about controlling or displaying info for a zone, and I understand that’s the main model, but for the sort of gizmo I crave to be truly useful it needs to be able to subscribe to updates for a particular physical endpoint, regardless of what zone it’s in. Because I know that in our house, zone memberships are fluid and ever-changing, depending on who’s in what room; but a little display/control box like I envision would be permanent infrastructure to show what was playing on a particular pair of speakers. And a particular pair of speakers is driven by a particular endpoint.
So for that use, the display box would need to be able to subscribe to updates for a particular single endpoint.
(Or it’d need to be able to query the Core and get a handle for the zone its favorite endpoint was in, and also. say, subscribe to updates whenever there was a grouping change for that zone so it could ask again when necessary)
Just hoping this will be in your minds as you flesh out the API.
We try really hard not to let the word “endpoint” leak into public communication or the application’s UI.
This was a conscious choice–endpoint vs zone is a technical distinction. In very tangible, unsophisticated terms, a user has speakers in their Kitchen, Bedroom, and Office–and that means they have 3 zones. Those zones can be grouped, or not, but it doesn’t change the number of zones that they have. That’s the model.
So, when I said “zone” I was referring to what you are calling an “endpoint”. Because I try really hard never to write down the word “endpoint” in public :). I.e. we are on the same page.
Roon doesn’t have a word that means “N zones grouped together”. That idea is intended to be implicit.
Sweet - then I was stumbling over my attempt to be precise while I was actually using confused terminology. A zone is a single thing driving the speakers in a particular physical location, and the ability for a second device to subscribe to updates about what’s playing in a particular zone is on the API roadmap. I’m good - I just have to be patient.
This kind of functionality is what Roon Ready certification can do and has, I think, been implemented int PS Audio Roon Ready.
Unfortunately various devices have different ways of dealing with visual data, so I don’t understand that it is feasible to create a one size fits all solution for Roon Bridge to do so. In circumstances where there are many devices that don’t use visual data there seems to be a strong case for keeping Roon Bridge lean and mean and implementing device specific bells and whistles in Roon Ready certification.
It will be interesting to see what the forthcoming Roon API makes possible. Details about API functionality haven’t been released yet.
I agree entirely. I’m really impressed with how well a relatively inexpensive device dedicated solely to high-quality transmission of audio data can perform. A microRendu - especially when fed by a shockingly excellent DC supply like an LPS-1, and I’d contend also aided by a surprisingly good USB-to-S/PDIF converter like the Singxer F-1 - is the best-sounding digital transport I’ve ever heard in my home.
I don’t want to compromise the microRendu’s performance by tacking on any ancillary user-interface nonsense. I just want it to continue to be the lean and mean excellent-sounding simple headless zone player it is.
BUT - I do crave some user-interface bits I feel are missing from our Roon experience. Simple-seeming things like the ability to use an IR remote control, and sure, a track display would be nice, too. I don’t want any of this to be the responsibility of the microRendu, as I wish to jealously guard the relative simplicity of its mission.
So a user-interface gizmo which could logically be bound tightly to a single microRendu, but which would physically be completely unconnected to it - the binding-together happening via the network and the server, not anywhere else - is what I want and need. Such a gizmo should just handle user interface chores, not add additional unnecessary load to the network or server by having to be fed audio which would just be discarded.
This is what I want. This is what I think a lot of people will want, once they realize they want it. This is what I hope the API will allow.
IMHO, kind of SBT (“old” SqueezeBox Touch but without audio capabilities) would be such a desirable device, from price range, UI, and form factor point of view.
But, unfortunately, it is not possible (EOL and almost no RAAT support) to group it with better RAAT enabled headless endpoints (from SQ point of view). So alternatives are needed. I hope too API will allow. Big improvement in Roon ecosystem usability
I have been having similar thoughts recently. What I would really like a manufacturer to build is a version of my Meridian F80 that is a Roon endpoint, which effectively has an iPod touch integrated into it, running the Roon remote app. Would give a great display and allow a nice touch interface. I would then want a programmable IR remote so you could do some basic navigation of the menu and the usual playback functions but with some proper buttons.