This is really nice. Would you mind chatting with me sometime? I'd love to pick your brain or even just converse with someone who has similar interests. I've spent the past two years developing Streamus, https://streamus.com/, an open-source music player which runs off of YouTube as a browser extension; it has 130,000 users currently.
Really cool idea. Who hasn't thought of doing this before? Congrats on actually making it, and making it look beautiful. Already forked it, can't wait to start playing with it.
I don't see any mobile screenshots, how does it look on a phone screen? I can imagine that being a great use-case for this app.
Congrats on the design, but it's sad to see that once again, the wheel has been reinvented: there once was playdar [0], the content resolver that clearly separated the data that was of interest to the user (artist, song, ...) and the actual sources. Its biggest problem was, I believe, that it wasn't an actual music player.
Its gentle folks decided to restart from scratch with a music player in mind, and keep the idea of having different resolvers to target different sources, such as local disk, youtube, spotify, radioshark, ... Really, if you know javascript, you can write a resolver targetting the platform of your choice. The end result is Tomahawk [1] and if you're interested in that you should have a look.
Maybe it didn't spread because it's not a webapp ?
>Maybe it didn't spread because it's not a webapp ?
I think this is it. I remember checking out Tomahawk a while ago, about the time Songbird announced it was discontinuing development. I ended up just going back to iTunes because it did all I needed (even if it is bloated). If I can install Tomahawk on a computer, I can probably install my music library onto it as well, so I don't need the resolving features it has.
I actually just tried installing Tomahawk because of your comment, and it does work very well, and looks pretty while doing it. It was able to find several obscure artists with perfect accuracy. (Though it did grab most of them from Soundcloud at 128kb/s, when a few of them are on Spotify with higher bitrates). But unless I can access it anywhere, with a moment's notice, I don't really have a purpose for it being installed on a machine.
I rarely even listen to music on my computer anymore. I use my phone for Spotify on the go and even at work. It's nice to not have another program running while I'm working. But a lot of artists I like aren't on Spotify, and my phone doesn't have enough storage to fit my entire library.
That's why this interests me so much. I would love to set up a server where I can open the URL on my phone, laptop, friend's laptop, etc, be able to play most of my music through web services, and the artists that aren't on those services would play from my server directly, or my DropBox, or whatever, and hopefully it can all be a seamless experience.
Thanks! I'm pretty sure though that I'm not the first one nor the last one to have ever thought of that :D
The design is fluid but not really responsive. What I've been playing with is remote control that worked great on mobile devices. You were able to control all of your active CloudTunes sessions from any connected browser. So you could for instance play music on your computer, and control it via your smartphone (just like the iOS Remote app from Apple can control iTunes, except this worked over the internet so you didn't need to be on the same network). It was a very crude prototype though so I didn't include it in the initial release.
Also I was just wondering if it has a mobile component, guess I hadn't thought of that....I could play music on my computer no problem, it's on my phone that is ideal :)
I don't think he's the first to think of it, but definitely one of the few who actually built it, I started once a while back, but never got very far...LOL
I didn't see any mobile screenshots, or much code that seemed responsive, so I assumed it wasn't mobile friendly and wanted to try fixing that. And the comments below about it supporting Dropbox, but not music stored on the local server (and the tips from OP about how to implement it), is another goal I'd like to tackle. I don't know if I can implement these, but I'm certainly going to try, and I'll learn a lot in the process.
Also I've had this idea a million times before, but never committed to doing it, it's the kind of product I've always wanted. So seeing it on GitHub (and written in a language I'm good at) makes me really happy, and I'd love to tear into this thing.
Edit: Also it's very pretty, and I'm a sucker for anything with a pleasant UI like that.
Could this support playing music from S3 and storing/reading metadata as S3 headers? I currently store about 200GB of music in Amazon Cloudplayer, which has recently gone sideways with their push towards Music Prime. I'm currently ripping all my music out and putting it into S3.
I've tried to use subsonic and madsonic (a fork of subsonic) before. I didn't like either of them much nor did I like the phone apps to accompany them (many are paid apps as well). I'm gonna look at this project tomorrow and see if I want to undertake a server port. I think it would be viable.
Agreed, the mobile apps are mostly ugly or abandoned and the server software itself still uses a flash player. It's just something I put up with because there's no better alternative at the moment.
I'll see what I can do about it ;)
I just found this from some of the comments above http://ampache.org/. I'm gonna install that and see how it is, but I really think I'm going to move forward with trying to integrate this with a seedbox type of server. Since the client is done in JS as well it could be practical to port that to Android and iPhone also.
Wow, really cool. Since you're already using brunch [1]. You should checkout chaplin [2]. It's a backbone framework built by the same guys who made brunch. It supports coffescript, pub/sub, dynamic url construction, plus a bunch of other features that make working with it a breeze.
Thanks for the tip. I actually did originally start with Chaplin. It helped me to start quickly, but later I replaced it with a very simple, custom Backbone-based MVC (Chaplin-inspired to some degree).
Interesting... you mind explaining the reason for switching? If it was missing functionality, I'm sure the team would appreciate pull requests. I'm often dismayed that angular is grabbing all the spotlight these days and not many new web apps use backbone in general or chaplin in particular.
There is a tradeoff between speed of development and degree of customizability when it comes to frameworks. With CloudTunes, I was going for a highly-customized and performant UI, and at some point it simply became easier to go back down by one layer of abstraction and build it just with Backbone instead.
Really cool. At first glance it seems to me like there might be two products/services here - one that is what you have here minus YouTube and other publicly available media sources, and another centralized web app that provides users access to all public media without having to run their own server. Maybe they could be integrated in a way where users can add their own media sources through the centralized web app to have it all in one place.
I've always thought it might be interesting to have apps like this that run locally on web technologies. Is there hope for this model? One obviously shortcoming as exemplified here is the painful installation process. I suspect people are also going to be concerned with what's being installed where.
I'd been planning on releasing it together with a Dockerfile so that people could easily run it locally in an isolated container. It turned out to be a bit more complex than I had anticipated so Docker support will come later. But I think that could be a viable model for locally-installable web apps in the future.
I definitely second this. As we move towards multiple devices with predominantly flash storage, the device should be responsible for serving the content rather than storing it. The more we can move towards these types of apps, the better.
there is if we can agree on a base tech (node.js for example), an app store model, and the environment is sandboxed. this would let people produce apps that would work everywhere - from raspberry pis to pcs to macs.
also sadly, some sort of drm should probably exist.
That currently is not possible, but wouldn't be very difficult to implement as I had it in mind from the beginning. Inspiration could be the Dropbox integration:
Nice work! I personally use ownCloud (which has Ampache support) for my streaming of my library, but this is a really nice job. I might see how hard it is to integrate into ownCloud :)
For the love of possible users, put some sort of scrolling indicator on the page. Firefox in OS X doesn't show scroll bar. I spend about a minute clicking on the slant phone and the name in the top right before accidentally causing the page to scroll down.
It's not running anywhere right now, sorry about that. That is because the app is not really ready for public production use. As mentioned in the README, I've kinda stopped working on it some time ago. I think it could still be interesting/useful to people who want to run in even in this state by themselves. The codebase also hopefully has some interesting bits, so I've at least opened it up for now. Another thing is that the backend talks directly to the Musicbrainz API, which is throttled (their DB is open though, so one could make a web service on top of it).
These comments make sense from end-users but I feel like they're out of place on HN. I mean, sure OneDrive & GoogleDrive support can obviously be implemented down the road, but especially when first showing the idea off - it's way easier to keep it simple and get feedback to improve the product and then later integrate with more services.
These comments remind me of the few apps I've put out that start with an iOS version so we can collect / data & feedback so we can make future versions (on both platforms) better, but that info almost always gets shouted down by chants of "why not an android version?" The obvious answer of "it costs 2x time and resources" to get the first version out, almost always gets completely ignored.
Let's give feedback on this version - help him improve it & then worry about the other service integrations later.
I don't think it's criticism, it's just not the most useful question they could be asking at this point in time. If he's showing off a new project - I think it's probably best to help improve what he currently has now and then worrying about the integrations later
Consider the perspective of someone who has never heard of a new piece of software before. They just want to know a bunch of things about it, so they can form a concept of it in their mind. This is one such question.
I don't disagree with what the author's focus should be, but I don't think that this question distracts from that.
I am a developer, I haven't dug into how he was processing the audio. I was simply asking a question. I don't use Dropbox so I was simply asking if it was on the roadmap so I could try it in the future.
When I was looking at Google Drive API some time ago, it didn't—unlike the Dropbox API—support byte serving (partial requests). That is needed for efficient indexing of MP3 files without having to download them first. It may have since changed though. Otherwise I think it would be pretty much analogous to the Dropbox integration.
YouTube now defaults to using the <video> element unless the video would show an advertisement. In those scenarios, it falls back to using the flash player.
Plex however relies on you either have 1) a good home connection (with no caps) or 2) a server "in the cloud(tm)". Dropbox provides the backend hosting, which makes providing the data files easier.
This is really nice. Would you mind chatting with me sometime? I'd love to pick your brain or even just converse with someone who has similar interests. I've spent the past two years developing Streamus, https://streamus.com/, an open-source music player which runs off of YouTube as a browser extension; it has 130,000 users currently.
Hit me up if you want to chat! admin@streamus.com and if you'd like to browse the repo, https://github.com/MeoMix/StreamusChromeExtension