What's funny about having to rely on unauthorized clones to provide a fast native UX was that Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.
Few Apps ever had that wow factor the first time I used it, it was so much lighter and more responsive than anything else of the day. I remember being perplexed at how I could search and skip to any part of a song quicker than iTunes could looking at a local library. Everything was latency-free and instantaneous.
We were building a Music Startup at the time, so we investigated how it worked. We we’re very surprised we couldn’t find any evidence of an established UI toolkit. It looked as though they had built their own custom UI renderer and optimized TCP protocol which sent back its metadata in XML. Their traffic looked like it was initially seeded from their own (or CDN) servers (for best latency) and then overtime we would see some P2P traffic on the wire.
Our QT/C++ client had decent performance but was noticeably heavier than Spotify's. I was disappointed to see their native client eventually be abandoned and succumb to become yet another Chromium wrapper. I expect it fell to the pressures of a growing startup adding 100s of developers (without the skill of their original CTO/devs) where a native UI couldn't be updated and re-iterated as fast as a Web App. I wish they maintained 2 desktop clients, and left their native client alone to just be an audio player and push all their new social features to their new flagship CEF app.
It's unfortunate the skill and desire of building fast native UIs are being lost to Electron and CEF wrappers. Seems the larger the organization the more likely they are to build new Web rendered Desktop Apps and we have to rely on unauthorized Indie efforts like this for fast, responsive native UIs.
Something that Chromium apps do give you however, for free for the most part, is accessibility. I just tried the GUI version of this client and was not surprised to find out that I could not use it.
The new Spotify UI released a few months ago is the most accessible Spotify has ever been. Landmarks, clear labels, headings, and even aria-trickery to automatically announce things using my screen reader. I remember being very frustrated with the old UI's to the point where I chose another service just because it was more accessible, even if it didn't have a desktop app. YouTube Music and Deezer had much better UI's from the get go.
At this point, I'm almost happy to see an Electron app. It doesn't guarantee accessibility, but the likelyhood is so, so, so much higher than any modern cross-platform UI framework.
I'd almost go as far as to not call these UI's native. Because if they were, if they used native controls, the accessibility would be there. The OS vendors spend a lot of time to make them usable and consistent. Sadly, these UI frameworks don't, or can't.
Sure, psst has a CLI, but I only get panics. I can't do -h to find out what I can do with it, I can only call it with a spotify URL and get it to play and exit once it's done. It feels like the cli was included as a sort of testing tool to check the underlying libs and code, and not as a usable version of the app itself - but it's still very early in development so the GUI might be the same. I can't tell.
Here's how these things usually go: first, you start small. You build something you can show other people. You try to generate some traction and build interest around your idea, validating it at a very small scale (friends, family, "Show HN", etc). You gradually expand that cycle of people. You get into a routine of iterating on improvements, adding new features, and gradually scaling things up. You probably get a couple of people to join you on that journey, because the more popular your product becomes - the more asks you'll be getting, and the more work it takes to scale it out. Rinse and repeat.
The reality is that we can't expect every single hobby project to support every single use-case from day one. Painfully for all - the current state of things in this space is such that building accessibility into your product is not trivial and hence it gets postponed "for later".
Now, on to a completely honest question: why don't we have screen readers that can consistently translate the "visual" version to a version people with visibility impairments can understand in a more generic manner, without requiring every single piece of software to adjust itself to every single flavor of a screen reader? I'm honestly asking why can't we solve the whole problem by offloading it to the screen reader itself. Can we solve this by simply offering a text-only command-line like version of every product? (ie. as opposed to building "beautiful"/"designed" experiences that get downsampled by the screen-reader anyways)? Sort of like building a sitemap.xml file that lets the user with a screen reader do everything a user with the full-blown GUI can. Sounds like an opportunity to create a cross-industry standard?
Edit: getting downvoted for comments like this is why I'm honestly considering just closing my account and not participating in any more such conversations going forward.
Hi, the author here. Psst is definitely in alpha, and the CLI is indeed just an example (it's what I was using to test the core mechanisms). I'm sorry the accessibility is so bad now, but Druid, the GUI library, takes it very seriously -- which is not very common in custom GUI frameworks. So, fingers crossed, it should get better soon.
Re. command-line Spotify clients, there is ncspot[1] and spotify-tui[2], and if you use Linux, Spot[3] looks like a nice GTK experience.
This is, unfortunately, a very common occurrence when GUI frameworks are concerned. For some reason, framework authors like to mislead and say that their framework is native, when it looks native but actually isn't. WX and SWT are the two notable exceptions here, they do indeed use native OS controls.
If you want to use a native GUI framework because of accessibility, check if it's as native as it claims.
I honestly think we need to rethink accessibility from the ground up. modern advances in OCR and machine learning should allow us to do accessibility entirely from the GPU output.
it'd take awhile to perfect but i think it'd ease the burden tremendously for software developers and those who need accessibility.
If you are interested in their story how the original client and architecture came to be and then how it changed to what it is today they have a podcast you can listen to: "Spotify: A Product Story" - https://pca.st/cbo7khrm
Just finished listening to this, thanks for the recommendation.
They spend some time interviewing Lars Ulrich of Metallica in the context of of the Napster lawsuit. He comes across in this interview as still upset at Napster for what they did, and he is at turns indignant and also emotionally wounded at the fact that they are perceived as the villains in the story. In particular he cannot seem to reconcile his belief that they, and I quote "are the most fan friendly band on this planet" with suing Napster for $100k per download in damages, a ludicrous and arrogant sum. I am not a Metallica fan and do not listen to their music (out of disinterest, not antifandom. Metal isn't my genre), but it is striking to me to see how 20 years on they still don't get it.
Thanks! It's great to read the backstory of how the original Spotify client came to be:
> "Not to go into too much detail here, but at the time, most of the internet was made up of “thin clients,” like web pages or Flash-based clients that ran in-browser, and used more traditional, standardized protocols like HTTPS. Seeing the limitations of that, Ludde and a team of engineers ran in the exact opposite direction, creating a stand-alone “fat client,” building entirely new protocols and hybridizing client-server and P2P technology to suit their own ends. (Check out Episode 01, “How do you steal from a pirate?”, to hear more of that nitty-gritty stuff about persistent TCP connections and how our P2P implementation saved us bandwidth cost.) It was only by rethinking every layer of our infrastructure that we were able to pull Spotify off, to create that magic moment of double-clicking on a new song and having it instantly play. And speaking of magic …"
Having been an early user of the beta I presumed it had to be driven by people with this mindset from rethinking everything from bottom up to provide the best UX possible, would really love to read more about the technology used in the original Desktop client?
EDIT: Currently listening to “How do you steal from a pirate?” which is providing a more detailed backstory on the origins of Spotify:
Sounds like Ludde Strigeus, the creator of µTorrent was the key hire to make the original Desktop Client UX possible whose Desktop & P2P expertise was able to convince the rest of dev team to go down the path they did. Some interesting insights, they used Ogg Vorbis instead of mp3 using a custom designed TCP protocol because they were better able to strip packet bits down to transport just the audio bits required for playback.
> Michelle: The thing that happened that was kind of pure magic in that meeting was that [Daniel] did a comparison. He started playing a song on the software, and the song played so quick, so instant … I mean, I don’t know if people remember, but playback was slow back then. Even if you had an MP3 on your computer, and you played it via, you know, Winamp, iTunes, this was faster. And we were like, “You have the files on your computer, right?” And he was like, “No, it’s in the cloud.”
I had the same initial experience where I was blown away at how instant and responsive it was, at first I didn't believe it and thought it was doing some sort of pre-caching magic where it'd start downloading before selecting each song. So ran lots of tests where I did first time searches and immediately scroll to songs down the list of search results (to bypass any caches) and could see that it was indeed pulling traffic in real-time, the time from click/scrubbing to audio playing was just unbelievably fast.
I guess much that did the first client light weight was because it was developed by Ludvig Strigeus. He devloped the very light and popular uTorrent client. Very early for Spotify they bought uTorrent AB, not for the uTorrent client, but because they wanted his skills and he was the person that developed the first Spotify client. A few month later Spotify sold the uTorrent client to Torrent Inc.
Ludvig Strigeus is a skilled developer and have got many awards, like the Polhem Prize which is a Swedish award for a high-level technological innovation or an ingenious solution to a technical problem. If I recall correctly, he is very good at writing very small and optimized c++ programs, but the code is very hard for others to understand and maintain. So I guess when Spotify become bigger and more developer needed to work with the code they needed a more "main stream" solution and had to abandon the first client.
The early versions of uTorrent were on the order of 80KB in size, it really was amazing. BitTorrent the company re-skinned it as BitTorrent the software and offered both versions for a few years, differing only by icons and colors, but fans held to strong opinions about which was technically better.
It is true that the code was hard to maintain and extend though.
The problem (or rather value proposition) is that the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability. Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app, especially given they just want to listen to music, which the app does just fine. If people specifically don't like the social features, they'll be mad at the decision to implement those social features instead of 'what they used for the tech stack' since ultimately Spotify could have developed the same features in a native app with just a few extra weeks of sprint, if that.
The outrage around these supposedly egregious performance issues is more understandable when you consider that developers who spend a lot of time tuning performance in their work would naturally develop a 'selective attention bias,' magnifying the significance of what to others are negligible if not imperceptible differences.
Imagine the frustration of someone who, for example, did work on sound insulation for cooling systems: they sit out on a patio for dinner with friends and the sound of an inexpertly designed air conditioner appears to them as intolerably intrusive; meanwhile, no one else at the meal notices until it's pointed out.
The Spotify website and phone apps don't just have performance issues, they have awful bugs that have been left unfixed for months/years. When streaming to a Chromecast, the UI quickly gets out of sync, randomly disconnects, etc. I'm resorting to using a bluetooth receiver connected to my amplifier because that works better. The recommendations are also getting worse IMO, though that's more subjective, hard to quantify, but the amount of time I spend using Spotify has gone down a lot, just because I'm not discovering enough interesting tracks anymore.
IMO, Spotify is neglecting its core features, and that will ultimately hurt the platform. However, there is such a thing as network effect, and they may have the broadest selection of music. That will keep the platform growing, up to a point. Eventually, the growth numbers may peak and slow down. It's just that there's a lot of inertia right now, and the growth is still going upwards, but eventually, gravity might catch up.
> Most people don't care that it takes an extra 10-100 milliseconds
I probably wouldn't care about it too much if they didn't mess up the rest of their apps into the dogturd that they currently are.
Doing bad UX is one thing, making UX consistently worse with pretty much every update another. And that's what Spotify has been doing for years now - if I could go back to a client-version from a few years ago, I would, immediately, without thinking twice.
The fun part? My company jumped on the SAFe-train a while ago, and Spotify was heralded as the "prime example" of where agile and all that works out really well.
I have no idea what they are doing, but whatever it is - if they continue like this, I'll go back to pirating music, because they're getting really close to having just-as-bad of an experience as that. And I really don't mind paying 20 bucks for my family account; experience is all I care about.
Users do notice speed issues in apps and websites.
The NNGroup has done studies with users to gather reactions to slow websites in 1997 and 2010. They remain relevant in 2021 to both apps and websites: "Users really care about speed in interaction design" [1]
A few weeks ago someone on HN shared the reflections of the developer of SumatraPDF - a native Windows PDF reader that is small, lightweight and performant (all the things that Adobe Acrobat Reader is not).
From the developer Krzysztof Kowalczyk: "I believe being small and seemingly fast was a big reason for adoption...there will never be a time when users want bloated and slow apps, so being small and fast is a permanent advantage." [2]
Generic statements such as "most people don't care [...] extra 10-100ms for the UI" need to be supported by evidence, especially since those 100ms are added to existing latency and 100ms is considered the threshold where operations feel instantaneous [1].
Still, for certain things 100ms is too much. Android famously had a round-trip audio latency of a bit above 100ms which made it a poor choice for music apps - in contrast to iOS. They now require 20ms in the Android Compatibility Definition Document and admit that musicians require 10ms [2].
In addition to that, hitting the 100ms threshold doesn't mean that lag is not noticeable or not annoying. There was an article about keyboard lag posted on HN a while ago, and the top comment was likewise interesting: https://developer.android.com/ndk/guides/audio/audio-latency
Search is just so basic, you can not have any typos whatsoever.
There is no proper history function. Say you start a radio, it only remembers that you started a radio but if you come back to it you probably will not have the same songs.
Connectivity is piss poor. If you lost connection you will have to restart the app otherwise you won't be able to use search.
While this is about the native desktop client, I assume it has similar problems so the argument that it is only a couple milliseconds of latency doesn't hold up. Their UX is the worst I've ever had to deal with in a music app.
If we followed similar arguments about hardware, we wouldn't have Apple today. The entire premise of Apple's hardware is that it is beautiful, well designed, with attention to details even in places where the user would never interact (motherboard layout and finish).
You might be guessing from intuition that 10-100ms latency doesn't matter, but I suspect that it does. You can feel the philsophy of the company when you use their products and they feel wonderful. It's a culmination of attention to detail in every aspect of development. I love Sublime Text precisely because of how fast it is.
I disagree with the assessment that an extra 10-100ms doesn’t matter.
How pleasant an app is to use does affect a user’s perception of an app and product even if they can’t articulate it. Fit, finish and polish do matter.
Myself and every (non-technical) user of Spotify I know complains about the horrible mobile and desktop apps.
The android one is an absolute dog, even on mid to high end smartphones.
If you neglect your core features in exchange for pointless trinkets you're setting yourself up for failure.
The first alternative to show up with an equally vast catalog, but a light and fast interface is going to win a lot of customers in no time.
Remember this is streaming: there is no friction for me to switch. I export/import my playlists and it's done.
I have one of the fastest laptops (Apple M1 MacBook Pro) and now I opened Spotify and it was just a black screen for about 1 minute before it showed anything. Then it started.
> Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app
You can tell this is true because people keep complaining about it, and developers keep reminding us that we don't actually care about how slow apps are.
The problem is that the people with decision power over software are usually not the ones who actually use it and latency issues are more of a subconscious thing. Slow programs just feel less good to use until they reach a pretty high threshold where it feels unbearable.
For speed good enough is just very far away from good (factor 10-1000)
The stability of Spotify is awful, I use Spotify to entertain my kids in the daytime and put them to bed at night so I’m a heavy user. Connecting to external speakers through Connect is very unstable.
The thing that keeps me on Spotify is that I’ve invested a lot (but not insane) time in curating my playlists. If I was guaranteed a high quality experience with a competitor I would make the switch but I’m not going to make the switch just to find out that the competitor also sucks.
The problem is it's only 10-100 milliseconds when my computer is otherwise unloaded. When my machine is under high load that turns into several seconds.
> the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability.
I think here it's more accurate to say, "the business' impression of the end-user's perceived value".
Because a snappy user experience DOES have real value; in web we are very conscious that milliseconds cost viewers in load and response times. It's well documented that brand positivity is connected to load and response times.
But users don't know to tell you that until the performance gets REALLY bad. Consequently it's hard to get this value from a user survey, and hard to communicate internally as a value prop. Capabilities are much more business process friendly.
> Most people don't care that it takes an extra 10-100 milliseconds for the UI
TLDR: up to 100ms latency is fine, but alongside higher RAM usage, and when applied to all programs across your machine (not just a single app), hell breaks loose.
I entirely agree with this statement. However, most people don't have a high-end machine like the developers test on, and actual difference in latency between an electron app and a web app may be over an order of magnitude larger.
The problem is in many parts of the world (including in poorer communities of the global north) people rely on second-hand hardware which even in 2021 typically has 1-4GB of RAM, so a single application taking hundreds of megabytes when not over a gigabyte of RAM will quickly lead to you swap hell and render your entire machine slower.
Despite being an ardent GNU/Linux user, I believe the linux kernel OOM is close to the worst that can be done in this matter (although there are certain progresses with eg. earlyoom), but MacOS and Windows are certainly not immune from it. You'd be surprised just how much people avoid using their computer altogether when they don't absolutely need it, just because it's slow as hell, just because developers in their ~ivory towers~ offices didn't do testing on reasonable second-hand hardware.
Spotify has certainly degraded over time.
My latest frustration: Controlling external devices via my computer or phone.
I'll often play from my phone and connect it to my Echo speaker group. This used to work so seamlessly - it was beautiful.
But now - it takes 10 seconds for the initial connect. If I hit play/pause there's a 5-second delay to the point where I'll tap it twice, which is also delayed, and then it'll stutter and jump around. And worst of all: I'll hit pause, come back to it in a few minutes, and it's completely disconnected.
One of the big (for me) issues with the old, native client was accessibility, or the complete lack of it.
As a screen reader user, I couldn't use Spotify at all before the Chromium client was released, first in beta and then in stable.
Spotify's desktop accessibility was... passable, but far from great. It improved massively with the most recent UI redesign, which is almost universally hated by sighted folks.
This is a pattern I see pretty often, Reddit is another great example. Old Reddit is almost unusable to me, the new one is a massive improvement.
Rdio was great, but it could not compete with Spotify’s performance. The funny thing is, those performance advantages (p2p streaming and a native C++ desktop client) are now ancient history. Rdio was ahead of its time.
Additionally Spotify's original app came out at the time iTunes was (is?) a big bloated mess, especially on Windows.
When Spotify came along it felt like a breath of fresh air, light, nimble, instant playback. Obviously the streaming approach was a departure from the older way, but it just felt so much better to use.
Such a shame they seem to have lost their way with the browser based thing.
> Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.
I think time is a large contributing factor. A lot of things start off simple and elegant. Then you have to come up with new features year after year after year (how old is the product?) in order to not appear stagnant and keep customers happy. "Oh, this other app got x feature, I want this in the app I use too!!!"
Here's kind of a video to illustrate the point, where Rick talks about iTunes. How it used to be, and how it evolved and is now. iTunes once ruled the world. It was simple, and elegant.
Spotify removed a lot of their great social features from that time, as well as Spotify apps. Almost everything about Spotify has gotten much worse except the reccomendation algorithm.
Didn't downvote, but can you name a couple of Electron apps that are sna...,hell,.. not sluggish?
People usually point to VSCode...If that is the epitome of a responsive, lag-free software then I claim Electron defenders haven't seen snappy application.
Maybe try elaborating yourself? The constant criticism of Electron Apps is that they're bloated and slow, you're claiming otherwise but missed the part providing any presumption of evidence to the contrary.
I've yet to experience any Electron App that's close to the snappiness and UX of the original native Spotify client, I'd like to hear about good examples of Electron Apps comparable to it.
Up-voted for the same reason as the edit - I'd love to hear some fact based arguments why this comment should be down voted (why it's not possible to build performant applications with Electron)
The original Windows and Mac clients didn't use Qt, it appears the Linux version released after did. Here's what I found scouting quora:
> Qt is only used on Linux. The native parts is built with our own custom toolkit on top of a canvas- and window-abstraction layer. The canvas/window stuff is implemented with Qt on Linux, but with native stuff on win/mac. Then we have the HTML5 views, which use Chromium Embedded Framework.
> Proprietary technology written in C++, C and a tad of assembler. A list of third party technology used can be read by going to Help → Show Licenses in Spotify, or by opening file://localhost/Applications/Spotify.app/Contents/Resources/licenses.xhtml (if you're on Mac OS).
One thing that has devastated me about recent Spotify updates is that now, when viewing an Artist, you do not get to see all of the albums (or at least the first 10 newest albums) for that artist straight away with all of the tracks listed. It's now much harder to find a song that you don't know the title of, but you know an artist has sung.
It's also small changes that are extremely annoying. Pressing "New Playlist" used to come up with a dialog box asking what the playlist should be named. Now it just gets called "New Playlist". Clicking the playlist name to rename it does not automatically select the textbox to give it a name, meaning that to create a new named playlist - an action that used to take one click, is at least three clicks and two keyboard presses... I mean, come on Spotify!
The search bar used to always be visible. Now I need to click search first, then click the search bar.
To me, Spotify was the epitome of software completion five years ago. The client worked. It was perfect. It seems like every single update since they released the "Daily Mixes" has both downgraded the performance of the app, and made discoverability harder. I want Spotify how it was 18 months ago.
Spotify on my machine sometimes chews up 2GB of RAM. Reached out to support, and the best that they can give is "try restarting the app". That helps, until 12 hours later you need to do it again. A music player should not have 10% CPU usage on a modern MacBook.
I'd pay handsomely for an app that did discovery on tracks and not artists. Last.fm kind of but not really does it. It took me many years to get from Sirenia: Seven Sirens And A Silver Tear to the Midnight Sonata (I can't remember alas who did it -- was it reddit or a forum on a now defunct tracker? all the great trackers are dead) and from there I was able to branch out. But this shouldn't be so hard..? We already have several music matching apps, surely closeness is a solvable problem.
They really do make things worse and worse and worse. Related to your playlist example - saving an actual album I liked as a new playlist would give it a default title, "artist - album title" or something like that. Fine, 2 clicks: create the playlist, and accept the title.
Now? A blank text box. "Let's ignore the artist and album this user's basing a playlist on and make them type the whole thing from memory". I just don't bother any more, which seems petty but it's just so cumbersome, from mobile especially.
I have also noticed this. There isn't even a way to see songs, you always have to go to each album. I don't remember the album! Or the name of the song!
I wonder if some of these decisions are driven by their business model. My understanding is Spotify's agreement with record labels means they have very low margin on a typical song stream. I've heard that some of their playlists are very valuable for artists and that there's some payola going on there. It could make sense that they're nudging people in those directions.
They also see much more upside in podcasts and thus are pushing people there.
An album is (ideally) carefully crafted to work as a coherent musical statement. Tracks in isolation don't have the same effect. It's even more so in classical music, where a work usually encompasses multiple tracks. One of my frustrations with Spotify is that it doesn't understand multi-movement works, so you get an single movement — sometimes even one that is connected to the preceding or following one — in isolation, and it's often really unsatisfying.
tl;dr I think albums have more significance than you do.
I just checked Spotify, and it seems like yes, it does now get focused automatically, not sure if it was always that way, or I just feel that I need to click the textbox after choosing the menu item on the left hand side.
That being said, it was still much friendlier to have a search box that you could click on straight away. From a UX perspective, you need to move your focus away from where you have clicked, because the textbox is in a different area of view.
Clicking back on the search menu clears the search that you were doing. It's fine, you can click the back button, but the old Spotify client (iirc!) would keep your previous search in the search box.
At this point, I'd be willing to pay for a Spotify client that works exactly the same, but just ignores the existence of podcasts entirely. I use a dedicated podcast client when I want to listen to podcasts, and they keep shoving them in my face and taking up precious UI real estate everywhere.
But any client without support for Spotify Connect might as well be dead to me. Controlling my wifi speakers from my phone, or playing music on my desktop Mac from my laptop or gaming PC is critical functionality at this point.
Check out spicetify cli[0]! It patches the Spotify (desktop) client and makes it better. It also adds support for extensions, one of which[1] disables the podcast features. I haven't used the extension so I'm not sure how well it works.
Heads up though, the original developer is MIA at the moment and the latest few versions of the client are incompatible. There's an effort by someone to fix the issues and there are other maintainers who mostly just seem to address PRs. Personally I just downgraded the client and it works perfectly.
If you’re on Windows, you can define audio input and output devices on a per app basis through Windows’ settings. Handy for any app that doesn’t support such configuration (though Spotify obviously should.)
What platform do you mean? The iOS app lets me select output device. It’s a little icon next to play/pause, kind of half computer screen half bookshelf speaker (monitor/monitor :)
I think I remember seeing this on desktop too but at that point why not use the OS sound mixer?
Came here to say this. It was hard enough losing Rdio and now Spotify has been on a rapid decline for the last 1-2 years. It used to be a place to listen to music you already knew and maybe find something new and now they do nothing but shove podcasts down your throat. Who that works there is looking at the current UI as an improvement?
I can't wait to sit my grandchildren on my knee and tell them stories of the magic headphones that you never needed to charge and just worked instantly with practically any audio device ever made by mankind right up until the iPhone 7 was unleashed unto the world.
Yep; I'm a paying customer of spotify and I like some of the podcasts they have. But they don't have the gap removal + speed controls of Overcast (my fav podcast program on my phone). So I'm in this weird situation of never wanting to listen to any podcasts through the spotify app, which I'm paying for. And then when I want to listen to music (eg while coding) I have to wade through podcasts which are intentionally designed to blend in with music recommendations in spotify's apps.
I hate it. If any spotify PMs are listening:
- If spotify wants me to listen to podcasts, let me do it from my existing podcast app. I'm sure the developer of Overcast (and other apps) would happily add a spotify login button for a song if you ask nicely and offered to pay.
- Let users disable podcasts entirely in the spotify app.
- In the spotify app, give podcasts a consistent visual differentiator so I can easily visually separate them from music. Nobody wants to be tricked into listening to a podcast instead of music. Maybe make the "album cover" for podcasts a rectangle instead of a square. Or change the background color for all podcast related content to blue so I can find podcasts visually (or filter them out visually) while scrolling.
If you care about Podcasts, don't listen to them on Spotify, ever. Spotify's plan is to build a walled garden around them.
Spotify promotes podcasts and buys exclusives so desperately, because their plan is to grow their audience to a too-big-to-fail size, so they start dictating their own terms. Every remaining use of RSS is a business opportunity.
It’s insane that Spotify on Mac doesn’t support airplay.
When my girlfriend and I moved in together, we got rid of her Alexa devices because privacy and use HomePods. But Spotify doesn’t work with AirPlay for reasons I cannot fathom, so I set her up with a program that will AirPlay specific applications on her Mac.
That said, there are open source libraries and clients for AirPlay so it shouldn’t be too difficult to get them supported. I have a Raspberry Pi for streaming to “dumb” speakers.
Airfoil [1] is worth every penny. The same could be said for pretty much everything Rogue Amoeba makes.
It’s also worth noting that Spotify can act as a remote for its own service across devices. So you can start a song playing on your phone and direct the output over AirPlay and then just interface with that session using the desktop client.
If I understood your problem correctly, you need to listen to Spotify through your HomePod which is on the same local network as your Mac.
This is what I do on macOS. I press on the little megaphone icon (enable it in OS sound preferences) in menu bar and then I can choose my HomePod from the list, without any third party software. I am running Big Sur but in two previous versions I also did the same. Maybe I’m missing something here but I think it should work seamlessly.
Got me thinking. I wonder how much scope there is to build apps for platforms like Spotify which are built around a given use case.
For example - for people that prefer listening to albums. Or people that only care about political podcasts. Or something. I wonder if the global audience is enough to support indie products like this.
i don't like this podcast stuff either. even just the homepage that displays artists (that i will never listen to) is enough to annoy me. i would really love an option to open directly into my playlists or something else. im building up a local music collection at the moment so its not going to be annoying me for too long more
I love seeing software like this, even if it's not legal. Who cares? I remember being a teenager and trying out all sorts of cool underground, fundamentally illegal software, or stuff that worked around Terms of Service.
Where would the world be today without Napster? Maybe the same place, but provocative software is the definition of cool.
Eh. Ish. They only support playback within a browser and have deprecated native playback support years ago. Also their ToS technically doesn't let you do a looot of things you may want. Like caching. Srsly, you're not allowed to cache things. Many 3rd parties stopped supporting spotify because the dev ToS kept getting worse.
Regardless, I'm excited about this little project even if it goes against the ToS.
Things like Napster have a long tradition dating back to the 1960s, in the UK the response to the paternalistic and stuffy state monopoly on music broadcasting was for people to put studios and transmitters on ships parked just outside of British territorial waters. That’s really what fuelled the explosion in British music!
people on here care about laws too much. it's a api/webscraping tool redisplayed a gtk window. nobody is going to go to jail. even if they dmca it someone should just host the sources on anything other than github and let it ride. people cheat at videogames all the time, they can cheat on a music client.
Running the risk of being a dirty reposter and.. reposting. My little Spotify client is for macOS only, mostly only built for my own use, and a lot more minimal, visually. It's also native Swift though, so it's got that nice macOS feel. It's also pretty much 100% keyboard-driven (Vim keys, if that's something you like) and supports regex filters. It's just an open-source thing: https://github.com/toothbrush/Spotiqueue
It shows you can write native cross-platform apps that are fast and have low system resource usage instead of the now default, packaging your app in a standalone resource-intensive web browser, aka Electron.
It's a shame we have a handful of people who can do this as a hobby project yet multi billion dollar companies with the money and manpower to do this don't, they chose Electron.
Druid is still not ready for prime time though (https://www.areweguiyet.com/). Played with psst for a bit: no keyboard shortcuts, no screenreader support, scrollbar feels 'off', stuff that just works if you use a native toolkit or a browser.
I get that this is early days for this project, but the issues are general for all of these non-browser, non-native UI toolkits. Hopefully we get there though.
Hi, the author here. Keyboard navigation is definitely something I'd like to focus on soon, the app should be 100% usable without a mouse. And accessibility is definitely on the Druid roadmap! <3
Keyboard shortcuts should be doable, I don't think this is a limitation of the toolkit.
Obviously screen readers are an important step, but we hope to be working with AccessKit.
In any case, though I'm not trying to represent Druid as ready for production use, I love seeing stuff like this. I think it's a good sign of what's possible and where things are headed.
Trying psst here on Linux I came away with the opposite impression - Druid's further along than I expected, it Just Worked at high DPI on Wayland better than most electron apps. I guess it'd feel worse on MacOS which already has a more consistent system UI.
We are (I hope) helping solve this problem at Kraken. We sponsor development of the iced library, which we're using to build https://cryptowat.ch/desktop. It's supported on Windows, Mac, and Linux and has received a ton of positive feedback about how fast and light it is. I have hope for the future, and don't expect Electron to stay dominant forever. Native GUI apps are slowly coming back.
Why do people keep forgetting this? You can use Qt to easily build a "fast" GUI that works on all platforms. And you can do it with Python via PyQt. No complicated C++ or Rust, unless you actually need it (which this almost certainly does not).
I suspect the real reason is that web developers are seen as a dime a dozen and GUI programmers more specialist and hard to find. This was the main reason my team chose to do an Electron app. We were already doing React on the website and nobody had any experience with Qt.
>It's a shame we have a handful of people who can do this as a hobby project yet multi billion dollar companies with the money and manpower to do this don't, they chose Electron
This is a purposeful decision though. How else could they track a thousand different metrics about you without 20mb of Javascript?
The OP project is speaking to Spotify servers through the same means that official clients are, but the official clients are not just on iOS, Android, macOS and Windows.
There’s official Spotify clients on almost every platform imaginable. Everything from PS4 to built into TVs. And even a lot of stereo systems have Spotify Connect built into them.
Spotify Connect works by having these other devices streaming and playing the media, and your computer or phone acting as a “remote” for choosing the songs to be played. See https://www.spotify.com/us/connect/
Basically they’d have to break a lot of official clients, many of which probably cannot be updated, if they were to change their DRM scheme. How do you update a receiver for example? Well, you might be able to flash a new firmware with a USB stick. But for regular people, they are not going to do that. And the DRM scheme, at least as of yet, would be defeated by the reverse engineers as DRM always is. And hopefully continues to be.
So at least as of yet I think they would hurt people with official clients more than they would hurt anyone using an unofficial client.
And even people using unofficial clients are probably paying customers.
Besides what’s the point anyways, everyone knows that if you really really want to rip audio you don’t need to circumvent any DRM at all. You can play the song on your computer or your phone and take the analog signal that is going to the speakers and digitize it again and make an imperfect but still good copy of any audio. Admittedly it doesn’t scale anywhere near as good as automatically stripping DRM though.
Music publishers could demand better DRM in their contracts, though. That would lock out any devices incapable of receiving DRM updates, but it's certainly a possibility. If Spotify would refuse to budge, their platform would lose access to a lot of songs. If they agree, their users would have a terrible experience, only being able to play some songs on some devices.
In order for Spotify to have any decent user experience, they need to nip any DRM bypass as scale in the bud before the publishers find out, through cease and desist or worse. If better DRM becomes the only solution, everyone loses.
The difference between official and unofficial clients is that Spotify can have some (contractual) power over the official clients, like demand that music is cached encrypted, demand a certain limit for cached music, etc. Unofficial clients aren't bound by any contract, so the developers could easily do something they shouldn't be doing according to the terms and conditions Spotify lays out (or the terms and conditions of the copyright holders that Spotify must uphold).
> Is that even possible for Spotify at this point?
Spotify are using Widevine on their web client, which is considerably more annoying to deal with than the encryption method used in the files fetched by Psst.
Nothing is stopping them from only serving files from the endpoint that serves Widevine protected files.
Then again, Widevine L3 has been broken[0], Google just keeps rotating the private keys used in the content decryption module.
The name of the game is risk mitigation. In this case, there are lots of ways to rip a singular track. They are usually slow because you record the audio stream from Spotify.
But if you could get the original file from Spotify's servers and decrypt it yourself, you could automate downloading your entire library, offline forever at source quality DRM free. Unfortunately, that is illegal and Spotify is going to dick them with lawyers. Pretty sure that's what happened to this project: https://news.ycombinator.com/item?id=25017167
History: after the developer decided to pivot from only being a tool to scrape the encryption keys needed to decrypt an individual song, the developer decided it would be a good idea to build in automating the downloading and also decryption of those files, instead of letting people develop that as a separate tool.
Developer and project has disappeared shortly after that decision.
They don't break the DRM and use the official WebAPI.
> This app uses the Web API from Spotify, which doesn't handle streaming itself. So you'll need either an official Spotify client open or a lighter weight alternative such as spotifyd.
librespot is a reverse-engineered thin client (using the same api that e.g. your "smart speakers" would). It doesn't use official APIs, arguably violates DMCA, and you pretty much have to use it if you don't want to simultaneously run the full thick official client on the same device at the same time.
> Psst: Fast Spotify client with native GUI, without Electron, built in Rust
I wonder what's faster: The new GUI, linked user accounts getting suspended or the project getting legal issues with the result of being taken down.
¯\_(ツ)_/¯
No, seriously. I support projects like this. But they pretty much always end the same. It's always sad to see so much effort go into waste. I get the motivation but I think there are a lot of other things to spend this kind of work on other than somethings that breaks a service's TOS from just reading the title.
This uses the same API as libspotify, a library for accessing Spotify for playback that Spotify released themselves. It’s not been supported for a while so future support for this API is unclear, but it’s not clearly going to be shut down like you suggest.
Apple Music also has an official and maintained API for building third party clients.
I think the idea of desktop apps being web apps repackaged is now so ingrained that some people have never experienced true desktop app performance.
As in, zero latency, or no observable latency. Instant performance. Honestly, it sickens me how spectacular advances in hardware translate into performance being worse than before.
Even the Office client apps are now web (React). And you can tell. Sluggish and glitchy.
As for the Spotify app, I have little love for it. Overengineered garbage where the simplest actions leave you searching. Internally, they have created this massively complex structure of squads and tribes each taking care of just one tiny part of the experience. This may explain why Spotify is so disconnected and makes no sense.
All of this engineering effort, I imagine there to be at least a few hundred working on it, ultimately add up to an experience less usable than bloody Windows Media Player from the 90s.
Hi, I'm glad you like it! The performance is not _that_ good at the moment, mostly because of superfluous paints, but it's something I'd like to focus on (as it's one of the primary objectives).
So Electron is the problem. It gets worse if you have lots of tabs open in Chrome + running other electron apps as well. A visible and obvious improvement when compared with a native app.
Also, Electron apps do not scale and it wastes CPU time, eats RAM up and fills up HDD space. On laptops, it drains the battery faster.
I've never given Spotify a try because of the crummy web/Electron player I saw everyone using. Wanted to try this out, but it only works with a premium account. That could've been mentioned more clearly, would've saved me the effort of compiling this thing.
I can't judge the main application but just the settings screen makes me feel like the UI library powering this isn't quite ready for prime time yet. I consider shortcuts and basic text handling like ctrl+a to select all text in a textbox to be basic features for any UI toolkit; the lack of such ease of use features really makes the GUI toolkit feel less native than the Electron cruft that's overtaking our desktops.
As for the legality, the DMCA sucks but this client is definitely in violation of it. Breaking the TOS isn't necessarily illegal so the tool is fine to use (at the risk of getting your account banned) but development can be quite risky. Hopefully, Spotify takes an interest and uses (a fork of) this project to write a faster player for their desktop clients instead of cease-and-desisting it to hell.
>it only works with a premium account. That could've been mentioned more clearly
I agree, although it looks like you only have to change a single line of code to make it work without a premium account. Might as well go all the way if you're already breaking the TOS anyway I guess.
Any circumvention of DRM, even simple DRM as long as it's not too trivial, is considered illegal under the DMCA. The decryption routines Spotify uses should definitely be considered non-trivial DRM.
Not who you replied to, but if anything decrypts a DRM stream in an unauthorized way, it technically is breaching DMCA. I assume that is what they meant.
I've been running this for the last 5 hours, since I saw the posting. Thankfully, in arch it's just part of the aur.
Frankly, it's awesome. It's literally every single thing I dislike about Spotify fixed. There are no podcasts, I can search, there's no social senselessness anymore.. I'm thrilled.
The only problem I have is that eventually it just gobbles CPU. Having it open and doing nothing seems to take ~4% of my CPU, and while playing a constant 7.2%. Frankly, I assume this is decoding, but I haven't traced yet. Eventually it spun out of control and pegged one CPU at ~90%, which a quick restart fixed. All of this is to say it's an incredible project - I'm not going back to the old client.
This is great, but the sad truth is that unofficial clients like this can never grow big and support more than a few thousand users, given how ridiculously low Spotify API's rate limits are.
My project https://volt.fm has 100k+ users now and I'm really struggling with the Spotify API.
Slightly off topic, but it’s a shame Spotify’s web API doesn’t support (and they’ve said never will support [1]) playlist folders. I get that it’s a bit of a power user feature but it’s an essential one for me in any media player.
Makes me worry they’ll remove the feature from their app one day (they allude to it being a bit of a mess in the database) which would be the push I’d need to move away to either another service or a local collection only…
"Chromium Embeded Framework". When people say Electron based they don't really care if it's using Electron or any other browser. It's still a browser. And it's therefore at least 100x slower than it could be.
Spotify regularly upsets me with change. Don't change a UI that looks good and works well just to hide something I need. It feels like it's just justification to have an entire team of client designers employed.
I remember when Spotify had Lyrics, which is an obvious choice of feature for a music service. It was off my a line or two, but it worked pretty well and I used it all the time. It was the best way to hear the music and see the lyrics that I knew of. Then, one day, I open the client and see that clicking the lyrics button showed a message that the lyrics feature was being enhanced and it'd be back soon. Then one day the button disappeared.
The only reason I use spottily over local music at this point is discovery, because they really do a great job at that.
Ripcord is excellent but you need to generate a new login token every few weeks. Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want.
> Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want
It would give up control and it's an admission of failure; a slap in the face to some project lead, some designer, some exec, showing that their brilliant ideas were not in fact the superior option for everyone forevermore.
Either of those are unacceptable enough to lock the system down. But both? Never in a million years.
"How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Shareware sometimes used to provide a way to check for updates, and sometimes allowed for this to be done automatically. But it generally did not try to make network connections without any permission from the user.
Shareware often used to provide contact information for the author so that users could show their appreciation. Authors invited voluntary feedback.
Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Anyway, his answer is:
"Set the environment variable RIPCORD_ALLOW_UPDATES=0"
How about starting the program while offline, i.e., network interface down.
> As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Lots of shareware did and does that. It's normal. It's just an update check. It doesn't self-update. It doesn't transmit any information. No logs are collected. It just displays a "update is available" message if it finds that an update is available, with a link to the website to download the new version.
> Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Ripcord doesn't send any information about the client when it checks for updates. No information is logged on the server. It just fetches from this URL: https://cancel.fm/ripcord/updates/v1
Ripcord does not have any kind of telemetry or analysis system in it. It doesn't even report which OS you're using to the static file HTTP server — the update info URL returns the information for every OS at once.
> How about starting the program while offline, i.e., network interface down.
It works fine if you do that.
> "How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
This is provided as a way for users who extra paranoid to turn it off outside of using the normal preferences in Ripcord, since that requires launching Ripcord at least once. It's not the only way to do it. (It'a also useful for package managers on Linux who don't want "update is available" notifications to show up for their users.)
The normal preferences window in Ripcord has a clearly labeled checkbox on the first page for turning update checking off or on. I don't know what alternative there is. If it was off by default, most users would ask why it was off by default and why are they being tricked into being left to use outdated versions. I don't know any software that does this.
looks very cool, might switch back to spotify just for this. the speed and feeling of pre-bloated iTunes is still the benchmark to which i hold any music app, and this might be the next best thing.
Usually the way it works is that _using_ the software is illegal, but distributing its source code is not. Code is covered by the first amendment in the US.
I hope this becomes popular enough that Spotify buys this and makes it default. I have not used this but anything is better than current Spotify memory hog. I miss those WinAmp days.
Actually, you could just use use react (or vue or angular with nativescript) and have one codebase with a __native__ ui on desktop + css on the browser, but keep the app-logic and UI code the same.
Anecdata: I have used this functionality literally once in ~5 years. Safe to retire it and build a real client. I suspect most people don't use the browser.
So right. As soon as you are the person paying for people and time to develop native apps, you start thinking, "Geez, I could make an identical UI with web technologies and skip all the platform stuff entirely!"
These apps are identical to native. Not one person could tell you the difference. The complaints about speed are nonsense, too. People don't benchmark apps. They use them! These Electron and other web-wrapper apps are absolutely the future of all client-side app development.
If native apps are the railroad, web apps (w/ or without a wrapper, makes no difference), are the airplane.
BTW, there are many complaints about the Spotify UI, but does anyone ever complain that it's a web-based UI? Who has ever said, "Wow, I like Spotify but, ya know, it's got a UI built with HTML and CSS and JS, so I don't wanna use it."
That's not real. Proprietary app wrappers are proprietary because the companies that make them benefit from lockdown. They will always promote their locked-down platforms, and many enterprises have millions of dollars of sunk costs in these siloed application environments. The way out of prison is through web-based apps that run anywhere without the user even knowing or caring how that happens.
This feels like such a breath of fresh air. I wish there comes a wave of such native implementations of popular electron resource hogs - Slack, Teams, WhatsApp etc.
What I don't understand is: How many developers do you really need to create a native Spotify client?
My pet complaint is Google Chat, which is now a web app or a PWA. Seriously, I don't believe that Google can't afford to have three Mac developers assigned to Chat and create an awesome native application, rather than shipping that piece of junk PWA. Similarly I don't buy that Slack, Facebook and Microsoft can't hire or train the most bad-ass Mac or Windows developers to work on native versions of their products.
Looks really nice! I switched to Apple Music like a year ago but if this is good then I might switch back to Spotify.
I remember seeing some demos of the UI library Druid in the past but I didn’t realize it was at the stage where complete applications like this could be built.
I am definitely going to check this out. I use the Spotify snap under Ubuntu as I never got Spotify client working when I upgraded to the lastest Ubuntu and they keep working on the main stable. I do not hate the UI of Spotify but having alternatives is really nice. I also have Spot installed. It is also a simple and native application to listen to your music. I am a very heavy Spotify user. We have a family subscription so my kids have their own premium. Last year I listened to 60K songs; I really like the yearly review BTW. Yesterday I was talking to my wife and we just swallowed the pill completely and we will be throwing out our CD collection to make room for a new cabinet (I currently own around 1000 CD's).
On the desktop, I simply use a separate Firefox profile for Spotify with the web client. The only 'special' thing is that I had to disable ServiceWorkers because they somehow caused some trouble every few weeks (dom.serviceWorkers.enabled = false). In addition, I use KDocker for a system tray icon.
However, on mobile it is a completely different story. The Spotify app requires so many resources that it takes forever to start (like a minute) and sometimes even causes my phone to reboot. For something like a MP3 player that is hilarious...
Does someone know if there is a good alternative mobile app?
Why the hell is there not a stateful GUI markup standard? Mice and desktops did not go away with the advent of mobile. They are still the bread and butter of business, for example.
Thus, rather than reinvent the GUI adapter wheel for each and every programming language, let's form a dynamic GUI markup standard based on existing open-source kits to avoid starting from scratch (Typically Tk, Qt, or WinForms. WinForm's base is OSS, believe it or not.)
Then languages can read and write markup (XML or JSON text) to have GUI's instead of glue on some screwy binary addon.
For the last couple of months I am using open.spotify.com (i.e. I uninstalled the native Windows app). Works great, not sure if I am not losing some audio quality, but if I do - I have not noticed.
```
Compiling sized-chunks v0.6.5
error[E0658]: `if` is not allowed in a `const fn`
--> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:119:5
|
119 | / if element_size == 0 {
120 | | usize::MAX
121 | | } else if element_align <= container_align && host_size > header_size {
122 | | (host_size - header_size) / element_size
123 | | } else {
124 | | 0 // larger alignment can't be guaranteed, so it'd be unsafe to store any elements
125 | | }
| |_____^
|
= note: for more information, see https://github.com/rust-lang/rust/issues/49146
error[E0658]: `if` is not allowed in a `const fn`
--> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:121:12
|
121 | } else if element_align <= container_align && host_size > header_size {
| ____________^
122 | | (host_size - header_size) / element_size
123 | | } else {
124 | | 0 // larger alignment can't be guaranteed, so it'd be unsafe to store any elements
125 | | }
| |_____^
|
= note: for more information, see https://github.com/rust-lang/rust/issues/49146
error[E0599]: no associated item named `MAX` found for type `usize` in the current scope
--> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:120:16
|
120 | usize::MAX
| ^^^ associated item not found in `usize`
|
help: you are looking for the module in `std`, not the primitive type
|
120 | std::usize::MAX
|
error: aborting due to 3 previous errors
Some errors have detailed explanations: E0599, E0658.
For more information about an error, try `rustc --explain E0599`.
error: could not compile `sized-chunks`.
warning: build failed, waiting for other jobs to finish...
error: build failed
```
If I had to guess, I'd say you're using a too old versions of rust.
In the future, one will be able to give a nice error when this happen (https://github.com/rust-lang/rust/issues/65262)
But now it's true that it can be hard to know what the problem is.
Yep, the two missing features are `usize::MAX` (stabilized in Rust 1.43, April 2020), and control flow in const fns (stabilized in Rust 1.46, August 2020).
Wow! Could Rust return the desire to build fast native UIs? I sure hope it does. And also is there Apple Music native app? Because the standard client is such a mess of an app.
Good news. We need more native apps, which work autonomous and locally and optionally sync with servers. Examples are Git (yeah! --everything-is-local) or any decent Mail-Client. Especially what the industry usually does is not the best, but just the cheapest.
A project like this cant come fast enough. Spotify desktop on Linux is a bloated mess that regularly crashes and takes down the display server with it.
It's working just fine so far on Linux even it sounds like they're mostly using MacOS. I could see using this a lot if playlist support was added. It seems snappy. I'm kind of surprised that htop reports 165M and Cpu reporting 38-45% which seems a tad bit high for playing a sound file O_O . I know it's early days though, so I'll keep an eye on it for sure. Very clean interface.
Hi, thanks for being interested! There've been some regressions lately, sorry :| Performance is #1 priority for me, and a big focus now, after last round of refactorings.
Is it just me or does the play buttons triange in the screenshot look horribly uncentered. Seems like the like positioned based on minimum/maximum horizontal extend whereas aligning the "center of gravity" with the circle center might make more sense.
Tried to build on M1/Apple Silicon, but hit some errors. Looks like one of the dependencies isn't playing nice with arm but would love to give this a try.
Any rust devs have second? I think its the miniaudio dependency that's broken.
The part I don't understand is how do you find the motivation to write such time taking things? Outside work? At work? I guess you don't know whether this would be profitable or not, how do you stay motivated?
Thank you! I took some time off after finishing my last full-time commitment, and wanted to cut my teeth on Rust a little bit -- exploring how feasible building cross-platform native apps is right now. So I've started building something that I'm missing and would like to use. Combine this with the pandemic, and here we are.
Can you decouple the UI from Spotify and make a generic interface to plug in N streaming services? Then people could make a Spotify provider, a file provider, a Pandora provider, an Amazon music provider, etc.
Everyone hates slow, laggy, shitty software. The average consumer just has no insight as to why their software experience is bad. But don’t be fooled. A snappy, smooth experience does matter to consumers. Even when they can’t even quantify why one app “feels good” and another “feels bad”.
What's funny about having to rely on unauthorized clones to provide a fast native UX was that Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.
Few Apps ever had that wow factor the first time I used it, it was so much lighter and more responsive than anything else of the day. I remember being perplexed at how I could search and skip to any part of a song quicker than iTunes could looking at a local library. Everything was latency-free and instantaneous.
We were building a Music Startup at the time, so we investigated how it worked. We we’re very surprised we couldn’t find any evidence of an established UI toolkit. It looked as though they had built their own custom UI renderer and optimized TCP protocol which sent back its metadata in XML. Their traffic looked like it was initially seeded from their own (or CDN) servers (for best latency) and then overtime we would see some P2P traffic on the wire.
Our QT/C++ client had decent performance but was noticeably heavier than Spotify's. I was disappointed to see their native client eventually be abandoned and succumb to become yet another Chromium wrapper. I expect it fell to the pressures of a growing startup adding 100s of developers (without the skill of their original CTO/devs) where a native UI couldn't be updated and re-iterated as fast as a Web App. I wish they maintained 2 desktop clients, and left their native client alone to just be an audio player and push all their new social features to their new flagship CEF app.
It's unfortunate the skill and desire of building fast native UIs are being lost to Electron and CEF wrappers. Seems the larger the organization the more likely they are to build new Web rendered Desktop Apps and we have to rely on unauthorized Indie efforts like this for fast, responsive native UIs.
Something that Chromium apps do give you however, for free for the most part, is accessibility. I just tried the GUI version of this client and was not surprised to find out that I could not use it. The new Spotify UI released a few months ago is the most accessible Spotify has ever been. Landmarks, clear labels, headings, and even aria-trickery to automatically announce things using my screen reader. I remember being very frustrated with the old UI's to the point where I chose another service just because it was more accessible, even if it didn't have a desktop app. YouTube Music and Deezer had much better UI's from the get go. At this point, I'm almost happy to see an Electron app. It doesn't guarantee accessibility, but the likelyhood is so, so, so much higher than any modern cross-platform UI framework. I'd almost go as far as to not call these UI's native. Because if they were, if they used native controls, the accessibility would be there. The OS vendors spend a lot of time to make them usable and consistent. Sadly, these UI frameworks don't, or can't. Sure, psst has a CLI, but I only get panics. I can't do -h to find out what I can do with it, I can only call it with a spotify URL and get it to play and exit once it's done. It feels like the cli was included as a sort of testing tool to check the underlying libs and code, and not as a usable version of the app itself - but it's still very early in development so the GUI might be the same. I can't tell.
Here's how these things usually go: first, you start small. You build something you can show other people. You try to generate some traction and build interest around your idea, validating it at a very small scale (friends, family, "Show HN", etc). You gradually expand that cycle of people. You get into a routine of iterating on improvements, adding new features, and gradually scaling things up. You probably get a couple of people to join you on that journey, because the more popular your product becomes - the more asks you'll be getting, and the more work it takes to scale it out. Rinse and repeat.
The reality is that we can't expect every single hobby project to support every single use-case from day one. Painfully for all - the current state of things in this space is such that building accessibility into your product is not trivial and hence it gets postponed "for later".
Now, on to a completely honest question: why don't we have screen readers that can consistently translate the "visual" version to a version people with visibility impairments can understand in a more generic manner, without requiring every single piece of software to adjust itself to every single flavor of a screen reader? I'm honestly asking why can't we solve the whole problem by offloading it to the screen reader itself. Can we solve this by simply offering a text-only command-line like version of every product? (ie. as opposed to building "beautiful"/"designed" experiences that get downsampled by the screen-reader anyways)? Sort of like building a sitemap.xml file that lets the user with a screen reader do everything a user with the full-blown GUI can. Sounds like an opportunity to create a cross-industry standard?
Edit: getting downvoted for comments like this is why I'm honestly considering just closing my account and not participating in any more such conversations going forward.
12 replies →
Hi, the author here. Psst is definitely in alpha, and the CLI is indeed just an example (it's what I was using to test the core mechanisms). I'm sorry the accessibility is so bad now, but Druid, the GUI library, takes it very seriously -- which is not very common in custom GUI frameworks. So, fingers crossed, it should get better soon.
Re. command-line Spotify clients, there is ncspot[1] and spotify-tui[2], and if you use Linux, Spot[3] looks like a nice GTK experience.
[1] https://github.com/hrkfdn/ncspot
[2] https://github.com/Rigellute/spotify-tui
[3] https://github.com/xou816/spot
This is, unfortunately, a very common occurrence when GUI frameworks are concerned. For some reason, framework authors like to mislead and say that their framework is native, when it looks native but actually isn't. WX and SWT are the two notable exceptions here, they do indeed use native OS controls.
If you want to use a native GUI framework because of accessibility, check if it's as native as it claims.
You're comparing a person's side project to years of work on this in Chromium.
Seems rather like comparing someone's homemade bottle rocket to a Saturn V...
2 replies →
Fun fact about Spotify web's accessibility: Alt+left/right are used to both navigate pages AND go back/skip a song. It is truly an abomination.
I honestly think we need to rethink accessibility from the ground up. modern advances in OCR and machine learning should allow us to do accessibility entirely from the GPU output.
it'd take awhile to perfect but i think it'd ease the burden tremendously for software developers and those who need accessibility.
2 replies →
If you are interested in their story how the original client and architecture came to be and then how it changed to what it is today they have a podcast you can listen to: "Spotify: A Product Story" - https://pca.st/cbo7khrm
Here's also a blog post related to the topic: https://engineering.atspotify.com/2021/08/04/four-lessons-we...
Just finished listening to this, thanks for the recommendation.
They spend some time interviewing Lars Ulrich of Metallica in the context of of the Napster lawsuit. He comes across in this interview as still upset at Napster for what they did, and he is at turns indignant and also emotionally wounded at the fact that they are perceived as the villains in the story. In particular he cannot seem to reconcile his belief that they, and I quote "are the most fan friendly band on this planet" with suing Napster for $100k per download in damages, a ludicrous and arrogant sum. I am not a Metallica fan and do not listen to their music (out of disinterest, not antifandom. Metal isn't my genre), but it is striking to me to see how 20 years on they still don't get it.
10 replies →
Thanks! It's great to read the backstory of how the original Spotify client came to be:
> "Not to go into too much detail here, but at the time, most of the internet was made up of “thin clients,” like web pages or Flash-based clients that ran in-browser, and used more traditional, standardized protocols like HTTPS. Seeing the limitations of that, Ludde and a team of engineers ran in the exact opposite direction, creating a stand-alone “fat client,” building entirely new protocols and hybridizing client-server and P2P technology to suit their own ends. (Check out Episode 01, “How do you steal from a pirate?”, to hear more of that nitty-gritty stuff about persistent TCP connections and how our P2P implementation saved us bandwidth cost.) It was only by rethinking every layer of our infrastructure that we were able to pull Spotify off, to create that magic moment of double-clicking on a new song and having it instantly play. And speaking of magic …"
Having been an early user of the beta I presumed it had to be driven by people with this mindset from rethinking everything from bottom up to provide the best UX possible, would really love to read more about the technology used in the original Desktop client?
EDIT: Currently listening to “How do you steal from a pirate?” which is providing a more detailed backstory on the origins of Spotify:
https://open.spotify.com/episode/1jHRUXkeiUh44CK4KZQb0h?si=d...
Sounds like Ludde Strigeus, the creator of µTorrent was the key hire to make the original Desktop Client UX possible whose Desktop & P2P expertise was able to convince the rest of dev team to go down the path they did. Some interesting insights, they used Ogg Vorbis instead of mp3 using a custom designed TCP protocol because they were better able to strip packet bits down to transport just the audio bits required for playback.
> Michelle: The thing that happened that was kind of pure magic in that meeting was that [Daniel] did a comparison. He started playing a song on the software, and the song played so quick, so instant … I mean, I don’t know if people remember, but playback was slow back then. Even if you had an MP3 on your computer, and you played it via, you know, Winamp, iTunes, this was faster. And we were like, “You have the files on your computer, right?” And he was like, “No, it’s in the cloud.”
I had the same initial experience where I was blown away at how instant and responsive it was, at first I didn't believe it and thought it was doing some sort of pre-caching magic where it'd start downloading before selecting each song. So ran lots of tests where I did first time searches and immediately scroll to songs down the list of search results (to bypass any caches) and could see that it was indeed pulling traffic in real-time, the time from click/scrubbing to audio playing was just unbelievably fast.
4 replies →
I guess much that did the first client light weight was because it was developed by Ludvig Strigeus. He devloped the very light and popular uTorrent client. Very early for Spotify they bought uTorrent AB, not for the uTorrent client, but because they wanted his skills and he was the person that developed the first Spotify client. A few month later Spotify sold the uTorrent client to Torrent Inc.
Ludvig Strigeus is a skilled developer and have got many awards, like the Polhem Prize which is a Swedish award for a high-level technological innovation or an ingenious solution to a technical problem. If I recall correctly, he is very good at writing very small and optimized c++ programs, but the code is very hard for others to understand and maintain. So I guess when Spotify become bigger and more developer needed to work with the code they needed a more "main stream" solution and had to abandon the first client.
The early versions of uTorrent were on the order of 80KB in size, it really was amazing. BitTorrent the company re-skinned it as BitTorrent the software and offered both versions for a few years, differing only by icons and colors, but fans held to strong opinions about which was technically better. It is true that the code was hard to maintain and extend though.
The problem (or rather value proposition) is that the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability. Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app, especially given they just want to listen to music, which the app does just fine. If people specifically don't like the social features, they'll be mad at the decision to implement those social features instead of 'what they used for the tech stack' since ultimately Spotify could have developed the same features in a native app with just a few extra weeks of sprint, if that.
The outrage around these supposedly egregious performance issues is more understandable when you consider that developers who spend a lot of time tuning performance in their work would naturally develop a 'selective attention bias,' magnifying the significance of what to others are negligible if not imperceptible differences.
Imagine the frustration of someone who, for example, did work on sound insulation for cooling systems: they sit out on a patio for dinner with friends and the sound of an inexpertly designed air conditioner appears to them as intolerably intrusive; meanwhile, no one else at the meal notices until it's pointed out.
26 replies →
The Spotify website and phone apps don't just have performance issues, they have awful bugs that have been left unfixed for months/years. When streaming to a Chromecast, the UI quickly gets out of sync, randomly disconnects, etc. I'm resorting to using a bluetooth receiver connected to my amplifier because that works better. The recommendations are also getting worse IMO, though that's more subjective, hard to quantify, but the amount of time I spend using Spotify has gone down a lot, just because I'm not discovering enough interesting tracks anymore.
IMO, Spotify is neglecting its core features, and that will ultimately hurt the platform. However, there is such a thing as network effect, and they may have the broadest selection of music. That will keep the platform growing, up to a point. Eventually, the growth numbers may peak and slow down. It's just that there's a lot of inertia right now, and the growth is still going upwards, but eventually, gravity might catch up.
2 replies →
> Most people don't care that it takes an extra 10-100 milliseconds
I probably wouldn't care about it too much if they didn't mess up the rest of their apps into the dogturd that they currently are. Doing bad UX is one thing, making UX consistently worse with pretty much every update another. And that's what Spotify has been doing for years now - if I could go back to a client-version from a few years ago, I would, immediately, without thinking twice.
The fun part? My company jumped on the SAFe-train a while ago, and Spotify was heralded as the "prime example" of where agile and all that works out really well.
I have no idea what they are doing, but whatever it is - if they continue like this, I'll go back to pirating music, because they're getting really close to having just-as-bad of an experience as that. And I really don't mind paying 20 bucks for my family account; experience is all I care about.
Users do notice speed issues in apps and websites.
The NNGroup has done studies with users to gather reactions to slow websites in 1997 and 2010. They remain relevant in 2021 to both apps and websites: "Users really care about speed in interaction design" [1]
A few weeks ago someone on HN shared the reflections of the developer of SumatraPDF - a native Windows PDF reader that is small, lightweight and performant (all the things that Adobe Acrobat Reader is not).
From the developer Krzysztof Kowalczyk: "I believe being small and seemingly fast was a big reason for adoption...there will never be a time when users want bloated and slow apps, so being small and fast is a permanent advantage." [2]
[1] Website Response Times (2010): https://www.nngroup.com/articles/website-response-times/
[2] Lessons learned from 15 years of SumatraPDF : https://blog.kowalczyk.info/article/2f72237a4230410a888acbfc...
Generic statements such as "most people don't care [...] extra 10-100ms for the UI" need to be supported by evidence, especially since those 100ms are added to existing latency and 100ms is considered the threshold where operations feel instantaneous [1].
Still, for certain things 100ms is too much. Android famously had a round-trip audio latency of a bit above 100ms which made it a poor choice for music apps - in contrast to iOS. They now require 20ms in the Android Compatibility Definition Document and admit that musicians require 10ms [2].
In addition to that, hitting the 100ms threshold doesn't mean that lag is not noticeable or not annoying. There was an article about keyboard lag posted on HN a while ago, and the top comment was likewise interesting: https://developer.android.com/ndk/guides/audio/audio-latency
1 reply →
Spotify's Android app is of very poor quality.
Search is just so basic, you can not have any typos whatsoever.
There is no proper history function. Say you start a radio, it only remembers that you started a radio but if you come back to it you probably will not have the same songs.
Connectivity is piss poor. If you lost connection you will have to restart the app otherwise you won't be able to use search.
While this is about the native desktop client, I assume it has similar problems so the argument that it is only a couple milliseconds of latency doesn't hold up. Their UX is the worst I've ever had to deal with in a music app.
7 replies →
If we followed similar arguments about hardware, we wouldn't have Apple today. The entire premise of Apple's hardware is that it is beautiful, well designed, with attention to details even in places where the user would never interact (motherboard layout and finish).
You might be guessing from intuition that 10-100ms latency doesn't matter, but I suspect that it does. You can feel the philsophy of the company when you use their products and they feel wonderful. It's a culmination of attention to detail in every aspect of development. I love Sublime Text precisely because of how fast it is.
4 replies →
I disagree with the assessment that an extra 10-100ms doesn’t matter.
How pleasant an app is to use does affect a user’s perception of an app and product even if they can’t articulate it. Fit, finish and polish do matter.
2 replies →
Myself and every (non-technical) user of Spotify I know complains about the horrible mobile and desktop apps. The android one is an absolute dog, even on mid to high end smartphones.
If you neglect your core features in exchange for pointless trinkets you're setting yourself up for failure.
The first alternative to show up with an equally vast catalog, but a light and fast interface is going to win a lot of customers in no time.
Remember this is streaming: there is no friction for me to switch. I export/import my playlists and it's done.
4 replies →
I mean
I have one of the fastest laptops (Apple M1 MacBook Pro) and now I opened Spotify and it was just a black screen for about 1 minute before it showed anything. Then it started.
It is usable. But not good.
> Most people don't care that it takes an extra 10-100 milliseconds for the UI to react compared to a native app
You can tell this is true because people keep complaining about it, and developers keep reminding us that we don't actually care about how slow apps are.
The problem is that the people with decision power over software are usually not the ones who actually use it and latency issues are more of a subconscious thing. Slow programs just feel less good to use until they reach a pretty high threshold where it feels unbearable.
For speed good enough is just very far away from good (factor 10-1000)
The stability of Spotify is awful, I use Spotify to entertain my kids in the daytime and put them to bed at night so I’m a heavy user. Connecting to external speakers through Connect is very unstable.
The thing that keeps me on Spotify is that I’ve invested a lot (but not insane) time in curating my playlists. If I was guaranteed a high quality experience with a competitor I would make the switch but I’m not going to make the switch just to find out that the competitor also sucks.
1 reply →
The problem is it's only 10-100 milliseconds when my computer is otherwise unloaded. When my machine is under high load that turns into several seconds.
My wife doesn't know WTF Electron is, but definitely notices when a pile of Electron "apps" are slowing her computer to a crawl.
> the only thing that matters is the end-user's perceived value, and that's almost always in the form of features and stability.
I think here it's more accurate to say, "the business' impression of the end-user's perceived value".
Because a snappy user experience DOES have real value; in web we are very conscious that milliseconds cost viewers in load and response times. It's well documented that brand positivity is connected to load and response times.
But users don't know to tell you that until the performance gets REALLY bad. Consequently it's hard to get this value from a user survey, and hard to communicate internally as a value prop. Capabilities are much more business process friendly.
Probably. But I'd like to think fit & finish makes an app more sticky.
> Most people don't care that it takes an extra 10-100 milliseconds for the UI
TLDR: up to 100ms latency is fine, but alongside higher RAM usage, and when applied to all programs across your machine (not just a single app), hell breaks loose.
I entirely agree with this statement. However, most people don't have a high-end machine like the developers test on, and actual difference in latency between an electron app and a web app may be over an order of magnitude larger.
The problem is in many parts of the world (including in poorer communities of the global north) people rely on second-hand hardware which even in 2021 typically has 1-4GB of RAM, so a single application taking hundreds of megabytes when not over a gigabyte of RAM will quickly lead to you swap hell and render your entire machine slower.
Despite being an ardent GNU/Linux user, I believe the linux kernel OOM is close to the worst that can be done in this matter (although there are certain progresses with eg. earlyoom), but MacOS and Windows are certainly not immune from it. You'd be surprised just how much people avoid using their computer altogether when they don't absolutely need it, just because it's slow as hell, just because developers in their ~ivory towers~ offices didn't do testing on reasonable second-hand hardware.
3 replies →
They do care if they have a comparison.
Spotify has certainly degraded over time. My latest frustration: Controlling external devices via my computer or phone.
I'll often play from my phone and connect it to my Echo speaker group. This used to work so seamlessly - it was beautiful.
But now - it takes 10 seconds for the initial connect. If I hit play/pause there's a 5-second delay to the point where I'll tap it twice, which is also delayed, and then it'll stutter and jump around. And worst of all: I'll hit pause, come back to it in a few minutes, and it's completely disconnected.
One of the big (for me) issues with the old, native client was accessibility, or the complete lack of it.
As a screen reader user, I couldn't use Spotify at all before the Chromium client was released, first in beta and then in stable.
Spotify's desktop accessibility was... passable, but far from great. It improved massively with the most recent UI redesign, which is almost universally hated by sighted folks.
This is a pattern I see pretty often, Reddit is another great example. Old Reddit is almost unusable to me, the new one is a massive improvement.
Rdio's app was stunning compared to Spotify imo.
Rdio was great, but it could not compete with Spotify’s performance. The funny thing is, those performance advantages (p2p streaming and a native C++ desktop client) are now ancient history. Rdio was ahead of its time.
Additionally Spotify's original app came out at the time iTunes was (is?) a big bloated mess, especially on Windows.
When Spotify came along it felt like a breath of fresh air, light, nimble, instant playback. Obviously the streaming approach was a departure from the older way, but it just felt so much better to use.
Such a shame they seem to have lost their way with the browser based thing.
> unauthorized clones
Are we really living in a world where we need "authorization" to replace some corporation's software with our own?
> Spotify's original client back in 2008 started out as beautifully light, custom rendered native client.
I think time is a large contributing factor. A lot of things start off simple and elegant. Then you have to come up with new features year after year after year (how old is the product?) in order to not appear stagnant and keep customers happy. "Oh, this other app got x feature, I want this in the app I use too!!!"
Here's kind of a video to illustrate the point, where Rick talks about iTunes. How it used to be, and how it evolved and is now. iTunes once ruled the world. It was simple, and elegant.
https://www.youtube.com/watch?v=MKJjLwMUPJI
Spotify removed a lot of their great social features from that time, as well as Spotify apps. Almost everything about Spotify has gotten much worse except the reccomendation algorithm.
You can build snappy UIs with Electron. It’s easy to conflate organizational bloat’s consequences with something intrinsic to Electron.
Edit:
Upset downvoters care to elaborate? Or just huffing into the void?
Didn't downvote, but can you name a couple of Electron apps that are sna...,hell,.. not sluggish?
People usually point to VSCode...If that is the epitome of a responsive, lag-free software then I claim Electron defenders haven't seen snappy application.
Do people even remember Winamp?
7 replies →
Maybe try elaborating yourself? The constant criticism of Electron Apps is that they're bloated and slow, you're claiming otherwise but missed the part providing any presumption of evidence to the contrary.
I've yet to experience any Electron App that's close to the snappiness and UX of the original native Spotify client, I'd like to hear about good examples of Electron Apps comparable to it.
23 replies →
Up-voted for the same reason as the edit - I'd love to hear some fact based arguments why this comment should be down voted (why it's not possible to build performant applications with Electron)
4 replies →
> Our QT/C++ client had decent performance but was noticeably heavier than Spotify's.
Wasn't Spotify's client Qt too ?
The original Windows and Mac clients didn't use Qt, it appears the Linux version released after did. Here's what I found scouting quora:
> Qt is only used on Linux. The native parts is built with our own custom toolkit on top of a canvas- and window-abstraction layer. The canvas/window stuff is implemented with Qt on Linux, but with native stuff on win/mac. Then we have the HTML5 views, which use Chromium Embedded Framework.
https://www.quora.com/What-is-spotify-Windows-Mac-GUI-app-bu...
> Proprietary technology written in C++, C and a tad of assembler. A list of third party technology used can be read by going to Help → Show Licenses in Spotify, or by opening file://localhost/Applications/Spotify.app/Contents/Resources/licenses.xhtml (if you're on Mac OS).
https://www.quora.com/How-did-Spotify-make-a-multiplatform-l...
The list of deps is insightful looks like they used WTL for their Windows UI, no idea how they made it work on Mac as well:
Boost, Expat, FastDelegate, giflib, libjpeg, libogg, libvorbis, Mersenne Twister, zlib, NSIS (Windows only), Windows Template Library (Windows only), Growl (Max OS X only), Lua
1 reply →
> started out as beautifully light, custom rendered native client
Very much expected - back then the main Spotify developer was Ludde, an author of another little marvel - uTorrent.
[1] https://en.wikipedia.org/wiki/Ludvig_Strigeus
Loading and rendering HTML can be extremely fast. The slowness we see with apps is a result of bloat, and it’s happened to our native apps too.
I really don't know what yall are going on about. I hit play on a song in spotify and it just plays instantly.
Even on the iPad app they don't follow basic things like swipe left on the edge to go back.
One thing that has devastated me about recent Spotify updates is that now, when viewing an Artist, you do not get to see all of the albums (or at least the first 10 newest albums) for that artist straight away with all of the tracks listed. It's now much harder to find a song that you don't know the title of, but you know an artist has sung.
It's also small changes that are extremely annoying. Pressing "New Playlist" used to come up with a dialog box asking what the playlist should be named. Now it just gets called "New Playlist". Clicking the playlist name to rename it does not automatically select the textbox to give it a name, meaning that to create a new named playlist - an action that used to take one click, is at least three clicks and two keyboard presses... I mean, come on Spotify!
The search bar used to always be visible. Now I need to click search first, then click the search bar.
To me, Spotify was the epitome of software completion five years ago. The client worked. It was perfect. It seems like every single update since they released the "Daily Mixes" has both downgraded the performance of the app, and made discoverability harder. I want Spotify how it was 18 months ago.
Spotify on my machine sometimes chews up 2GB of RAM. Reached out to support, and the best that they can give is "try restarting the app". That helps, until 12 hours later you need to do it again. A music player should not have 10% CPU usage on a modern MacBook.
Finding Psst has been a life changer.
Discoverability...
I'd pay handsomely for an app that did discovery on tracks and not artists. Last.fm kind of but not really does it. It took me many years to get from Sirenia: Seven Sirens And A Silver Tear to the Midnight Sonata (I can't remember alas who did it -- was it reddit or a forum on a now defunct tracker? all the great trackers are dead) and from there I was able to branch out. But this shouldn't be so hard..? We already have several music matching apps, surely closeness is a solvable problem.
> a forum on a now defunct tracker
Years have passed. I still havent filled the gap left by whatcd...
2 replies →
Try YouTube Music. There's a tab in the player that shows related tracks for each song you're listening to.
1 reply →
They really do make things worse and worse and worse. Related to your playlist example - saving an actual album I liked as a new playlist would give it a default title, "artist - album title" or something like that. Fine, 2 clicks: create the playlist, and accept the title.
Now? A blank text box. "Let's ignore the artist and album this user's basing a playlist on and make them type the whole thing from memory". I just don't bother any more, which seems petty but it's just so cumbersome, from mobile especially.
Oh wow. I thought that was only a mobile thing, going to have to check the "desktop" app now...
I have also noticed this. There isn't even a way to see songs, you always have to go to each album. I don't remember the album! Or the name of the song!
Under the artist's page, select their Discography. Songs not released under albums should show up under 'Singles'
2 replies →
I wonder if some of these decisions are driven by their business model. My understanding is Spotify's agreement with record labels means they have very low margin on a typical song stream. I've heard that some of their playlists are very valuable for artists and that there's some payola going on there. It could make sense that they're nudging people in those directions.
They also see much more upside in podcasts and thus are pushing people there.
I'm on the same boat: finding a song now requires too many clicks. Albums make sense in a physical world, but not in the virtual one.
An album is (ideally) carefully crafted to work as a coherent musical statement. Tracks in isolation don't have the same effect. It's even more so in classical music, where a work usually encompasses multiple tracks. One of my frustrations with Spotify is that it doesn't understand multi-movement works, so you get an single movement — sometimes even one that is connected to the preceding or following one — in isolation, and it's often really unsatisfying.
tl;dr I think albums have more significance than you do.
3 replies →
dunno how long it will last for, but you can add `ui.experience_override="classic"` to your prefs file to hold out a little longer.
Sadly, this does not work on the newest version of their client.
2 replies →
> The search bar used to always be visible. Now I need to click search first, then click the search bar.
This is a lie. When you click "Search" in the side bar the search field gets focused automatically. It is still just one click.
I just checked Spotify, and it seems like yes, it does now get focused automatically, not sure if it was always that way, or I just feel that I need to click the textbox after choosing the menu item on the left hand side.
That being said, it was still much friendlier to have a search box that you could click on straight away. From a UX perspective, you need to move your focus away from where you have clicked, because the textbox is in a different area of view.
Clicking back on the search menu clears the search that you were doing. It's fine, you can click the back button, but the old Spotify client (iirc!) would keep your previous search in the search box.
At this point, I'd be willing to pay for a Spotify client that works exactly the same, but just ignores the existence of podcasts entirely. I use a dedicated podcast client when I want to listen to podcasts, and they keep shoving them in my face and taking up precious UI real estate everywhere.
But any client without support for Spotify Connect might as well be dead to me. Controlling my wifi speakers from my phone, or playing music on my desktop Mac from my laptop or gaming PC is critical functionality at this point.
Check out spicetify cli[0]! It patches the Spotify (desktop) client and makes it better. It also adds support for extensions, one of which[1] disables the podcast features. I haven't used the extension so I'm not sure how well it works.
Heads up though, the original developer is MIA at the moment and the latest few versions of the client are incompatible. There's an effort by someone to fix the issues and there are other maintainers who mostly just seem to address PRs. Personally I just downgraded the client and it works perfectly.
[0] https://github.com/khanhas/spicetify-cli
[1] https://github.com/3raxton/spicetify-custom-apps-and-extensi...
I'd be willing to pay for a Spotify client that allows you to select your audio output device. And yet here we are, 10 years later...
Spotify is a marketing platform first and an audio player second.
If you’re on Windows, you can define audio input and output devices on a per app basis through Windows’ settings. Handy for any app that doesn’t support such configuration (though Spotify obviously should.)
2 replies →
I'd rather use https://staticz.com/soundcontrol/ (which I do use actually) than rely on an app like Spotify to be honest.
2 replies →
What platform do you mean? The iOS app lets me select output device. It’s a little icon next to play/pause, kind of half computer screen half bookshelf speaker (monitor/monitor :)
I think I remember seeing this on desktop too but at that point why not use the OS sound mixer?
3 replies →
Can't you just do that outside of Spotify? It would be nicer if you could in app, but with pavucontrol I have Spotify send music where it belongs.
They make it easy to play to any Bluetooth device or headphones. Covers my use case, but I can see it being annoying if it doesn’t support your setup.
2 replies →
Came here to say this. It was hard enough losing Rdio and now Spotify has been on a rapid decline for the last 1-2 years. It used to be a place to listen to music you already knew and maybe find something new and now they do nothing but shove podcasts down your throat. Who that works there is looking at the current UI as an improvement?
I loved Rdio for the Ui. I subscribed for years. That said Spotify has introduced me to so much music that I missed growing up.
The Spotify UI has been pretty painful lately but I have a hard time living because the suggested music selection has been so good.
I love my 3.5mm cables for this reason. No negotiating with vendors (except Apple but it's well known that they really suck) just plug and play.
I can't wait to sit my grandchildren on my knee and tell them stories of the magic headphones that you never needed to charge and just worked instantly with practically any audio device ever made by mankind right up until the iPhone 7 was unleashed unto the world.
16 replies →
I'm with you 100%. If they had a decent podcast experience, I'd be happy to switch but it's terrible. Why can't I mark something as already played?
Yep; I'm a paying customer of spotify and I like some of the podcasts they have. But they don't have the gap removal + speed controls of Overcast (my fav podcast program on my phone). So I'm in this weird situation of never wanting to listen to any podcasts through the spotify app, which I'm paying for. And then when I want to listen to music (eg while coding) I have to wade through podcasts which are intentionally designed to blend in with music recommendations in spotify's apps.
I hate it. If any spotify PMs are listening:
- If spotify wants me to listen to podcasts, let me do it from my existing podcast app. I'm sure the developer of Overcast (and other apps) would happily add a spotify login button for a song if you ask nicely and offered to pay.
- Let users disable podcasts entirely in the spotify app.
- In the spotify app, give podcasts a consistent visual differentiator so I can easily visually separate them from music. Nobody wants to be tricked into listening to a podcast instead of music. Maybe make the "album cover" for podcasts a rectangle instead of a square. Or change the background color for all podcast related content to blue so I can find podcasts visually (or filter them out visually) while scrolling.
6 replies →
If you care about Podcasts, don't listen to them on Spotify, ever. Spotify's plan is to build a walled garden around them.
Spotify promotes podcasts and buys exclusives so desperately, because their plan is to grow their audience to a too-big-to-fail size, so they start dictating their own terms. Every remaining use of RSS is a business opportunity.
You can. There's a "Mark as played" button in at least the Android Spotify app that I'm looking at right now.
Can't comment on anything else, though.
It’s insane that Spotify on Mac doesn’t support airplay.
When my girlfriend and I moved in together, we got rid of her Alexa devices because privacy and use HomePods. But Spotify doesn’t work with AirPlay for reasons I cannot fathom, so I set her up with a program that will AirPlay specific applications on her Mac.
That said, there are open source libraries and clients for AirPlay so it shouldn’t be too difficult to get them supported. I have a Raspberry Pi for streaming to “dumb” speakers.
Airfoil [1] is worth every penny. The same could be said for pretty much everything Rogue Amoeba makes.
It’s also worth noting that Spotify can act as a remote for its own service across devices. So you can start a song playing on your phone and direct the output over AirPlay and then just interface with that session using the desktop client.
[1] https://rogueamoeba.com/airfoil/mac/
If I understood your problem correctly, you need to listen to Spotify through your HomePod which is on the same local network as your Mac.
This is what I do on macOS. I press on the little megaphone icon (enable it in OS sound preferences) in menu bar and then I can choose my HomePod from the list, without any third party software. I am running Big Sur but in two previous versions I also did the same. Maybe I’m missing something here but I think it should work seamlessly.
1 reply →
I don’t understand, not a user of Airplay - your Mac doesn’t have a way to stream to airplay devices? Why does it come down to the app?
2 replies →
I gave up on Spotify because of this - and because of their hostile moves to turn podcasts into another centralized service.
Apple Music is still mostly worse without discovery, but at least lossless makes up the quality difference that use to be there.
Got me thinking. I wonder how much scope there is to build apps for platforms like Spotify which are built around a given use case.
For example - for people that prefer listening to albums. Or people that only care about political podcasts. Or something. I wonder if the global audience is enough to support indie products like this.
Significant platform risk though.
i don't like this podcast stuff either. even just the homepage that displays artists (that i will never listen to) is enough to annoy me. i would really love an option to open directly into my playlists or something else. im building up a local music collection at the moment so its not going to be annoying me for too long more
I love seeing software like this, even if it's not legal. Who cares? I remember being a teenager and trying out all sorts of cool underground, fundamentally illegal software, or stuff that worked around Terms of Service.
Where would the world be today without Napster? Maybe the same place, but provocative software is the definition of cool.
Nothing illegal about it, Spotify has a well documented API and supports third party clients
Eh. Ish. They only support playback within a browser and have deprecated native playback support years ago. Also their ToS technically doesn't let you do a looot of things you may want. Like caching. Srsly, you're not allowed to cache things. Many 3rd parties stopped supporting spotify because the dev ToS kept getting worse.
Regardless, I'm excited about this little project even if it goes against the ToS.
1 reply →
So does this version not have advertisements or something?
1 reply →
Things like Napster have a long tradition dating back to the 1960s, in the UK the response to the paternalistic and stuffy state monopoly on music broadcasting was for people to put studios and transmitters on ships parked just outside of British territorial waters. That’s really what fuelled the explosion in British music!
people on here care about laws too much. it's a api/webscraping tool redisplayed a gtk window. nobody is going to go to jail. even if they dmca it someone should just host the sources on anything other than github and let it ride. people cheat at videogames all the time, they can cheat on a music client.
Running the risk of being a dirty reposter and.. reposting. My little Spotify client is for macOS only, mostly only built for my own use, and a lot more minimal, visually. It's also native Swift though, so it's got that nice macOS feel. It's also pretty much 100% keyboard-driven (Vim keys, if that's something you like) and supports regex filters. It's just an open-source thing: https://github.com/toothbrush/Spotiqueue
I like this! Thanks for (re)posting it.
I love this! Thanks for making it.
This is good to see.
It shows you can write native cross-platform apps that are fast and have low system resource usage instead of the now default, packaging your app in a standalone resource-intensive web browser, aka Electron.
It's a shame we have a handful of people who can do this as a hobby project yet multi billion dollar companies with the money and manpower to do this don't, they chose Electron.
Druid is still not ready for prime time though (https://www.areweguiyet.com/). Played with psst for a bit: no keyboard shortcuts, no screenreader support, scrollbar feels 'off', stuff that just works if you use a native toolkit or a browser.
I get that this is early days for this project, but the issues are general for all of these non-browser, non-native UI toolkits. Hopefully we get there though.
Hi, the author here. Keyboard navigation is definitely something I'd like to focus on soon, the app should be 100% usable without a mouse. And accessibility is definitely on the Druid roadmap! <3
Keyboard shortcuts should be doable, I don't think this is a limitation of the toolkit.
Obviously screen readers are an important step, but we hope to be working with AccessKit.
In any case, though I'm not trying to represent Druid as ready for production use, I love seeing stuff like this. I think it's a good sign of what's possible and where things are headed.
Trying psst here on Linux I came away with the opposite impression - Druid's further along than I expected, it Just Worked at high DPI on Wayland better than most electron apps. I guess it'd feel worse on MacOS which already has a more consistent system UI.
We are (I hope) helping solve this problem at Kraken. We sponsor development of the iced library, which we're using to build https://cryptowat.ch/desktop. It's supported on Windows, Mac, and Linux and has received a ton of positive feedback about how fast and light it is. I have hope for the future, and don't expect Electron to stay dominant forever. Native GUI apps are slowly coming back.
https://github.com/hecrj/iced
love cryptowatch desktop! :) very performant.
1 reply →
Why do people keep forgetting this? You can use Qt to easily build a "fast" GUI that works on all platforms. And you can do it with Python via PyQt. No complicated C++ or Rust, unless you actually need it (which this almost certainly does not).
Picard is a good example of a PyQt app: https://picard.musicbrainz.org/
I suspect the real reason is that web developers are seen as a dime a dozen and GUI programmers more specialist and hard to find. This was the main reason my team chose to do an Electron app. We were already doing React on the website and nobody had any experience with Qt.
>It's a shame we have a handful of people who can do this as a hobby project yet multi billion dollar companies with the money and manpower to do this don't, they chose Electron
This is a purposeful decision though. How else could they track a thousand different metrics about you without 20mb of Javascript?
Why would an Electron frame allow them to track you more easily than a native desktop app that has access to your whole (userspace) system?
1 reply →
If it's just for tracking, why not ship a JS runtime and run the tracking in a separate thread. No electron needed.
2 replies →
Oh, don't forget the legions of cheap javascript newbs fresh out of boot camp that they can hire!
I'm going to give it less than a year now that it has been featured on HN.
This is too user facing and too easy to modify for DRM circumvention (if it isn't already doing that)
Whether it dies through a DMCA takedown or harder DRM measures remains to be seen.
I'm always sad to see people investing lots of time into creating great software that exists in a legal dark grey zone and will inevitably be nuked.
And yes I'm also not happy with the standard Spotify client
> harder DRM measures
Is that even possible for Spotify at this point?
The OP project is speaking to Spotify servers through the same means that official clients are, but the official clients are not just on iOS, Android, macOS and Windows.
There’s official Spotify clients on almost every platform imaginable. Everything from PS4 to built into TVs. And even a lot of stereo systems have Spotify Connect built into them.
Spotify Connect works by having these other devices streaming and playing the media, and your computer or phone acting as a “remote” for choosing the songs to be played. See https://www.spotify.com/us/connect/
Basically they’d have to break a lot of official clients, many of which probably cannot be updated, if they were to change their DRM scheme. How do you update a receiver for example? Well, you might be able to flash a new firmware with a USB stick. But for regular people, they are not going to do that. And the DRM scheme, at least as of yet, would be defeated by the reverse engineers as DRM always is. And hopefully continues to be.
So at least as of yet I think they would hurt people with official clients more than they would hurt anyone using an unofficial client.
And even people using unofficial clients are probably paying customers.
Besides what’s the point anyways, everyone knows that if you really really want to rip audio you don’t need to circumvent any DRM at all. You can play the song on your computer or your phone and take the analog signal that is going to the speakers and digitize it again and make an imperfect but still good copy of any audio. Admittedly it doesn’t scale anywhere near as good as automatically stripping DRM though.
Music publishers could demand better DRM in their contracts, though. That would lock out any devices incapable of receiving DRM updates, but it's certainly a possibility. If Spotify would refuse to budge, their platform would lose access to a lot of songs. If they agree, their users would have a terrible experience, only being able to play some songs on some devices.
In order for Spotify to have any decent user experience, they need to nip any DRM bypass as scale in the bud before the publishers find out, through cease and desist or worse. If better DRM becomes the only solution, everyone loses.
The difference between official and unofficial clients is that Spotify can have some (contractual) power over the official clients, like demand that music is cached encrypted, demand a certain limit for cached music, etc. Unofficial clients aren't bound by any contract, so the developers could easily do something they shouldn't be doing according to the terms and conditions Spotify lays out (or the terms and conditions of the copyright holders that Spotify must uphold).
> Is that even possible for Spotify at this point?
Spotify are using Widevine on their web client, which is considerably more annoying to deal with than the encryption method used in the files fetched by Psst.
Nothing is stopping them from only serving files from the endpoint that serves Widevine protected files.
Then again, Widevine L3 has been broken[0], Google just keeps rotating the private keys used in the content decryption module.
[0]: https://github.com/Satsuoni/widevine-l3-guesser
2 replies →
This is a great point. It's truly no different than a third party manufacturer writing some device firmware to connect with Spotify.
1 reply →
DRM for audio is so laughable. Any bit of patience allows for even the most rookie of users to rip a track from spotify.
If it weren't for all the legal agreements with copyright holders, I feel like spotify would already have an open playback API.
The name of the game is risk mitigation. In this case, there are lots of ways to rip a singular track. They are usually slow because you record the audio stream from Spotify.
But if you could get the original file from Spotify's servers and decrypt it yourself, you could automate downloading your entire library, offline forever at source quality DRM free. Unfortunately, that is illegal and Spotify is going to dick them with lawyers. Pretty sure that's what happened to this project: https://news.ycombinator.com/item?id=25017167
History: after the developer decided to pivot from only being a tool to scrape the encryption keys needed to decrypt an individual song, the developer decided it would be a good idea to build in automating the downloading and also decryption of those files, instead of letting people develop that as a separate tool.
Developer and project has disappeared shortly after that decision.
5 replies →
Rdio had an api that let you playback songs with a valid user token. It was really sweet.
Anecdotally, the only other Spotify UI I've seen on HN is still going strong after 2 years: https://github.com/Rigellute/spotify-tui
They don't break the DRM and use the official WebAPI.
> This app uses the Web API from Spotify, which doesn't handle streaming itself. So you'll need either an official Spotify client open or a lighter weight alternative such as spotifyd.
2 replies →
I've been using pianobar and pithos and pandoroid for my paid Pandora account for over 10 years.
> This is too user facing and too easy to modify for DRM circumvention (if it isn't already doing that)
How?
Google "pianobarfly"
You realize there are other unofficial spotify clients and have been for years don't you?
They do not exist in a legal grey zone. Spotify has open APIs. Using them is allowed.
librespot is a reverse-engineered thin client (using the same api that e.g. your "smart speakers" would). It doesn't use official APIs, arguably violates DMCA, and you pretty much have to use it if you don't want to simultaneously run the full thick official client on the same device at the same time.
> Psst: Fast Spotify client with native GUI, without Electron, built in Rust
I wonder what's faster: The new GUI, linked user accounts getting suspended or the project getting legal issues with the result of being taken down.
¯\_(ツ)_/¯
No, seriously. I support projects like this. But they pretty much always end the same. It's always sad to see so much effort go into waste. I get the motivation but I think there are a lot of other things to spend this kind of work on other than somethings that breaks a service's TOS from just reading the title.
This uses the same API as libspotify, a library for accessing Spotify for playback that Spotify released themselves. It’s not been supported for a while so future support for this API is unclear, but it’s not clearly going to be shut down like you suggest.
Apple Music also has an official and maintained API for building third party clients.
Spotify API is open. He is not breaking any ToS.
The DRM decrypting stuff is breaking the ToS.
1 reply →
I think the idea of desktop apps being web apps repackaged is now so ingrained that some people have never experienced true desktop app performance.
As in, zero latency, or no observable latency. Instant performance. Honestly, it sickens me how spectacular advances in hardware translate into performance being worse than before.
Even the Office client apps are now web (React). And you can tell. Sluggish and glitchy.
As for the Spotify app, I have little love for it. Overengineered garbage where the simplest actions leave you searching. Internally, they have created this massively complex structure of squads and tribes each taking care of just one tiny part of the experience. This may explain why Spotify is so disconnected and makes no sense.
All of this engineering effort, I imagine there to be at least a few hundred working on it, ultimately add up to an experience less usable than bloody Windows Media Player from the 90s.
MS Office is React now? Wow. Does not surprise me though.
That statement's horribly misleading. The desktop versions (eg. windows or mac) aren't, but the web versions are.
3 replies →
Just downloaded this to try it out... This is now my new Spotify client!
It's so damned efficient it barely registers in my CPU monitor. Check out the memory utilization too!
https://i.imgur.com/Fa3Dnnb.png
Now compare it with the semi-official Spotify client:
https://i.imgur.com/nNWFIj1.png
According to this: https://forums.overclockers.com.au/threads/winamp-memory-usa...
Winamp 2.72 only used about 8 megs of RAM.
Eight Megs And Counting.
Wow, eight megs was once so much memory that we would laugh about applications that even approached it.
1 reply →
Hi, I'm glad you like it! The performance is not _that_ good at the moment, mostly because of superfluous paints, but it's something I'd like to focus on (as it's one of the primary objectives).
So Electron is the problem. It gets worse if you have lots of tabs open in Chrome + running other electron apps as well. A visible and obvious improvement when compared with a native app.
Also, Electron apps do not scale and it wastes CPU time, eats RAM up and fills up HDD space. On laptops, it drains the battery faster.
A quadruple negative to the user.
The second one should be sorted by name to show that there are actually multiple spotify processes. (There's another one near the bottom of the list.)
I wonder what the footprint will look like once the author writes in all of the missing features
I wonder if that executable is stripped, often that saves a decent chunk of memory.
It'll save disk space but not resident memory? Debug symbols etc shouldn't be paged in. The Linux binary goes from 20MB to 10MB stripped.
I've never given Spotify a try because of the crummy web/Electron player I saw everyone using. Wanted to try this out, but it only works with a premium account. That could've been mentioned more clearly, would've saved me the effort of compiling this thing.
I can't judge the main application but just the settings screen makes me feel like the UI library powering this isn't quite ready for prime time yet. I consider shortcuts and basic text handling like ctrl+a to select all text in a textbox to be basic features for any UI toolkit; the lack of such ease of use features really makes the GUI toolkit feel less native than the Electron cruft that's overtaking our desktops.
As for the legality, the DMCA sucks but this client is definitely in violation of it. Breaking the TOS isn't necessarily illegal so the tool is fine to use (at the risk of getting your account banned) but development can be quite risky. Hopefully, Spotify takes an interest and uses (a fork of) this project to write a faster player for their desktop clients instead of cease-and-desisting it to hell.
>it only works with a premium account. That could've been mentioned more clearly
I agree, although it looks like you only have to change a single line of code to make it work without a premium account. Might as well go all the way if you're already breaking the TOS anyway I guess.
This is not really the case, you need a Premium account for Psst to work.
1 reply →
> As for the legality, the DMCA sucks but this client is definitely in violation of it.
How is it definitely in violation of the DMCA? (Not a lawyer and not a USA resident, would appreciate legal clarification)
Any circumvention of DRM, even simple DRM as long as it's not too trivial, is considered illegal under the DMCA. The decryption routines Spotify uses should definitely be considered non-trivial DRM.
Not who you replied to, but if anything decrypts a DRM stream in an unauthorized way, it technically is breaching DMCA. I assume that is what they meant.
I've been running this for the last 5 hours, since I saw the posting. Thankfully, in arch it's just part of the aur.
Frankly, it's awesome. It's literally every single thing I dislike about Spotify fixed. There are no podcasts, I can search, there's no social senselessness anymore.. I'm thrilled.
The only problem I have is that eventually it just gobbles CPU. Having it open and doing nothing seems to take ~4% of my CPU, and while playing a constant 7.2%. Frankly, I assume this is decoding, but I haven't traced yet. Eventually it spun out of control and pegged one CPU at ~90%, which a quick restart fixed. All of this is to say it's an incredible project - I'm not going back to the old client.
This is great, but the sad truth is that unofficial clients like this can never grow big and support more than a few thousand users, given how ridiculously low Spotify API's rate limits are.
My project https://volt.fm has 100k+ users now and I'm really struggling with the Spotify API.
The trick would be to have each user register their own API key.
This seems like such an obvious answer, why isn't it significantly more common?
5 replies →
Also, they can lock out out overnight and good luck appealing to the legal team.
How does the nature of the API determine the number of users?
I meant rate limits. Edited my original comment.
Slightly off topic, but it’s a shame Spotify’s web API doesn’t support (and they’ve said never will support [1]) playlist folders. I get that it’s a bit of a power user feature but it’s an essential one for me in any media player.
Makes me worry they’ll remove the feature from their app one day (they allude to it being a bit of a mess in the database) which would be the push I’d need to move away to either another service or a local collection only…
[1] https://github.com/spotify/web-api/issues/38
Nit: Spotify isn't electron-based.
https://www.quora.com/How-is-JavaScript-used-within-the-Spot...
"Chromium Embeded Framework". When people say Electron based they don't really care if it's using Electron or any other browser. It's still a browser. And it's therefore at least 100x slower than it could be.
And when people say "iPhone" they don't really care if it's an actual iPhone or just any smart phone?
Spotify regularly upsets me with change. Don't change a UI that looks good and works well just to hide something I need. It feels like it's just justification to have an entire team of client designers employed.
I remember when Spotify had Lyrics, which is an obvious choice of feature for a music service. It was off my a line or two, but it worked pretty well and I used it all the time. It was the best way to hear the music and see the lyrics that I knew of. Then, one day, I open the client and see that clicking the lyrics button showed a message that the lyrics feature was being enhanced and it'd be back soon. Then one day the button disappeared.
The only reason I use spottily over local music at this point is discovery, because they really do a great job at that.
I've been using Spot[0], which is another Rust Spotify client using GTK.
[0]: https://github.com/xou816/spot
And for those wanting a ncurse client, there is ncspot [0] which is quite stable and complete.
[0] https://github.com/hrkfdn/ncspot
I never really got into Spotify because I found the UI so confusing, clearly designed for "engagement" instead of usability.
But this is perfect:
- search for the name of an album, press enter and voilà it plays the album in order like I expect
- Playback takes 1% CPU and 0.1% of RAM
- vim-ish bindings
- It even works with physical play/pause/next... keys on my keyboard
Thank you!
Instantly installed and wow - this is outstanding. Thanks for the recommendation, had never heard of it.
I actually liked this a bit more than Psst, thank you for the comment
people who are interested in this will also be interested in ripcord [0], a native client for discord and slack.
[0]: https://cancel.fm/ripcord/
Ripcord is excellent but you need to generate a new login token every few weeks. Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want.
> Sucks that these companies like slack and spotify et al. don't just offer the tooling themselves that a subset of their customers clearly want
It would give up control and it's an admission of failure; a slap in the face to some project lead, some designer, some exec, showing that their brilliant ideas were not in fact the superior option for everyone forevermore.
Either of those are unacceptable enough to lock the system down. But both? Never in a million years.
I have not had to do that.
1 reply →
From the Ripcord page:
"Shareware is coming back, baby."
This is quite amusing. Further down:
"How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Shareware sometimes used to provide a way to check for updates, and sometimes allowed for this to be done automatically. But it generally did not try to make network connections without any permission from the user.
Shareware often used to provide contact information for the author so that users could show their appreciation. Authors invited voluntary feedback.
Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Anyway, his answer is:
"Set the environment variable RIPCORD_ALLOW_UPDATES=0"
How about starting the program while offline, i.e., network interface down.
> As I recall, shareware never did that. It violates the spirit of leaving the user alone, user automonomy.
Lots of shareware did and does that. It's normal. It's just an update check. It doesn't self-update. It doesn't transmit any information. No logs are collected. It just displays a "update is available" message if it finds that an update is available, with a link to the website to download the new version.
> Today authors instead try to perform telemetry and control the use of the software after download through "automatic updates". They seek to gain from users' laziness to change defaults. They want to collect information about users and their usage habits. "Involuntary feedback."
Ripcord doesn't send any information about the client when it checks for updates. No information is logged on the server. It just fetches from this URL: https://cancel.fm/ripcord/updates/v1
Ripcord does not have any kind of telemetry or analysis system in it. It doesn't even report which OS you're using to the static file HTTP server — the update info URL returns the information for every OS at once.
> How about starting the program while offline, i.e., network interface down.
It works fine if you do that.
> "How do I prevent Ripcord from checking for updates before I'm able to open the preferences window to disable it?
This is provided as a way for users who extra paranoid to turn it off outside of using the normal preferences in Ripcord, since that requires launching Ripcord at least once. It's not the only way to do it. (It'a also useful for package managers on Linux who don't want "update is available" notifications to show up for their users.)
The normal preferences window in Ripcord has a clearly labeled checkbox on the first page for turning update checking off or on. I don't know what alternative there is. If it was off by default, most users would ask why it was off by default and why are they being tricked into being left to use outdated versions. I don't know any software that does this.
1 reply →
I have heard that discord is quite active in banning users of alternate clients and even slight CSS tweaks, when they can manage to detect them.
looks very cool, might switch back to spotify just for this. the speed and feeling of pre-bloated iTunes is still the benchmark to which i hold any music app, and this might be the next best thing.
appreciate the work here.
I love the look and idea of this - are alternative clients against the Spotify ToS though?
Would be such a shame to put in all this work only for Spotify to kill it.
It uses private APIs to retrieve the decryption keys from the server and circumvent the DRM.
It's certainly against the ToS and probably illegal in some jurisdictions
Usually the way it works is that _using_ the software is illegal, but distributing its source code is not. Code is covered by the first amendment in the US.
1 reply →
Related to the Spotify desktop client, I still don't understand why I have to restart the app when my internet connection is interrupted.
I hope this becomes popular enough that Spotify buys this and makes it default. I have not used this but anything is better than current Spotify memory hog. I miss those WinAmp days.
Anyone thinking this is delusional. Spotify works in a browser and there’s no non-CSS-based framework that can do that.
The reason Electron is popular is because you can have a single codebase for ALL the targets.
> a single codebase for ALL the targets
Spotify even has a pretty detailed post on this:
https://engineering.atspotify.com/2021/04/07/building-the-fu...
Actually, you could just use use react (or vue or angular with nativescript) and have one codebase with a __native__ ui on desktop + css on the browser, but keep the app-logic and UI code the same.
> Spotify works in a browser
Anecdata: I have used this functionality literally once in ~5 years. Safe to retire it and build a real client. I suspect most people don't use the browser.
2 replies →
So right. As soon as you are the person paying for people and time to develop native apps, you start thinking, "Geez, I could make an identical UI with web technologies and skip all the platform stuff entirely!"
These apps are identical to native. Not one person could tell you the difference. The complaints about speed are nonsense, too. People don't benchmark apps. They use them! These Electron and other web-wrapper apps are absolutely the future of all client-side app development.
If native apps are the railroad, web apps (w/ or without a wrapper, makes no difference), are the airplane.
BTW, there are many complaints about the Spotify UI, but does anyone ever complain that it's a web-based UI? Who has ever said, "Wow, I like Spotify but, ya know, it's got a UI built with HTML and CSS and JS, so I don't wanna use it."
That's not real. Proprietary app wrappers are proprietary because the companies that make them benefit from lockdown. They will always promote their locked-down platforms, and many enterprises have millions of dollars of sunk costs in these siloed application environments. The way out of prison is through web-based apps that run anywhere without the user even knowing or caring how that happens.
This feels like such a breath of fresh air. I wish there comes a wave of such native implementations of popular electron resource hogs - Slack, Teams, WhatsApp etc.
What I don't understand is: How many developers do you really need to create a native Spotify client?
My pet complaint is Google Chat, which is now a web app or a PWA. Seriously, I don't believe that Google can't afford to have three Mac developers assigned to Chat and create an awesome native application, rather than shipping that piece of junk PWA. Similarly I don't buy that Slack, Facebook and Microsoft can't hire or train the most bad-ass Mac or Windows developers to work on native versions of their products.
Looks really nice! I switched to Apple Music like a year ago but if this is good then I might switch back to Spotify.
I remember seeing some demos of the UI library Druid in the past but I didn’t realize it was at the stage where complete applications like this could be built.
Is there any plans for iOS support?
Just cloned and built this - was running within 3 minutes with no effort. On Windows. That's unusual for native GUI apps to say the least.
Didn't know Druid was even at this stage yet so that's nice to see. It's definitely living up to the goal of 60fps smooth resizing.
I am definitely going to check this out. I use the Spotify snap under Ubuntu as I never got Spotify client working when I upgraded to the lastest Ubuntu and they keep working on the main stable. I do not hate the UI of Spotify but having alternatives is really nice. I also have Spot installed. It is also a simple and native application to listen to your music. I am a very heavy Spotify user. We have a family subscription so my kids have their own premium. Last year I listened to 60K songs; I really like the yearly review BTW. Yesterday I was talking to my wife and we just swallowed the pill completely and we will be throwing out our CD collection to make room for a new cabinet (I currently own around 1000 CD's).
On the desktop, I simply use a separate Firefox profile for Spotify with the web client. The only 'special' thing is that I had to disable ServiceWorkers because they somehow caused some trouble every few weeks (dom.serviceWorkers.enabled = false). In addition, I use KDocker for a system tray icon.
However, on mobile it is a completely different story. The Spotify app requires so many resources that it takes forever to start (like a minute) and sometimes even causes my phone to reboot. For something like a MP3 player that is hilarious...
Does someone know if there is a good alternative mobile app?
Why the hell is there not a stateful GUI markup standard? Mice and desktops did not go away with the advent of mobile. They are still the bread and butter of business, for example.
Thus, rather than reinvent the GUI adapter wheel for each and every programming language, let's form a dynamic GUI markup standard based on existing open-source kits to avoid starting from scratch (Typically Tk, Qt, or WinForms. WinForm's base is OSS, believe it or not.)
Then languages can read and write markup (XML or JSON text) to have GUI's instead of glue on some screwy binary addon.
For the last couple of months I am using open.spotify.com (i.e. I uninstalled the native Windows app). Works great, not sure if I am not losing some audio quality, but if I do - I have not noticed.
Didn't build on macos 11.5
``` Compiling sized-chunks v0.6.5 error[E0658]: `if` is not allowed in a `const fn` --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:119:5 | 119 | / if element_size == 0 { 120 | | usize::MAX 121 | | } else if element_align <= container_align && host_size > header_size { 122 | | (host_size - header_size) / element_size 123 | | } else { 124 | | 0 // larger alignment can't be guaranteed, so it'd be unsafe to store any elements 125 | | } | |_____^ | = note: for more information, see https://github.com/rust-lang/rust/issues/49146
error[E0658]: `if` is not allowed in a `const fn` --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:121:12 | 121 | } else if element_align <= container_align && host_size > header_size { | ____________^ 122 | | (host_size - header_size) / element_size 123 | | } else { 124 | | 0 // larger alignment can't be guaranteed, so it'd be unsafe to store any elements 125 | | } | |_____^ | = note: for more information, see https://github.com/rust-lang/rust/issues/49146
error[E0599]: no associated item named `MAX` found for type `usize` in the current scope --> ~/.cargo/registry/src/github.com-1ecc6299db9ec823/sized-chunks-0.6.5/src/inline_array/mod.rs:120:16 | 120 | usize::MAX | ^^^ associated item not found in `usize` | help: you are looking for the module in `std`, not the primitive type | 120 | std::usize::MAX |
error: aborting due to 3 previous errors
Some errors have detailed explanations: E0599, E0658. For more information about an error, try `rustc --explain E0599`. error: could not compile `sized-chunks`. warning: build failed, waiting for other jobs to finish... error: build failed ```
If I had to guess, I'd say you're using a too old versions of rust.
In the future, one will be able to give a nice error when this happen (https://github.com/rust-lang/rust/issues/65262) But now it's true that it can be hard to know what the problem is.
Yep, the two missing features are `usize::MAX` (stabilized in Rust 1.43, April 2020), and control flow in const fns (stabilized in Rust 1.46, August 2020).
Wow! Could Rust return the desire to build fast native UIs? I sure hope it does. And also is there Apple Music native app? Because the standard client is such a mess of an app.
Good news. We need more native apps, which work autonomous and locally and optionally sync with servers. Examples are Git (yeah! --everything-is-local) or any decent Mail-Client. Especially what the industry usually does is not the best, but just the cheapest.
https://josephg.com/blog/electron-is-flash-for-the-desktop/
A project like this cant come fast enough. Spotify desktop on Linux is a bloated mess that regularly crashes and takes down the display server with it.
It's working just fine so far on Linux even it sounds like they're mostly using MacOS. I could see using this a lot if playlist support was added. It seems snappy. I'm kind of surprised that htop reports 165M and Cpu reporting 38-45% which seems a tad bit high for playing a sound file O_O . I know it's early days though, so I'll keep an eye on it for sure. Very clean interface.
Hi, thanks for being interested! There've been some regressions lately, sorry :| Performance is #1 priority for me, and a big focus now, after last round of refactorings.
Spotify should pay this guy to make their official native client or at least license the software from him.
Is it just me or does the play buttons triange in the screenshot look horribly uncentered. Seems like the like positioned based on minimum/maximum horizontal extend whereas aligning the "center of gravity" with the circle center might make more sense.
Tried to build on M1/Apple Silicon, but hit some errors. Looks like one of the dependencies isn't playing nice with arm but would love to give this a try.
Any rust devs have second? I think its the miniaudio dependency that's broken.
This link should help[0]!
[0] https://github.com/jpochyla/psst/issues/87#issuecomment-9003...
Check the workflow for artefacts, the macos build runs on m1.
IIRC the workflow targets macOS-latest, which is macOS Catalina 10.15 and the default host is `x86_64-apple-darwin`.
Does Github Workflow currently support M1 (arm 64 based). Am I missing something?
1 reply →
I hope the team considers abstracting this codebase into a general framework after its reached a sufficient level of maturity.
Would be nice to have a growing ecosystem of high-performance, rock solid, cross-platform native app frameworks.
For linux there is a snap of the app available, which is a lot easier than building it from source: https://snapcraft.io/psst-gui
Great work!
The part I don't understand is how do you find the motivation to write such time taking things? Outside work? At work? I guess you don't know whether this would be profitable or not, how do you stay motivated?
Thank you! I took some time off after finishing my last full-time commitment, and wanted to cut my teeth on Rust a little bit -- exploring how feasible building cross-platform native apps is right now. So I've started building something that I'm missing and would like to use. Combine this with the pandemic, and here we are.
Thanks for the answer!
Can you decouple the UI from Spotify and make a generic interface to plug in N streaming services? Then people could make a Spotify provider, a file provider, a Pandora provider, an Amazon music provider, etc.
I believe this is the goal of mopidy
Close, but that looks like a server, I guess a client front end for it could be written in a native GUI.
I would love to see something like this adapted for YT music?
> Spotify client with native GUI, without Electron, built in Rust
Does this use system UI control bindings? What makes a UI "native"?
Nice!
I also suspect that this one doesn't destroy ssds by running OPTIMIZE or whatnot on its internal sqlite, unlike the official client?
YouTube Music – what do you guys think is the best client for this? Because YTM doesn't have its own app. Thanks!
The play button in the image looks off-center. Probably a case of centering horizontally as opposed to the centroid.
Really great job.
I wish there is one for apple music.. Since switching to apply music it has been a pain to open iTunes in my PC.
I expect it will soon run into the troubles that NewPipe/SkyTube or even Barinsta suffer from.
This is amazing! Anybody knows anything similar for other music services like YouTube Music?
Add private listening by default and I’ll forget many other features
This is excellent, just what I use spotify for, music.
This is awesome. I wish something like this existed for Slack!
edit: it does[0]!
[0]: https://news.ycombinator.com/item?id=28205333
So how do I download and run this on mobile phones? Would like both on Android and apple, is this possible?
And like moths to a flame, any mention of electron on HN spurs complaints only this community cares about.
Everyone hates slow, laggy, shitty software. The average consumer just has no insight as to why their software experience is bad. But don’t be fooled. A snappy, smooth experience does matter to consumers. Even when they can’t even quantify why one app “feels good” and another “feels bad”.
fast enough is good enough. All the words you used to describe a good experience are subjective and relative.
1 reply →
No ad blocking feature?
Since this client (like all third party clients) requires a spotify premium account, ad blocking shouldn't be necessary.
What a rookie mistake, making this open source. Hopefully the author wises up.
A vote for open source is a vote for minified javascript.