Just came to say thank you for this extension! My 3d printer didn’t do a fantastic job making the case, but my little rpi and touchscreen made for a perfect little platform for this extension! So much more useful than Roon Display. Thanks!
6 Likes
I wanted to thank you for this wonderful effort. Thanks to your Github guide I was able to setup for my kitchn exactly what I wanted. I have now a “Roon station” made of RPI + Touch screen running Dietpi. Took 2 hours but the available information was great and this is an inexpensive Roon bridge and Roon controller which I can now use. I only wish we had the file information and format, and hopefully the API will provide this one day!
2 Likes
Honestly, I am on the fence about having the the format in the API. I recognize that this is a highly requested feature and as you accurately point out, it is not currently in the API. But there are a LOT of questions in my head about how this type of information would be displayed in what I like to think is a clean UI.
If it is just the file format - for example FLAC 192k 24bit Stereo - then I am somewhat okay with it. Adding one line to the now playing UI does not hurt my head.
But just because the file is that format does not mean that is the format that is playing. While most of us have systems that can play the original format, there are quite a few that don’t - for example Chrome Cast Audio, Apple Air Play, or Sonos. And what about zone groups where one device can play the original format but another device gets down sampled to - for example 96k 24bit, or 48k 24 bit?
So which should be displayed? The file format? The format being played? If it is the format being played, how should zone groups be handled? Some DACs show the playing format as text or as different colored LEDs - should this information be duplicated?
Either way, this is all academic since it is not in the API. But it would not surprise me if others have asked these same types of questions.
Oh - and for those of you who are curious, a complete rewrite that will become Roon Web Controller 2.0 is rapidly approaching alpha status. The backend is 95% done and the frontend is about 75% done.
So while I will not set a time line, please know that it will be coming soon.
4 Likes
I was mistaken with my previous comments. The queue api does not allow for managing the play queue. The only available function is “play from here” which I have not implemented yet. The Roon Web Controller 2.0 prototype in my lab (not released yet) is displaying the queue beautifully, though.
And as an FYI especially for you, I plan on doing a screen reader friendly layout in Roon Web Controller 2.0.
2 Likes
Mike,
excellent news. Thank you very much for announcing the new version and for make it friendly for screenreaders. I will wait with great impatience because each new functionality of the Web Controller gives me greater sphobody and increases the joy of listening to music.
I miss the ability to edit and save playlists. Keyboard shortcuts for play / pause, previous and next song would also be useful. And the opportunity to see Quee is great information and will make using the Web Controller more enjoyable.
If I could be somehow helpful I would like to help but I don’t know programming at all.
I keep my fingers crossed and greetings Robert Tota
I will definitely have open beta testing, so I appreciate the offer!
Many users of Roon Web Controller are using it on older devices like iPads that cannot support the full Roon client. As I am writing the replacement, this fact is on my mind. Unfortunately, I do not have any older devices that I can test with. So I will definitely have a beta to get information on things like that.
I will create a new thread with instructions and will announce it here as well when I am at that stage. But as I mentioned, I do not want to set timelines and will leave it as “soon”.
2 Likes
Keyboard shortcuts is definitely on the list of things that I want to implement. And I plan on doing that with 2.0.0. The javascript framework that I am using (Vue) does not natively support it, but there are a lot of folks that have implemented keyboard shortcuts with Vue applications. So I am hopeful.
The plan is for keyboard shortcuts for play/pause, previous song, next song, as well as shortcuts to the different views - library, now playing, queue. Keyboard shortcuts for volume and showing the settings view are things I would like to do as well.
Not only are keyboard shortcuts critical for screen reader users, but it will also be useful in a TV / home theater layout that I am considering - likely in version 2.1.0.
Playlist management is not in the API, so I really can’t implement that.
Mike,
I understand, you can’t do anything unless the API allows it. As you describe, all keyboard shortcuts will be very useful. I really like the ability to switch using a keyboard shortcut between Quee and library or now playing. Could it be one keyboard shortcut that would switch between these three views sequentially in turn?
I would also ask you to put aside the numbers representing the total time of the song from the time to its end. Because currently screenreader reads it to me as one value.
Regards Robert Tota
I remember you had mentioned the number issue before. On the new touchscreen layout, they are separate div elements, so a screen reader should separate them correctly. For the screen reader layout, I am planning on having them on different lines with text describing what the number is.
I had not thought about using one keyboard shortcut to cycle through the views. I like that idea!
1 Like
Continuing to play with the interface and of course bumped to the lack of abilty to type in the search box on the touch screen (dietpi on RPI 4). Is it still the same tweak you proposed much higher on this thread (about two years ago I think)?
Mike,
I’m glad you remembered my suggestions about the length and time of the song. I am waiting patiently for the new version of Web Controller. I know there are other things that may require your attention and time.
Regards Robert Tota
If memory serves, the previous suggestion was to use an onscreen keyboard from the Chrome store. And that would still be the recommendation.
On the version of Roon Web Controller you are running, the on screen keyboard can be inconsistent due to the way the pages are put together. The newer version I am working on, the on screen keyboard will be a lot more consistent.
Looking at that settings screenshot, there are are few options that I do not recognize. I am guessing that you are using a fork of Roon Web Controller. “Show clock” and “Track color” are new to me…
Out of curiosity, when the “Show clock” setting is enabled, where does the clock display? If this is a feature that is useful, then I can easily add it to the new version I am currently writing…
1 Like
VERY cool that you were able to figure out that spaghetti code enough to tweak it to your liking!
For the song info lines - yes you are correct that line1 = track, line2 = artist, and line3 = album, but only when you are playing music from your local library. When you are streaming from an internet radio source, line1 = stream name, line2 usually is the song, line3 usually is the artist, but sometime it is artist/album. It was for that reason that I did not label the lines and I kept the lines in the 1, 2, 3 order. It is up to you if you want to keep your tweaks, but with the new version, I am keeping the 1, 2, 3 order. Although with the new version it will be much easier for you to tweak it, too!
For the clock - even with the original version, I had toyed with putting a clock in the UI. Now that I am using Vue, it would be even easier. The new now playing screen looks very similar to the one you are using, so I could easily put a locale localized formatted clock in one of the corners, with a setting to show it or not. To keep it clean looking, I would use the format “LT” described in the “Localized Formats” table here [1]. I would want to use the localized format because I know there are Roon Web Controller users in France, Japan, and Korea, and the time/date format varies for different regions.
[1] https://momentjs.com/docs/#/displaying/format/
For the play pause on the progress bar - in the new version, this bar is already replaced with a functional track seek control. The UI element is in place now, but I need to do the back end code to actually support the track seek. That is a 2.0.0 feature, so I would not want to duplicate the play/pause behavior on that element.
For the color differences - neat idea! Though in the new version, I am eliminating the use of color to show if something is active or not. I work with a few folks who are color blind and they were not able to tell if (for example) radio was on or off. So with the new version, I am using different icons for on/off, or in the case of loop, loop off, loop all, loop 1.
For the light/dark detection code - that was there to support the “dominant color” theme. Neat use of the code, but I am not planning on having a “dominant color” theme this time - at least not for 2.0.0. If enough folks want it, I might be able to bring it back.
For the weirdness of the no display when switching from library to now playing - that is annoying isn’t it!!! That is one the main drivers for the architecture change with the new version. Vue uses a product called Vuex to store state centrally. When used properly, all of the data goes into the state, then the display elements just display the state. It is a shift in thinking, but once done, it makes creating UIs MUCH simpler. By doing this, I no longer have that weirdness with switching from library to now playing to queue. It just works!
For the progress time - I forgot about that! A year ago I had toyed with having a setting to have that time be either “Current Position” or “Time Left”, but I never implemented it in the old version. I just added it to my todo list for version 2.0.0.
Good stuff! Thanks for the info and I hope you will have just as much fun tweaking the next version!
3 Likes
A minority request here: include a screen display geared to classical music. My mental model is to create a few (2-3) screen templates for different types of music. The two obvious ones are “Rock” and “Classical”. The primary difference between these screen templates is the amount and type of track data displayed. The Classical template, for example, would include the composer, and would extend the amount of space allocated to a track’s WORK and PART descriptions. Space for these additions would be borrowed from something, perhaps smaller album covers, smaller fonts, etc.
The user could access any template but is likely to just pick one and leave it alone. A really cool way to program templates is have the extension choose the best template based upon the track’s genre.
Anyway, just food for thought.
Not as minority a request as you would think. I listen to a LOT of classical as well and feel your pain.
However, I can only show what is in the API itself. And the API does not separate out WORK, SECTION, PART, COMPOSER, CONDUCTOR, ENSEMBLE or the many other useful tags for classical music. It shows lines of text only, the format of which cannot be changed. What the app shows is what the API presents.
That said, one things that really bugs me with the current version of the app is the length of the song lines. Scrolling through a long line like “Das Rheingold: Scene1. Der Welt Erbe gewänn’ ich zu eigen durch dich?” is downright painful. The new version does not do any scrolling and displays the entire line, which makes things much easier to read.
Here is an example screenshot of the Now Playing page in the new version - the first screenshot to be made public by the way! 
3 Likes
Definite improvement methinks. I yearn for a classical-friendly display.
Roon, pretty please??
1 Like
Roon Web Controller 2.0.0 ALPHA-0 has been made publicly available.
Please keep ALPHA comments in the other thread so that I can keep an eye on them.
See this post:
2 Likes
Please hint how to change the listening port (8080) for the Web controller installed on QNAP NAS Server?
Best Regards Robert