Live data from Hacker News

Fastpotify

fastpotify.rocks

181–190 of 583 posts

Re: Fastpotify

#181
post #174

Lots of people seem to care about whether a project was built by hand over time by a few committed developers, or if it was vibe-coded in the past week by a single person. Whether the distinction matters or not, it would be nice for everyone involved if projects falling into the second category were more upfront about that.

As a matter of interest, would seeing a full disclosure that vibe coding was used sway your decision one way or the other?

Due to security and future updates, yes.

Re: Fastpotify

#182
post #174

Lots of people seem to care about whether a project was built by hand over time by a few committed developers, or if it was vibe-coded in the past week by a single person. Whether the distinction matters or not, it would be nice for everyone involved if projects falling into the second category were more upfront about that.

As a matter of interest, would seeing a full disclosure that vibe coding was used sway your decision one way or the other?

Yes, a project maintained and built over longer time has a bigger chance of staying relevant, than someone's weekend fun they will abandon once the dopamine hit of "making something" wears off.

Re: Fastpotify

#183
post #174

Lots of people seem to care about whether a project was built by hand over time by a few committed developers, or if it was vibe-coded in the past week by a single person. Whether the distinction matters or not, it would be nice for everyone involved if projects falling into the second category were more upfront about that.

As a matter of interest, would seeing a full disclosure that vibe coding was used sway your decision one way or the other?

I'm not sure what decision you're talking about. My comment just mentions that it would be convenient if disclosure of vibe-coding was more common.

I can look for myself and see that the repo was started a week ago and has had hundreds of commits since, and that the author exclusively talks about ai on twitter. I'd just like it if I could save myself some time, and it would prevent useless discussions in this thread were people argue whether the commit-messages look like ai.

Re: Fastpotify

#184

I realise I’m pissing into the wind here, but I find the LLM text on the homepage and docs quite funny/ awkward. > “Ctrl+M turns it into a tiny player that wears any classic Winamp 2 skin, spectrum analyser, equalizer, and playlist included. 2000s vibes, pixel for pixel.” Everything is said with too much intensity, and phrasing that sounds impressive but doesn’t really mean that much. Like “wears any classic Winamp 2…

If it can transform into Winamp I don't care if the code is LLM generated, typed by infinite monkeys or found in some ancient scrolls. Jokes aside, how can you be sure that the official Spotify app (or any app, or Windows) was not written by a LLM without supervision?

The official Spotify app has some skin in the game. Random dudes self promotion project, not so much.

Re: Fastpotify

#185
post #49

If you're focused on lightweight, native and fast, I don't think you should use an immediate-mode GUI toolkit. Why does an app like this need to hit a 60fps framerate? It's not a game.

[deleted]

Re: Fastpotify

#186

I realise I’m pissing into the wind here, but I find the LLM text on the homepage and docs quite funny/ awkward. > “Ctrl+M turns it into a tiny player that wears any classic Winamp 2 skin, spectrum analyser, equalizer, and playlist included. 2000s vibes, pixel for pixel.” Everything is said with too much intensity, and phrasing that sounds impressive but doesn’t really mean that much. Like “wears any classic Winamp 2…

LLMs seem to have been fine-tuned to use metaphors, presumably because they read like vivid creative writing. The over-use of metaphor in LLM-produced text is exhausting.

Re: Fastpotify

#187
post #117

Spotify is in the process of killing the librespot project that this and most third party Spotify players are built on. I think the golden age of music streaming is coming to an end. I’ve migrated to a self hosted library with streaming and radio for discovery. I hope we’ll see many projects in the space flourish. Many, like Navidrome and the whole OpenSubsonic ecosystem, seem to be doing quite well.

> Spotify is in the process of killing the librespot project Source?

https://github.com/librespot-org/librespot/issues/1649

Re: Fastpotify

#188
post #49

If you're focused on lightweight, native and fast, I don't think you should use an immediate-mode GUI toolkit. Why does an app like this need to hit a 60fps framerate? It's not a game.

Author here. Two reasons I chose an immediate mode UI framework:

1. Latency. A click paints on the next frame, because it sidesteps the stages of a retained mode UI: there's no dirty-marking, no layout and paint passes scheduled for later, no cached visual state that can be stale.

2. Simplicity. The UI is a plain function of app state. There's no retained tree to keep in sync and no invalidation bugs: mutate the state and the next frame shows it.

Yes, the drawback is that you have to watch what a frame costs, but it doesn't repaint at every frame. It paints on input and you can schedule repaints yourself. Fastpotify sits at zero CPU when idle, asks for a few frames a second while a track plays, and runs at full rate only while you scroll.

Re: Fastpotify

#190

I realise I’m pissing into the wind here, but I find the LLM text on the homepage and docs quite funny/ awkward. > “Ctrl+M turns it into a tiny player that wears any classic Winamp 2 skin, spectrum analyser, equalizer, and playlist included. 2000s vibes, pixel for pixel.” Everything is said with too much intensity, and phrasing that sounds impressive but doesn’t really mean that much. Like “wears any classic Winamp 2…

Uncanny valley. LLMs are great at producing text that reads almost right.
Post reply on HN