Great! Please however, take also time to write a little documentation about it. If not we can not work on it!
Roger. Just got interwebs past saturday, so hopefully back into action this week!
Great!!!
I’m really really sorry… it has been taking a long time.
In the mean time, I have done some work, but didn’t upload anything anymore… 
These last couple of months are very busy and many unannounced stuff happened. Like I’m currently in Rome now, but going back tomorrow. Then I think I cannot make a good contribution before the end of the month. (Some private manners). Bit annoying in all. I will try to write out the documentation as promised first before adding new stuff.
I would love to see a working spectrum analyzer! Then we can have a UI that feels connected to what it is playing.
Here’s my concept mockup for what Volumio could look like:
Hello there,
I’m sorry for the long absence, but I’m still interested a lot in volumio v2, just that I’m not sure when I can start to code again!
Anyway, I was reading those posts, and just wondered: is there a consensus on abandoning the current volumio look & feel? I’m thinking more especially about the playback view, with those 2 round controls for volume & seeking. I must say I’d be a bit sad if it’s abandoned, because I think that’s something that really make the difference with the other players we can see here and there (well, excepted runeaudio of course). That’s what makes people saying “waw it’s so cool!” when I show them Volumio. So I was wondering, is it a will to differentiate from runeaudio, or just because you want something new?
Some ideas on the interface:
- Available view
– 3 default views: browse [local / mounted files], playback, playlist
– any number of “plugin” views: browse spotify, library, and we could imagine other views to present data differently, like albums cover smart browser (itunes-fashion), spectrum analyser (look at this! codepen.io/swys/pen/nxzpD ), etc.
– other spotify concurrents such as jamendo developers.soundcloud.com/docs/api/sdks
Each view could be enabled / disabled through settings. And each view can have its own settings.
Now, hamburger menu Vs. tabs : I personally prefer the tabs, even if they could be presented differently than they currently are. For the same reasons mentioned in this article : techcrunch.com/2014/05/24/before … kills-you/ . Especially because tabs let me know at any instant which views are accessible, and they’re just one click away.
But why not implemented both designs, and leave the choice to the user in settings?
One more thing I thought about: the current sqlite database is very lightweight, we don’t have tons of data to put into. Why do we bother requesting SQL? Why not just reading, a json file from disk at startup, keep it in memory, and overwrite it when necessary (that is, really, not often!). It’s human-readable in any text editor, and javascript-ready without any need to an external module (if only node’s read/write io)
Hello,
I think that we really have to consider using Volumio from a smartphone, with a (rather) small and vertical screen.
Welcome back Joel! 
We don’t necessarily have to abandon the old Volumio look! I figured, however, since we’re starting fresh, it’s worthwhile to explore some different UI options as well. Balbuze also has a valid point about mobile display. Here’s more of my two cents on a layout which can adapt to different screen sizes (that’s not a hamburger, its a playlist button 
).
Regular:
Library View:
Mobile:
Watch:
Large Screen:
(library browser operates like the OSX Finder)
Yes I like this idea to have customizable views!
I’m currently trying out LevelDB for the music library database. It can store and retrieve javascript objects directly (encoded as JSON on disk)! 
Interesting 
I couldn’t find information about memory usage: does it require a daemon to be running on background (like 90% of dbs) or is it daemon-free, like sqlite?
BTW my proposition was also to support easy manual editing through files. I understand from leveldb readme that it’s compressed, so not easily editable. We could use leveldb for “large” scale storing (library db, tagging, etc.) and json files for light configuration, what do you think?
Nice screens It would be nice to compare without black borders, for flatter design
I don’t think LevelDB needs a daemon, if I understand it correctly. Ah I missed the part where you mentioned readable files earlier. That’s a good idea, and would definitely help for config storage.
Here!
Nice, I think I prefer this version! After reflection, finally I agree it’s better to remove the volume knob.
I like this layout but there’s some missing info / actions compared to the current (song info like bitrate, playlist position, social sharing, random/repeat modes, textual elapsed time / total time). Of course it would be difficult to fit all that on a smart watch screen! But people used to controlling everything on larger screens would be loosing functionalities.
Would you guys be ok to set up a conference call, so that we can set out arguments and decide what we do?
We would need answers to:
- Which techs will we use (or I missed something, but this is still under discussion, right?)
- Layout / general design
- Views
(this is at least for the front end)
Sure, I’d be down to teleconference. I’ve got Skype.
Welcome back Joel!
So, my points:
- I was thinking as well to use light text as configuration storage. This will make config backups super easy, and it brings a lot of advantages.
- As per the db, another option could be redis (but it requires a running daemon , which we don’t want…)
- And yes, a common call would be ideal, what about tomorrow at 6pm UTC ( 20 italian and french time, and I guess 11 cal time). Or let me know what suits best yout needs later in the week.
- About smartwatches: let’s keep em last in our wish list. The way they are designed makes using a webui useless, it will be way faster and more usable to have a wear app for volumio. (they work on notifications, and browsing is quite impossible. I own a moto 360 and spotify works like that…).
We’re on the same line.
About leveldb, it really looks like a good alternative to sqlite. You can read this for instance : jeelabs.org/2013/09/27/leveldb-mqtt-and-redis/ ; apparently, the author tested it on a raspberry pi (see latest paragraph).
For common call I suggest a doodle doodle.com/fr/
Would you guys prefer weekends or weekday?
I am abroad for work. what about doing this Weekend, or friday?
I’ll set up a doodle for that…
Created the poll:
doodle.com/2tghwnigf4rccf6c
I emailed to some of you, didn’t have the email of anyone, but just clicking on the above link will get you trough!