I remember with nostalgia the mp3blaster. I spent years listening to it in my terminal. At one point I used only cli without graphical desktop on slackware and one of my TTYs was dedicated to it.
Turns out these times are forever gone - never to come back. The huge disappointment when I tried this on the first run to play a mp3 file from my local disk and it initiated outbound connection. Why a local CLI player needs outbound TCP connection to play a local file from my local disk?!?! The answer was in the source. It is called telemetry. Back then when I used mp3blaster we used to call this spyware, but the times had changed since then.
Back in the day I used to use mpg123. It's still available, but most of the time today I use mpv (successor to "mplayer", handles video too, opens a separate window, zero chrome) or ffplay, since they have wider format support.
No playlist or even file management - they do show id3tags, that's about it. No telemetry, SaaS chicanery or "improvement" upgrades every few days, either.
I just woke up this morning and I am amazed. I am taking all my nasty words back and I starred the project and followed the author who reacted so fast to my dull negative feedback and this reaction shows how much he cares about the project.
My issue with telemetry is that 99% of software ends up not using it. Why have it? And definitely don't have it by default. Your users will come tell you what they want, making telemetry useless, especially when it's an OSS project you're mostly building for yourself.
Except that telemetry can give you more complete (and foolproof) information than what users report. But yeah, that could also be solved by having debug info that users can attach to their report, the app doesn't have to "call home" for that...
I agree, but it's a cost/benefit thing. Most OSS projects aren't big enough to do anything with the telemetry, so you're just paying in goodwill for no reason.
IP address (which can be geolocated) along with a unique identifier is not considered "personal data"? This is basically a tracking cookie. It also seems to use HTTP, which is itself widely fingerprintable based on what request headers it sends.
I saw it, it is NOT spyware. It just sends a random UUID. It is just a personal disappointment for the fact that it is something so simple as a console player and yet connects somewhere. But that's just me. I grew up in other times.
Also I just compiled mp3blaster and I am listening to it again. So cool!
Like others the telemetry is hugely undesirable nor necessary. Likewise if they truly don't collect your IP as they claim it's just ripe for endless abuse.
Winamp was pretty cool. When I switched to Linux, many years
ago, I wanted to have winamp too. I think I used bmp for a while
until it died; before that xmms but that one also sort of died.
Meanwhile some other GUI showed up, I forgot the name. I kind of
gave up on winamp, mostly because my use cases shifted. I went
to mplayer, then mpv, and now I am too used to using mpv for
literally anything related to audio and video (which in turn uses
ffmpeg of course). I kind of built a commandline helper variant
that just plays anything I have local - audio, video. I could
probably go and find a nice UI again, and that may have advantages
such as simply scrolling through the list or setting ad-hoc favourites,
but I don't quite need it anymore; I am faster with the keyboard
too, so my use cases changed. To play all audio from Hans Zimmer,
for instance, I may type "rsong Zimm" or something like that. (I
also alias a lot so I may just type "zimmer" instead, but most of
the time if I use it I just have it default to random selection as
I don't care what is played normally.)
The not so good parts are 1) it is written in Rust and therefore packaging is awful with a lot of dependencies; 2) it repeats playlists by default with no option (so far) to turn that off. But there's an issue open on it and it looks like this is going to be fixed.
This is cool! I wanted to make a basic CRUD form to update meta data and was considering go, lots of neat libraries to take a look at.
Interesting that it uses charmbracelet libraries to create the terminal components. I often have a hard time understanding how to use charmbracelet effectively, for minor TUI things I prefer tview more.
Anyone know any good tutorials/blog posts about building something complicated with bubble tea? I feel like the charmbracel docs are way too "happy path" if that makes sense?
I’ve been using this in Omarchy, it’s really great - easy to use and can do any songs or playlist on YouTube, so I’ll pipe through those programming concentration playlists without visiting YouTube.
As someone who is fond of Windows music players and futuristically designed DIN stereos of the early-to-mid 2000s, the variety of console visualizations is wicked cool and very much welcome! This is easily the best feature of cliamp. I'd love the collection of visualizations as a separate program, akin to cava[1], that listens and responds to your default audio sink. I already use a Raspberry Pi for music while driving, so I'm already thinking about displaying these visualizations on my car's infotainment screen somehow.
As a friendly request, I'd love to be able to use up and down keys to seek one minute forward or backward during playback, like with mpv. I play a lot of mixes that are an hour or longer in length, so this functionality would be a nice-to-have. I'll likely submit this idea to GitHub, anyhow.
To share some honest criticism, I was disappointed to discover built-in telemetry. Although it can be disabled with a flag, I dislike how it's enabled by default and unknown to the user unless one specifies the -h flag. I don't understand why user diagnostics data is needed from a console music player. Make this anti-feature opt-in and instead rely primarily on bug reports, or make the user aware of this telemetry upon initial invocation and provide instructions on how to disable it. Constructively, know your audience.
But overall, thank you to all the maintainers for this cool software!
There may not be many like me, but I sure as hell appreciate a clever name. A great name is extremely hard, but figuring one out can make or break a project.
I remember with nostalgia the mp3blaster. I spent years listening to it in my terminal. At one point I used only cli without graphical desktop on slackware and one of my TTYs was dedicated to it.
Turns out these times are forever gone - never to come back. The huge disappointment when I tried this on the first run to play a mp3 file from my local disk and it initiated outbound connection. Why a local CLI player needs outbound TCP connection to play a local file from my local disk?!?! The answer was in the source. It is called telemetry. Back then when I used mp3blaster we used to call this spyware, but the times had changed since then.
The times haven't changed. It's still spyware, it's just been normalised.
Back in the day I used to use mpg123. It's still available, but most of the time today I use mpv (successor to "mplayer", handles video too, opens a separate window, zero chrome) or ffplay, since they have wider format support.
No playlist or even file management - they do show id3tags, that's about it. No telemetry, SaaS chicanery or "improvement" upgrades every few days, either.
OIC: https://github.com/bjarneo/cliamp/blob/main/telemetry/teleme...
Should be easy to nerf, but the build instructions are kinda vague. Clone, and then what? Something like "go build" or something I guess.
Looks cool though
It's gone: https://github.com/bjarneo/cliamp/commit/085734a86343a80176d...
I just woke up this morning and I am amazed. I am taking all my nasty words back and I starred the project and followed the author who reacted so fast to my dull negative feedback and this reaction shows how much he cares about the project.
Thanks for pointing this out, to me it seems quite a good response.
I wouldn't mind opt-in telemetry, but possibly the participation rate would be too low to make use of it.
My issue with telemetry is that 99% of software ends up not using it. Why have it? And definitely don't have it by default. Your users will come tell you what they want, making telemetry useless, especially when it's an OSS project you're mostly building for yourself.
Except that telemetry can give you more complete (and foolproof) information than what users report. But yeah, that could also be solved by having debug info that users can attach to their report, the app doesn't have to "call home" for that...
I agree, but it's a cost/benefit thing. Most OSS projects aren't big enough to do anything with the telemetry, so you're just paying in goodwill for no reason.
Opt-in via extension, fine. Opt-in via flag, unreliable. The spyware code should never be anywhere near the main codebase.
Yay! Also, I hadn't noticed an entire section about building from source. Sorry about that. Good work!
Woo, good on them
No personal data is collected
IP address (which can be geolocated) along with a unique identifier is not considered "personal data"? This is basically a tracking cookie. It also seems to use HTTP, which is itself widely fingerprintable based on what request headers it sends.
There's a config variable and a cli flag to disable.
That seems reasonable to me.
to disable
All such surveillance behaviour should strictly be OPT IN.
I saw it, it is NOT spyware. It just sends a random UUID. It is just a personal disappointment for the fact that it is something so simple as a console player and yet connects somewhere. But that's just me. I grew up in other times.
Also I just compiled mp3blaster and I am listening to it again. So cool!
If it phones home without explicitly asking the user for permission in advance, it's spyware.
You can still set up an mpd server: https://www.musicpd.org/ that runs on your local files.
I used to use mocp under Unix but nowadays it's just audio/zuke in 9front with plumber settings for playlists.
Telemetry on by default in a CLI app seems very weird
As noted in another thread, it has since been removed: https://github.com/bjarneo/cliamp/commit/085734a86343a80176d...
Like others the telemetry is hugely undesirable nor necessary. Likewise if they truly don't collect your IP as they claim it's just ripe for endless abuse.
If you just want to say "like others", you could simply upvote one of the other comments? Anyway, looks like the telemetry has been removed due to popular demand: https://github.com/bjarneo/cliamp/commit/085734a86343a80176d...
Hi, I didn't just want to say though, as you might have noted from the second sentence in my comment.
Have a great day!
Winamp was pretty cool. When I switched to Linux, many years ago, I wanted to have winamp too. I think I used bmp for a while until it died; before that xmms but that one also sort of died.
Meanwhile some other GUI showed up, I forgot the name. I kind of gave up on winamp, mostly because my use cases shifted. I went to mplayer, then mpv, and now I am too used to using mpv for literally anything related to audio and video (which in turn uses ffmpeg of course). I kind of built a commandline helper variant that just plays anything I have local - audio, video. I could probably go and find a nice UI again, and that may have advantages such as simply scrolling through the list or setting ad-hoc favourites, but I don't quite need it anymore; I am faster with the keyboard too, so my use cases changed. To play all audio from Hans Zimmer, for instance, I may type "rsong Zimm" or something like that. (I also alias a lot so I may just type "zimmer" instead, but most of the time if I use it I just have it default to random selection as I don't care what is played normally.)
XMMS lives on as Audacious: https://audacious-media-player.org/
You can still configure it to look like XMMS.
And it's compatible with winamp skins, so you can download the winamp base skin ( https://skins.webamp.org/skin/5e4f10275dcb1fb211d4a8b4f1bda2... ) and have it look exactly like winamp.
XMMS1 source code is also still around https://github.com/csepulveda/xmms1
..and XMMS2 apparently had a few recent releases https://github.com/xmms2/xmms2-devel
There are countless good audio players now.
I am using Amberol, it looks just amazing in a modern desktop and plays my FLAC collection.
About using the command line... I just type open musicfile.flac and it works. Opening another file adds it to the reproduction queue.
For a terminal music player I like termusic, which is somewhat similar to mp3blaster, which I sorely miss.
https://github.com/tramhao/termusic
The not so good parts are 1) it is written in Rust and therefore packaging is awful with a lot of dependencies; 2) it repeats playlists by default with no option (so far) to turn that off. But there's an issue open on it and it looks like this is going to be fixed.
This is cool! I wanted to make a basic CRUD form to update meta data and was considering go, lots of neat libraries to take a look at.
Interesting that it uses charmbracelet libraries to create the terminal components. I often have a hard time understanding how to use charmbracelet effectively, for minor TUI things I prefer tview more.
Anyone know any good tutorials/blog posts about building something complicated with bubble tea? I feel like the charmbracel docs are way too "happy path" if that makes sense?
I’ve been using this in Omarchy, it’s really great - easy to use and can do any songs or playlist on YouTube, so I’ll pipe through those programming concentration playlists without visiting YouTube.
Looks great and bring backs a lot of memories... I had to go back to https://skins.webamp.org/ for a nostalgia shot.
I wish music had not move to stream, I think I appreciated each song much more when listening did not feel like such an ephemeral experience.
Just installed this, loving it so far! Thank you!
As someone who is fond of Windows music players and futuristically designed DIN stereos of the early-to-mid 2000s, the variety of console visualizations is wicked cool and very much welcome! This is easily the best feature of cliamp. I'd love the collection of visualizations as a separate program, akin to cava[1], that listens and responds to your default audio sink. I already use a Raspberry Pi for music while driving, so I'm already thinking about displaying these visualizations on my car's infotainment screen somehow.
As a friendly request, I'd love to be able to use up and down keys to seek one minute forward or backward during playback, like with mpv. I play a lot of mixes that are an hour or longer in length, so this functionality would be a nice-to-have. I'll likely submit this idea to GitHub, anyhow.
To share some honest criticism, I was disappointed to discover built-in telemetry. Although it can be disabled with a flag, I dislike how it's enabled by default and unknown to the user unless one specifies the -h flag. I don't understand why user diagnostics data is needed from a console music player. Make this anti-feature opt-in and instead rely primarily on bug reports, or make the user aware of this telemetry upon initial invocation and provide instructions on how to disable it. Constructively, know your audience.
But overall, thank you to all the maintainers for this cool software!
[1]: https://github.com/karlstav/cava
Looks like the telemetry was removed:
https://github.com/bjarneo/cliamp/commit/085734a86343a80176d...
You now have my full support. Thank you!
Should have called it clamp
Ha! Huge missed opportunity :-)
There may not be many like me, but I sure as hell appreciate a clever name. A great name is extremely hard, but figuring one out can make or break a project.
This is great, all I wanted from music player! I've used cmus last few years but it has some warts and UX downsides.
The project is cool, the demo song is iconically AI not great, sorry.
I've checked out the three radio stations, they are lame, too. Not sure if AI or otherwise low effort, but not good in any case.
The project is not promoting it's music taste and ability..
I hope they included the llama whipping.
Imagine telling your AI to include unsecured telemetry… all im the namesake of mother Russia and father China. Wait no, that’s the wrong message.
Of course for the terminal. GUIs never developed, as we still live in the 1970s.
[dead]