Hi Everyone,
sorry for the absence… Now I’m back and really intrigued to get my hands dirty with Volumio 2.
Thought it is useful to set some little goals, and assign tasks to people.
You can see an updated readme file with milestones and general architecture of the player on the repo main page: github.com/volumio/WebUI-NODE
First thing, let’s see who wanna do what, and then let’s start working together at full throttle.
Please reply to this thread, saying what you want to take care (see repo for tasks), I’ll add you to this table.
OS Michelangelo
BACKEND
Audio Services Controller - Ning-yuMeryn
Player Core - Ning-yu
I dont know much about frontend development, but I would like to help on the Node Backend. Both the Core and Services Controllers would be fine for me.
I’m afraid i have to sign off on the Volumio project There’s no way I can be of any help. Some private issues have been around for some time, and are still keeping me from doing what needs to be done. I would’ve loved to place my role as front-end developer, but I’m just not able to make any contribution at the moment. I’ve still got a lot of new code which is not even committed. With the new screen sketches; I’m not sure if my code will still be useful. (It’s a rebuild of the current Volumio UI)
Hello,
A user, Sog Sussex did a amazing work to create a theme and language selector for Volumio UI https://volumio.org/forum/theme-language-selector-installation-t2802.html.
I talked with him and he will be interested in helping to dev for Volumio.
But he need right to access this thread. Is it possible to do something ?
Thanks you.
Well we’re definitely not decided on the GUI, mostly I’m throwing ideas around to get people thinking. I’m actually very interested to see the code you wrote, let me know if I can take a look at some point, even if you don’t commit it.
We’ll miss you. Of course, personal life comes first, so take care of yourself. And we’d love to have you back if at any point you’re able!
I’ll see if i can commit the code. So I’ll make a PR. You don’t have to merge it, but you can see what I’ve done. I don’t think if you merge it it will collide with any other code. But it might be a piece dormant code in the code base.
I really love this project so it does pain me a little to stop.
Thinking of mobile usability, and being able to stream to Volumio (as well as using local phone music in the Volumio playlist), I think a mobile webpage only wont suffice.
A mobile webpage is enough for remote control, as well as playing from other sources, but if you want to stream from your phone to Volumio you will need 3rd party apps like BubbleUPnP.
A while ago I worked on a dedicated Volumio app (using the MPD protocol) with the support for streaming directly from your phone. Unfortunately I never came to the point of implementing UPnP (or any other streaming method) and ended up with just a MPD client, Volumio style.
Would it be a good idea to have a dedicated app (like Sonos) from which you can control your Volumio in addition to the WebUI? This would also allow us to have notifications on our phone, playback control from your lockscreen, volume control while receiving calls (as suggested on the forums) and much more. With the new system (and abstraction layers) we are no longer limited to the MPD protocol and create a solid connection between the phone and Volumio, making a lot of things easier like the Album Art and having a settings menu. Ofcourse the UI would and should match the new WebUI.
Let me know what you think.
Some pics of the app I worked on.
I’m currently on a Nexus 4, but used the older Samsung to check backwards compatability and UI scaling. To get to the browse/playback/playlist tab you can just swipe left and right.
@meryn
I like it ! I think (as I already wrote) that the webUI must fit to a smartphone screen with all command available without scrolling.
If you need, I can test your work on other android device.
Just to make it clear, this is not a webpage, but an standalone app
The only difference an app would have from the WebUI, would be notifications, custom volume control, lockscreen control, and streaming music from your phone.
As of now (last time I worked on this was 2 months ago, and I never used this app as the main control as it was under development), the app isnt fully funcitonal yet. What works:
playback control
browsing
searching
playback info
playlist (only display tracks, no changes can be made)
What doesnt work yet:
playlist manipulation
adding songs to playlist/next/etc (only play now)
Streaming (!)
Album art
lockscreen control
notifications
auto IP-address detection or manual IP input (currently hard-coded IP)
Also currently the protocol is badly implemented and uses more data traffic than needed. I was still experimenting and exploring MPD so didn’t know most of the tricks to get stuff.
If we decide to have an app, it should probably have its own abstraction layer.
I’m really sad you are leaving (hope just momentarily), and most of all now that we’re right on track with the development…
If you could make a PR of your code it will be sure a valid grounding for our future work. So when you come back, you’ll feel more familiar
Does this mean we do want a dedicated app? If so, I would like to sign my name under this development. Mainly because I know more of Android than NodeJS, and I really love working on integration with mobile devices. I would still like to help on the backend, abstraction layers mostly.
As for the API set, where can I find this discusison, or was it held on Skype?
Would a 1 on 1 link be best for the API? This way developers have access to the same data and functions as the abstraction layers. This would not only be easier on the RPi processing, but will also give developers the access to raw, unmanipulated data.
This way the commandRouter will basically be accessible by other connections like tcp or http. The only difference with other abstraction layers will be that other abstraction layers will alternate the data to the structure its service uses, whilst this one will be the raw data.
We had talked about exposing the current websocket interface module as an API that can be connected to by both the built in WebUI and other custom UIs (apps included). I think we can make this websocket interface provide all the data that your app needs! If this is not possible, we can make a custom interface module still.
I kinda had the same idea. The problem with dediacated apps is that you also have to maintain them. A webapp will be independant and much easier to implement new features and tweaks.
For mobile testing… I built a device lab which I can use (bit showing off )
There’s no way I can be of any help. Some private issues have been around for some time, and are still keeping me from doing what needs to be done. I would’ve loved to place my role as front-end developer, but I’m just not able to make any contribution at the moment. I’ve still got a lot of new code which is not even committed. With the new screen sketches; I’m not sure if my code will still be useful. (It’s a rebuild of the current Volumio UI)
)
