Musicer

How it Started

I listen to a lot of music. Well, I spend most of my day sitting at my desk or on my laptop working or studying, and I always have something playing in the background. So, my music player is probably one of the most important apps in my workflow. Having tried out countless different players over the years, for both streaming and for my local library, I never felt comfortable sticking to one of these apps for more than a couple of weeks.

For starters, both Spotify and Apple Music are heavy webapps and their Windows apps feel sluggish to use; not to mention the crazy amount of bugs and insane memory usage even in the background. Mind you, I still pay for Spotify and I love their iOS app, but I don’t actually listen to music on the go. It’s more like a background noise filter for me on the bus.

When I’m at my setup, I have my local library of lossless tracks and a nice pair of IEMs to really enjoy my favorite music. But here’s the thing: most audiophiles have these crazy software and EQ setups which they spend thousands of hours playing around with. There are apps like foobar2000 that are very lightweight, but also offer endless amounts of customization. Being a perfectionist, I’d find myself spending more time swapping out EQs than actually listening. I mean, it’s part of the hobby, but it wasn’t for me. Barebones foobar2000 gets the job done, but it looks like an app made for Windows XP.

Having tried out a few more options including Windows Media Player (which I used for more than a year), I realized that none of these options gave me the perfect balance between user-friendly aesthetics and systems-level performance. Being bored and wanting a challenge, I thought it would be cool to try and build my own player.

A New Challenge

At this point, I had already been playing around with Rust and worked on a couple of projects including xcreen; I wanted to build a CLI music player focusing solely on performance and resource efficiency.

While working on the core audio pipeline (mostly cleaning up vibe-coded slop) for about a month, I started building a portfolio website on the side. I was researching different frameworks and stumbled upon Svelte. Needless to say, I fell in love with it. I don’t know, maybe it was the nice and simple logic/markup/styles structure, or even the routing system; I wanted to build everything in Svelte. I started my markdown editor project which used Tauri with Svelte and I finished my portfolio website in a couple of weeks. By this point, I already had Musicer (or whatever that project was called) playing my library, sequentially, in a quiet terminal. So, I had two options: build a complete CLI which would grow into a full TUI; or use the Rust backend I’d built and wrap a Svelte UI around it with Tauri. Guess which one I picked?

I didn’t build Musicer with plans to put it up on the store or sell it to people; I built it for myself. I hated every music player app I tried and I wanted something that just blends into my workflow and gets out of my way. After all, good UX is invisible, right?

It Felt Personal

From the global command palette with near-instant searching and commands like /q <track_name> which adds a track to the queue, to the CLI mode where the same binary can play music without a webview, Musicer is now a mix of gimmicks and genuinely useful features. But it’s mine, and I have the freedom to do anything I want with it.

I do think about making it a public repo when I’m done. The idea of a small community on a GitHub thread, bringing up all the little quirks and flaws of something I built with so much joy and passion — that does get me excited.

There’s still a lot of work left to do. Smart playlists, metadata editing, visualizations, a now-playing view, a mini-player mode. It’s probably going to take another couple of months to get everything right before I think about the next step. For now, it’s just me, my IEMs, and a music player that finally doesn’t get in the way.